Escolher um MSP para migração de servidores para nuvem deixou de ser uma decisão de infraestrutura e passou a ser uma decisão de risco. Em empresas de médio e grande porte — sobretudo as que operam dados sensíveis, transações via Pix ou ambientes regulados pelo Banco Central — o fornecedor que conduz o projeto passa a ter acesso privilegiado a sistemas críticos, trilhas de auditoria e informações sob a LGPD. Errar nessa escolha custa mais do que o contrato: custa prazo, conformidade e confiança do negócio.
O problema é que a maioria das propostas chega igual. Todas falam em assessment, em ondas de migração, em Azure, em segurança. O que muda — e quase nunca aparece no slide comercial — é o que está escrito no contrato, quem atende o chamado às 3h da manhã, como o provedor comprova os controles que diz ter e o que acontece se o cutover falhar. Sem critérios objetivos, a decisão acaba sendo tomada por simpatia comercial ou por preço, dois péssimos conselheiros em ambientes críticos.
Este guia reúne critérios pontuáveis para comparar MSPs, perguntas técnicas para usar na entrevista com cada candidato, modelos de contratação praticados no mercado brasileiro e as cláusulas que precisam estar no contrato antes da assinatura — incluindo SLA, reversibilidade e propriedade dos dados.
O que um MSP faz na migração de servidores para a nuvem (e o que não é responsabilidade dele)
Um MSP (Managed Service Provider, ou provedor de serviços gerenciados) assume a execução técnica e a coordenação do projeto de migração de servidores on-premise para a nuvem. Isso inclui inventário de ativos, desenho da arquitetura de destino, configuração de rede e identidade, replicação de dados, execução do cutover e estabilização pós-migração. Em ambientes Microsoft, o trabalho concentra-se em Azure Migrate, Azure Site Recovery, redefinição de políticas de acesso e integração com o Microsoft Entra ID (antigo Azure AD).
O MSP também opera a camada de governança durante o projeto: define grupos de recursos, tags de custo, políticas de backup e monitoramento antes mesmo do primeiro servidor ser movido. Em setores regulados, como o financeiro, ele documenta evidências de controle que serão exigidas em auditorias — trilhas de acesso, segregação de funções e registros de mudança. A migração para Azure bem conduzida é, antes de tudo, um projeto de engenharia de plataforma, não de simples cópia de máquinas virtuais.
O que não é responsabilidade do MSP: decidir unilateralmente o roadmap de negócio, aprovar orçamento, assumir a responsabilidade legal pela conformidade da empresa ou garantir disponibilidade absoluta. A LGPD atribui ao controlador — a empresa contratante — a obrigação final de proteção de dados. O MSP atua como operador e pode responder solidariamente em caso de falha comprovada, mas a decisão de risco é da contratante. Da mesma forma, o MSP não substitui o DPO nem o comitê de segurança interno.
Sinais de que sua empresa precisa de um MSP em vez de fazer a migração sozinha
O primeiro sinal objetivo é a ausência de equipe com experiência em migração em escala. Mover três servidores de arquivos é factível para uma equipe interna; migrar 80 servidores com interdependências, Active Directory, SQL Server e aplicações legadas exige conhecimento de dependências que só aparece em projetos reais.
O segundo sinal é a combinação de ambiente regulado com prazo de auditoria. Empresas que processam transações via Pix ou dados financeiros não podem tratar a migração como experimento: precisam de evidências desde o primeiro dia. Um MSP com metodologia documentada entrega o pacote de conformidade junto com a infraestrutura. O terceiro sinal aparece quando o custo de oportunidade da equipe interna supera o custo do serviço: manter engenheiros seniores parados por três meses em tarefas de migração custa mais do que contratar um parceiro, especialmente considerando retrabalho.
- Equipe interna sem experiência em migração de larga escala
- Ambiente regulado com necessidade de trilha de auditoria desde o início
- Prazo rígido imposto por fim de contrato de datacenter ou renovação de licenças
- Dependências complexas entre servidores legados e SQL Server
- Custo de oportunidade da equipe interna maior que o valor do projeto
Os 9 critérios para avaliar um MSP de migração para nuvem
Estes nove critérios formam uma matriz objetiva de comparação. Atribua peso de 1 a 5 para cada um conforme a realidade da sua empresa e pontue cada candidato. A soma ponderada elimina o viés de discurso comercial e transforma a escolha em decisão técnica auditável.
Certificações e competências validadas pelos hyperscalers (AWS, Azure, Google Cloud)
Certificações de parceiro não são enfeite: elas exigem renovação periódica, número mínimo de profissionais certificados e comprovação de projetos entregues. No ecossistema Microsoft, procure o selo Solutions Partner com designações específicas — Infraestrutura (Azure), Segurança e Modern Work. A designação exige métricas de performance, crescimento de consumo e qualificações técnicas auditadas pela Microsoft, não apenas inscrição em programa.
Desconfie de parceiros que listam apenas certificações individuais antigas. A certificação de pessoa física (como Azure Solutions Architect Expert) tem valor, mas não prova capacidade de entrega em equipe. O selo de parceiro é o que vincula a empresa a resultados mensuráveis. Pergunte há quanto tempo a designação está ativa e quantos profissionais certificados sustentam o selo.
Metodologia de migração: assessment, ondas, cutover e rollback
Metodologia madura se reconhece pela granularidade do plano. Um MSP sério entrega o assessment com inventário de dependências, mapa de rede, análise de licenciamento e estimativa de custo por workload antes de propor qualquer arquitetura. A migração em ondas — agrupando servidores por afinidade de aplicação e risco — reduz o impacto de falhas e permite aprendizado entre lotes.
O critério decisivo é o plano de rollback. MSP que não descreve como reverter um cutover malsucedido está vendendo otimismo, não engenharia. Exija documento formal com RTO (Recovery Time Objective) e RPO (Recovery Point Objective) por onda, janela de cutover, critérios de go/no-go e responsável por acionar a contingência.
Experiência comprovada no seu setor e porte de ambiente
Migrar servidores para um escritório de advocacia tem complexidade diferente de migrar um ambiente bancário ou de meios de pagamento. Regras de segregação de rede, criptografia de dados em trânsito e em repouso, e requisitos do Banco Central mudam completamente o desenho. Um MSP com histórico em varejo pode ser excelente, mas não terá repertório para as exigências de um ambiente que processa Pix.
Peça referências do mesmo setor e, idealmente, do mesmo porte. Um projeto de 15 servidores não prepara ninguém para 200 servidores com SQL Server em cluster, balanceadores e VPN site-to-site. O porte importa porque erros de arquitetura que passam despercebidos em ambientes pequenos viram incidentes graves em escala.
Modelo de suporte, SLA e escalonamento
SLA de migração é diferente de SLA de operação. Durante o projeto, o que importa é o compromisso com janelas de cutover, tempo de resposta em incidentes de migração e disponibilidade da equipe no período hipercrítico — as primeiras 72 horas após cada onda. Depois da migração, o SLA operacional assume: tempo de resposta, tempo de resolução e disponibilidade da plataforma.
Examine a matriz de escalonamento. Quem atende o chamado às 3h da manhã quando um servidor crítico não sobe após o cutover? O contrato prevê engenheiro sênior de plantão ou apenas central de atendimento que registra ticket? Para ambientes que processam transações financeiras, a diferença entre um e outro é medida em prejuízo por minuto de indisponibilidade.
Segurança, LGPD e conformidade regulatória
O MSP precisa demonstrar controles próprios, não apenas falar sobre segurança. Exija evidências: política de acesso à sua tenancy, uso de contas com privilégio mínimo, autenticação multifator obrigatória para a equipe do provedor e registro de todas as ações administrativas. Um MSP que acessa seu ambiente com conta global compartilhada viola princípios básicos de ISO 27001 e coloca sua conformidade em risco.
No contexto da LGPD, o contrato precisa definir claramente os papéis de controlador e operador, a finalidade do tratamento, as categorias de dados acessadas e o destino dos dados após o encerramento. A autenticação multifator é requisito mínimo para qualquer acesso administrativo. Em ambientes Pix, avalie também se o MSP tem repertório em controles específicos do setor financeiro, como segregação de ambientes de desenvolvimento e produção e criptografia de chaves com HSM.
Transparência de custos e previsibilidade contratual
Proposta de migração que esconde custo de saída de dados, licenciamento ou tráfego entre regiões é armadilha clássica. O MSP maduro apresenta o custo total estimado da migração e, separadamente, o custo recorrente da nuvem com estimativa de variação mensal. A conta da nuvem é da sua empresa, não do MSP — o provedor deve ajudar a prever, não intermediar com opacidade.
Contrato com cláusula de reajuste unilateral ou sem teto de horas adicionais é sinal de risco. Exija previsibilidade: escopo fechado com gatilhos claros de mudança, custo por onda, e definição do que é considerado "fora de escopo" antes da assinatura. A transparência de custos é um dos critérios mais objetivos para separar parceiros de intermediários.
Independência de fornecedor e portabilidade
Um MSP sério não cria dependência irreversível. Isso significa que sua conta na nuvem fica em nome da sua empresa, com acesso administrativo pleno; que os scripts de automação e a documentação da arquitetura são entregues como parte do projeto; e que o encerramento do contrato prevê transferência de conhecimento estruturada. Se o MSP é o único que sabe como seu ambiente funciona, você não contratou um serviço — contratou um sequestro técnico.
Avalie também a neutralidade tecnológica dentro do ecossistema escolhido. Um parceiro Microsoft legítimo recomenda Azure quando faz sentido, mas não força migração de cargas que rodariam melhor on-premise ou em outro modelo. A decisão de migrar com parceiro deve ampliar suas opções, não reduzi-las.
Equipe dedicada versus body shop
Body shop é o modelo em que o MSP aloca profissionais avulsos na sua operação, sem metodologia própria nem responsabilidade pelo resultado. Equipe dedicada, no contexto de MSP, significa um time com papéis definidos — arquiteto, engenheiro de migração, especialista em segurança e gerente de projeto — que segue um processo e responde pelo desfecho. A diferença aparece na primeira crise: o body shop aponta o profissional; o MSP aponta a solução.
Pergunte quem será o arquiteto responsável pelo desenho e se essa pessoa participa das reuniões de decisão. MSP que vende projeto mas envia apenas executores juniores sem supervisão sênior está terceirizando o risco para você. O nome do arquiteto e do gerente de projeto devem constar na proposta, com currículo resumido.
Referências verificáveis e cases auditáveis
Referência verificável é aquela em que você pode falar com o cliente anterior, não apenas ler depoimento no site. Peça contato de pelo menos dois clientes do mesmo setor ou porte, e pergunte objetivamente: o prazo foi cumprido? Houve incidente no cutover? Como foi a resposta? O custo final ficou dentro do estimado? O que fariam diferente?
Case auditável é o que traz números verificáveis: quantidade de servidores, prazo em semanas, redução de custo operacional medida, tempo de cutover por onda. Desconfie de cases sem métricas ou com resultados genéricos como "migração bem-sucedida". Um MSP que entrega relatório de projeto com dados concretos tem metodologia; um que entrega apenas narrativa tem marketing.
Perguntas que separam MSPs preparados de vendedores de nuvem
Estas perguntas são para fazer em reunião técnica, com engenheiros presentes — não em call comercial. A forma como o MSP responde revela mais do que o conteúdo da resposta.
- Qual foi o maior incidente de migração que vocês já enfrentaram e como resolveram?
- Como vocês descobrem dependências ocultas entre servidores antes do cutover?
- Qual estratégia de rollback vocês aplicam quando um servidor crítico não sobe na nuvem?
- Quem acessa nossa tenancy durante o projeto e como esse acesso é registrado?
- Como vocês tratam dados sensíveis durante a replicação e o descarte do ambiente de origem?
- Qual o custo de saída se encerrarmos o contrato no meio do projeto?
- Vocês já migraram ambientes com requisitos do Banco Central ou que processam Pix?
MSP preparado responde com método, exemplo e limitação. Vendedor de nuvem responde com promessa vaga e desvia para "depende do cenário" sem detalhar o cenário. A pergunta sobre incidente é a mais reveladora: quem nunca teve incidente em migração ou está mentindo ou nunca migrou nada relevante. A resposta madura descreve o problema, a causa raiz e a correção — não a ausência de problemas.
Modelos de contratação: projeto fechado, alocação de horas ou MSP recorrente
O modelo de projeto fechado é adequado quando o escopo é claro e o objetivo é finito: migrar N servidores até a data X. O risco de mudança de escopo fica precificado, e o valor é acordado antes do início. A desvantagem é a rigidez: se durante o assessment surgirem 20 servidores não mapeados, a renegociação é inevitável. Contratos de projeto fechado bem feitos incluem cláusula de descoberta — uma fase paga de assessment que ajusta o escopo antes do valor final.
O modelo de alocação de horas (ou banco de horas) é flexível, mas perigoso para quem não tem governança interna forte. Sem métricas de produtividade, vira caixa-preta: você paga por horas sem saber o que foi entregue. Esse modelo funciona bem para demandas pontuais e imprevisíveis, não para projeto de migração com prazo e resultado definidos.
O modelo de MSP recorrente é o mais alinhado a quem busca relação de longo prazo: a migração é uma fase inicial de um contrato que inclui operação, monitoramento, segurança e otimização contínua. Nesse formato, o MSP tem incentivo econômico para migrar bem — porque vai operar o ambiente que construiu. A construção de business case para serviços gerenciados deve considerar que o custo da migração é investimento, não despesa isolada.
Quanto custa um MSP para migração de servidores para a nuvem no Brasil
Não existe tabela pública de preços para migração gerenciada no Brasil, e qualquer valor fechado sem assessment é estimativa.
Ambientes com alta complexidade — clusters de SQL Server, aplicações legadas sem documentação, requisitos de compliance financeiro — podem ultrapassar esse teto. O que encarece não é o número de servidores, mas a densidade de dependências e o nível de exigência regulatória. Um servidor de arquivos simples custa pouco; um servidor de banco de dados transacional com exigência de RPO próximo de zero custa múltiplas vezes mais.
Além do custo do projeto, considere o custo recorrente da nuvem, que é pago ao hyperscaler e não ao MSP. Uma estimativa mal calibrada de consumo pode transformar uma migração "barata" em conta mensal imprevisível. O MSP competente entrega a estimativa de custo mensal da nuvem junto com a proposta de migração — e essa estimativa é parte do critério de avaliação, não um anexo decorativo.
Erros que encarecem a migração e como o MSP certo os evita
O erro mais caro é migrar sem assessment: mover servidores no formato lift-and-shift sem entender dependências gera retrabalho, indisponibilidade e custo de nuvem inflado. Servidores superdimensionados na nuvem são a principal causa de conta mensal acima do orçamento. O MSP que faz assessment de sizing e rightsizing antes da migração evita pagar por capacidade ociosa desde o primeiro dia.
O segundo erro é ignorar custo de saída de dados e tráfego entre regiões. Migrar dados para a nuvem é barato; movê-los entre regiões ou de volta para on-premise pode custar caro. O MSP experiente desenha a topologia considerando onde os dados vão residir e como serão acessados, evitando surpresas na fatura do hyperscaler.
O terceiro erro é tratar segurança como fase posterior. Migrar primeiro e "depois a gente protege" é a receita para incidente em ambiente exposto. O MSP certo configura identidade, rede segmentada, criptografia e monitoramento antes do primeiro cutover. A migração com monitoramento proativo desde o primeiro dia não é diferencial — é requisito mínimo de engenharia.
O que avaliar depois da migração: FinOps, governança e otimização contínua
A migração não termina no cutover. O que separa projeto bem-sucedido de desastre financeiro é a gestão contínua do ambiente. FinOps — a disciplina de gestão financeira da nuvem — começa no primeiro mês de operação: analisar consumo por workload, identificar recursos ociosos, ajustar reservas e definir orçamentos por departamento ou aplicação. Sem FinOps, a conta de nuvem cresce silenciosamente até virar problema de diretoria.
Governança pós-migração inclui políticas de acesso, revisão periódica de permissões, gestão de patches e conformidade contínua. O ambiente na nuvem muda mais rápido que o datacenter físico: novos recursos, novas contas, novas configurações. Sem governança automatizada, o ambiente degrada em meses. A otimização contínua — rightsizing, modernização de workloads, ajuste de arquitetura — é o que transforma a nuvem em vantagem competitiva em vez de despesa crescente.
Um MSP recorrente entrega essas três frentes como serviço: relatórios mensais de FinOps, revisão de governança e recomendações de otimização. Se o contrato termina no cutover, sua equipe interna herda a responsabilidade sem necessariamente ter a capacitação. Avalie antes de assinar se o escopo inclui o pós-migração ou se o MSP desaparece após a última onda.
Checklist de due diligence para contratar seu MSP
Use este checklist como roteiro de validação antes de assinar qualquer contrato. Cada item não verificado é um risco assumido conscientemente — ou um ponto de negociação.
- Selos de parceiro ativos e verificáveis no portal do hyperscaler
- Metodologia documentada com fases, entregáveis e critérios de aceite por onda
- Plano de rollback com RTO e RPO definidos por workload
- Contrato com cláusula de reversibilidade e transferência de conhecimento
- Política de acesso administrativo com privilégio mínimo e MFA obrigatória
- Definição de papéis LGPD (controlador e operador) e destino dos dados no encerramento
- Proposta com custo de migração e estimativa de custo recorrente da nuvem separados
- Referências do mesmo setor e porte, com contato direto para validação
- Equipe nomeada na proposta: arquiteto, gerente de projeto e engenheiros
- SLA de projeto e SLA operacional descritos com métricas e penalidades
A due diligence não é burocracia: é o que transforma uma decisão de confiança em decisão de engenharia. Em ambientes que processam dados sensíveis ou transações via Pix, a ausência de qualquer item da lista pode ser o elo fraco que um auditor ou um atacante encontra primeiro. O ethical hacking e os testes de invasão em Azure são complementos naturais dessa validação, aplicados depois que o ambiente está operando.
Como conduzir o processo de RFP e comparação de propostas
RFP (Request for Proposal) é o instrumento que transforma a seleção de MSP em processo comparável. Envie o mesmo documento para todos os candidatos, com escopo detalhado, inventário de servidores, requisitos de compliance, prazos e critérios de avaliação. A padronização elimina a assimetria de informação e permite comparar propostas lado a lado em uma matriz objetiva.
A matriz de comparação deve incluir os nove critérios deste artigo, com pesos definidos antes de receber as propostas — não depois. Definir pesos a posteriori é viés de confirmação disfarçado de análise. Cada critério recebe nota de 1 a 5, multiplicada pelo peso, e a soma gera um ranking. A proposta vencedora não é necessariamente a mais barata nem a mais cara: é a que maximiza o valor ponderado para o seu contexto.
Na etapa de apresentação, exija que cada candidato defenda tecnicamente a proposta diante da sua equipe. Pergunte sobre os pontos fracos da própria proposta — a resposta revela maturidade. MSP que admite limitações e propõe mitigação é mais confiável do que o que promete perfeição. Por fim, valide as referências antes de abrir negociação contratual, e inclua no contrato as cláusulas de reversibilidade, propriedade de dados e transferência de conhecimento que foram prometidas na proposta. A terceirização da TI com controle preservado depende exatamente disso: contrato bem desenhado, não confiança cega.
