A maior parte do conteúdo sobre contratar servidor trata do que perguntar ao fornecedor. Este trata do outro lado: o que você precisa saber sobre o seu próprio projeto antes de fazer essas perguntas.

A razão é prática. Contratações que dão errado raramente falham por escolha de fornecedor. Falham por decisões que não foram tomadas: ninguém definiu quem administra, ninguém mediu a carga real, ninguém verificou se a aplicação roda no ambiente escolhido, ninguém previu o que acontece na migração.

Este guia organiza o que levantar antes de assinar, na ordem em que as respostas importam. Os critérios de avaliação do fornecedor estão no artigo sobre como escolher uma hospedagem — aqui, o foco é a preparação.

1. Confirme que a restrição é real

A primeira pergunta é a mais desconfortável: você precisa mesmo de um servidor?

Existem três motivos legítimos para contratar um: o ambiente atual não executa o que a aplicação exige, não sustenta o volume que ela tem, ou não permite a configuração que ela precisa.

Se nenhum dos três se aplica, a contratação tende a adicionar custo e responsabilidade sem entregar resultado. E há um cenário específico que vale eliminar antes: lentidão causada pela aplicação, e não pelo ambiente. Nesse caso, o problema acompanha a migração — apenas com custo maior.

Vale rodar o diagnóstico antes de decidir. Para sites WordPress, o roteiro está no artigo sobre por que o WordPress fica lento.

2. Meça a carga real

Sem números, o dimensionamento é chute — e o chute erra nos dois sentidos, com custos diferentes.

Contratar demais é desperdício recorrente. Contratar de menos gera um projeto de migração logo em seguida, o que é pior.

O que levantar no ambiente atual:

• Pico de consumo de memória e processamento nos últimos 30 dias, e não a média.
• Requisições simultâneas no horário de maior movimento.
• Proporção de tráfego que não passa por cache — é ela que define a carga real.
• Tamanho do banco de dados e a taxa de crescimento.
• Espaço em disco em uso, considerando mídias e backups locais.
• Volume de dados transferido por mês, que costuma ter cota nos planos.

Esses dados estão no painel do provedor atual e em uma ferramenta de analytics. O levantamento leva menos de uma hora e muda completamente a conversa comercial: você deixa de perguntar “qual plano vocês recomendam” e passa a perguntar “esta configuração comporta esta carga”.

3. Liste o que a aplicação exige

A verificação que evita a descoberta mais cara: contratar e depois perceber que o ambiente não executa o que você precisa.

O inventário:

• Versões de linguagem e de banco de dados exigidas.
• Extensões e bibliotecas que a aplicação usa — os frameworks costumam listar.
• Serviços auxiliares, como cache em memória ou motor de busca.
• Processos que precisam ficar ativos: filas, workers, automações.
• Tarefas agendadas, com a frequência de cada uma.
• Integrações que dependem de endereço fixo, já que o IP muda com o servidor.
• Bibliotecas que exigem compilação na instalação.

O item das integrações é o que mais causa problema depois: sistemas de terceiros que autorizam acesso por endereço precisam ser atualizados, e essa falha é silenciosa — ninguém avisa que parou de funcionar.

4. Defina quem administra

A decisão que mais impacta o resultado e a mais adiada.

A pergunta precisa de nome, não de intenção: quem, especificamente, vai aplicar as atualizações de segurança, monitorar o consumo, verificar o backup e responder quando algo falhar?

As respostas possíveis:

• Alguém da equipe que já administra servidores como parte do trabalho.
• Uma agência ou consultor contratado para isso, com escopo definido.
• O provedor, em um plano gerenciado.
• Você mesmo, com tempo alocado para a rotina.

A resposta que não funciona é “a gente vê depois” — e ela é a mais comum. Um servidor sem responsável definido acumula atualizações não aplicadas e vira uma exposição crescente.

Se ninguém da equipe faz isso hoje, o modelo gerenciado costuma sair mais barato no total, considerando as horas envolvidas. O comparativo entre os modelos está no artigo sobre Cloud Server gerenciado ou autogerenciado.

5. Monte o orçamento completo

A mensalidade é uma linha entre várias, e comparar propostas só por ela leva a decisões incompletas.

O que somar:

• A instância, com os recursos definidos na etapa 2.
• A administração, seja em horas internas, seja em contrato.
• Backup, se não estiver incluído com a retenção necessária.
• Monitoramento, quando exigir ferramenta à parte.
• Ambiente de homologação, se o projeto precisar.
• A migração, que é custo pontual mas real.
• Uma margem para crescimento nos próximos doze meses.

A composição detalhada está no artigo sobre quanto custa manter um Cloud Server. O que vale reforçar aqui: calcule em doze meses e use preços de renovação, não promocionais.

6. Defina o que precisa estar em contrato

Itens que devem ser esclarecidos antes de assinar, e não descobertos durante um incidente:

Item	O que confirmar
Escopo de gestão	O que exatamente o provedor faz, por escrito
SLA	Qual se aplica a este serviço, e o que exclui
Backup	Frequência, retenção, local e quem restaura
Suporte	Canais, horários e prazos, inclusive fora do expediente
Crescimento	Como aumentar recursos e se há indisponibilidade
Migração	Se há apoio e o que ele cobre
Saída	Como exportar tudo se você decidir sair

A última linha é a menos perguntada e uma das mais reveladoras. Um fornecedor que facilita a saída está confiando na qualidade do serviço; um que dificulta está apostando na inércia.

Sobre o SLA, vale a atenção específica de verificar o número aplicável ao serviço contratado, e não o exibido na página inicial — o assunto está detalhado no artigo sobre o que é uptime e SLA.

7. Planeje a migração antes de contratar

Um erro comum de sequência: contratar primeiro e pensar na migração depois. O resultado é pagar por dois ambientes enquanto ninguém tem tempo de conduzir a mudança.

O que definir antes:

1. Quem executa a migração — equipe, agência ou o provedor.
2. Quando, com janela escolhida fora de períodos críticos do negócio.
3. O que migra junto: site, banco de dados, contas de e-mail, tarefas agendadas, certificados.
4. Quanto tempo o ambiente antigo permanece ativo depois da virada.
5. Quem atualiza as integrações que dependem de endereço fixo.
6. Como voltar atrás, se necessário.

O procedimento completo está no artigo sobre migrar de hospedagem sem sair do ar. O ponto aqui é que essas decisões precedem a contratação, porque influenciam o que contratar e quando.

Os erros que aparecem depois

Padrões que se repetem e são evitáveis:

1. Contratar pelo plano do meio da tabela, sem medir. É a origem tanto do desperdício quanto do subdimensionamento.
2. Assumir que o backup está incluído com a retenção que você precisa.
3. Descobrir depois que falta uma extensão que a aplicação exige.
4. Não definir quem administra, e perceber isso na primeira atualização de segurança pendente.
5. Esquecer o e-mail, tratando a migração como se fosse só o site.
6. Contratar em véspera de período crítico, sem janela para migrar com calma.
7. Comparar mensalidades em vez de custo total em doze meses.

O quinto merece destaque porque falha em silêncio: mensagens que deixam de chegar não geram reclamação imediata, e o problema é descoberto tarde.

Um roteiro de duas semanas

Para quem quer organizar isso sem travar o projeto:

Semana 1 — levantamento. Rodar o diagnóstico da etapa 1, medir a carga da etapa 2 e montar o inventário da etapa 3. É trabalho de poucas horas, distribuído.

Semana 2 — decisões e propostas. Definir quem administra, montar o orçamento completo, solicitar propostas com os números em mãos e comparar pelos itens contratuais da etapa 6.

Depois — planejar a migração e só então contratar, com a janela já definida.

Duas semanas parecem muito para quem tem pressa, mas são menos do que o tempo perdido em uma contratação que precisa ser corrigida.

Conclusão

Contratar um servidor com segurança depende menos de escolher o fornecedor certo e mais de chegar à conversa com as respostas prontas: a restrição é real, a carga foi medida, a aplicação foi inventariada, o administrador tem nome e a migração tem data.

Com esses cinco pontos resolvidos, a comparação entre propostas fica objetiva e a chance de descobrir um problema depois cai drasticamente.

E a pergunta que resolve mais do que qualquer outra: quem, especificamente, vai cuidar disso? Se ela não tem resposta, resolva-a antes de contratar — ou contrate o modelo gerenciado. Conheça os Cloud Servers da TBF Host e traga os seus números para a conversa.

Perguntas frequentes

O que avaliar antes de contratar um servidor cloud?

Do lado do seu projeto: se a restrição que motiva a contratação é real, qual a carga medida do ambiente atual, o que exatamente a aplicação exige, quem vai administrar o servidor, qual o orçamento completo em doze meses, o que precisa estar em contrato e como será a migração.

Como saber se realmente preciso de um servidor?

Existem três motivos legítimos: o ambiente atual não executa o que a aplicação exige, não sustenta o volume que ela tem ou não permite a configuração necessária. Se nenhum se aplica, a contratação adiciona custo e responsabilidade sem resultado. Vale eliminar antes a hipótese de lentidão causada pela própria aplicação.

O que medir antes de dimensionar um servidor?

Pico de memória e processamento nos últimos 30 dias, requisições simultâneas no horário de maior movimento, proporção de tráfego que não passa por cache, tamanho e crescimento do banco de dados, espaço em disco em uso e volume de dados transferido por mês. Os dados estão no painel do provedor atual.

O que verificar sobre a aplicação antes de contratar?

As versões de linguagem e banco exigidas, extensões e bibliotecas usadas, serviços auxiliares necessários, processos que precisam ficar ativos, tarefas agendadas e integrações que dependem de endereço fixo — porque o IP muda com o servidor e essas integrações param sem avisar.

Quem deve administrar o servidor?

A pergunta precisa de nome, não de intenção: quem especificamente vai aplicar atualizações de segurança, monitorar consumo, verificar backup e responder a falhas. Pode ser alguém da equipe, uma agência contratada, o provedor em plano gerenciado ou você mesmo com tempo alocado. A resposta que não funciona é deixar para depois.

O que precisa estar no contrato?

Escopo de gestão por escrito, o SLA aplicável ao serviço específico e suas exclusões, frequência e retenção do backup com quem executa a restauração, canais e prazos de suporte inclusive fora do expediente, como aumentar recursos, se há apoio na migração e como exportar tudo em caso de saída.

Devo planejar a migração antes ou depois de contratar?

Antes. Contratar primeiro e pensar na migração depois costuma resultar em pagar por dois ambientes enquanto ninguém tem tempo de conduzir a mudança. Definir quem executa, quando, o que migra junto e como voltar atrás influencia inclusive o que e quando contratar.

Quais os erros mais comuns ao contratar um servidor?

Escolher o plano do meio da tabela sem medir, assumir que o backup está incluído com a retenção necessária, descobrir depois que falta uma extensão, não definir quem administra, esquecer o e-mail na migração, contratar em véspera de período crítico e comparar mensalidades em vez de custo total anual.