Escolher quem vai conduzir a migração para o Azure costuma virar uma decisão de alto risco quando as propostas parecem idênticas no papel e os selos exibidos não deixam claro o que realmente foi validado. Para empresas que lidam com dados sensíveis, a dúvida não é só técnica: é sobre confiança, conformidade e continuidade. Este texto reúne o que avaliar em um parceiro Microsoft para migração Azure, com critérios de verificação, perguntas para referências e sinais de alerta antes de assinar.
O que um parceiro Microsoft para migração Azure realmente entrega
Um parceiro Microsoft para migração Azure não é apenas um fornecedor de mão de obra técnica. Ele atua como um agente de transformação que conecta o estado atual da infraestrutura — geralmente on-premise, com servidores legados, dependências ocultas e dívidas técnicas — a um modelo operacional em nuvem que precisa ser governado, seguro e financeiramente sustentável. Essa entrega começa muito antes da movimentação de cargas de trabalho: envolve leitura de inventário, análise de dependências, definição de arquitetura-alvo e construção de um business case que justifique o investimento perante o conselho ou a diretoria.
Na prática, o parceiro entrega um conjunto articulado de capacidades que inclui:
- Diagnóstico técnico do ambiente atual, com inventário de servidores, aplicações, bancos de dados e fluxos de rede
- Desenho da arquitetura-alvo no Azure, considerando zonas de pouso, identidade, rede e políticas de segurança
- Execução da migração em ondas controladas, com testes de cutover e plano de reversão documentado
- Governança de custos desde o primeiro dia, evitando surpresas na fatura mensal
- Transferência de conhecimento para o time interno operar o ambiente com autonomia progressiva
Empresas do setor financeiro ou que processam transações via Pix adicionam uma camada crítica a essa entrega: a conformidade regulatória. O parceiro precisa demonstrar familiaridade com requisitos de soberania de dados, trilhas de auditoria e controles de acesso que vão além do básico de qualquer migração. Um parceiro que trata segurança como item opcional de escopo não está preparado para ambientes sensíveis.
Certificações e designações Microsoft que importam na prática
As credenciais de um parceiro Microsoft funcionam como um filtro inicial, mas precisam ser interpretadas com precisão. Um selo genérico não diz nada sobre a capacidade de executar uma migração específica de SAP, de um data warehouse legado ou de um ambiente com criptografia de dados em trânsito e em repouso. O que importa é a combinação entre a designação global, as especializações avançadas e a evidência de projetos entregues.
Azure Expert MSP, Gold e Solutions Partner: o que cada selo comprova
O programa de parceiros da Microsoft passou por reformulações nos últimos anos, e a nomenclatura antiga ainda gera confusão. As competências Gold e Silver foram descontinuadas como modelo principal e substituídas pelo programa Solutions Partner, que avalia o parceiro em seis áreas de solução — entre elas Infraestrutura (Azure), Segurança, Dados e IA (Azure) e Modern Work. Dentro de cada área, a Microsoft mede desempenho, qualificações da equipe e crescimento de clientes.
O selo Azure Expert MSP é uma auditoria independente, conduzida por terceiros, que avalia a excelência operacional em serviços gerenciados de Azure. Ele não é uma simples compra de certificação: exige evidências de processos maduros, automação, monitoramento e gestão de custos em clientes reais. Para uma empresa que busca um parceiro de longo prazo — e não apenas um executor pontual — essa designação tem peso maior que qualquer competência isolada.
Especializações avançadas por carga de trabalho (dados, SAP, segurança, IA)
As especializações avançadas são o refinamento do Solutions Partner. Elas comprovam capacidade técnica profunda em cenários específicos, como migração e modernização de data warehouse para Azure, SAP on Azure, segurança de nuvem, serviços de IA e virtualização de desktop. Um parceiro com especialização avançada em migração de data warehouse, por exemplo, passou por validação técnica da Microsoft sobre como conduzir esse tipo de projeto — não apenas sobre como vender Azure.
Para ambientes financeiros, a especialização em segurança de nuvem e a de conformidade são sinais relevantes. Elas indicam que o parceiro já foi avaliado em cenários que envolvem controles de acesso, proteção de dados e auditoria — exatamente o tipo de exigência que uma empresa com Pix e dados sensíveis enfrenta no dia a dia.
Como validar as credenciais no Partner Center e no diretório oficial
Nenhuma credencial deve ser aceita apenas porque aparece no site do parceiro. A Microsoft mantém diretórios públicos onde qualquer pessoa pode verificar a situação de um parceiro, as designações ativas e as especializações avançadas conquistadas. O caminho é acessar o Partner Center ou o diretório de parceiros da Microsoft, buscar pelo nome da empresa e conferir se os selos exibidos correspondem aos que foram declarados na proposta comercial.
Três verificações práticas fazem diferença:
- Confirmar se a designação Solutions Partner está ativa no ano corrente — selos antigos expiram e não são renovados automaticamente
- Verificar se a especialização avançada citada na proposta existe de fato no perfil oficial do parceiro
- Cruzar o nome do parceiro com a lista pública de Azure Expert MSPs, que é atualizada periodicamente
Essa checagem elimina o risco de contratar uma empresa que usa logotipos desatualizados ou credenciais de terceiros como se fossem próprias.
Metodologia de migração: como o parceiro conduz o projeto
A metodologia separa um parceiro estratégico de um executor de tarefas. O modelo mais maduro segue a estrutura do Cloud Adoption Framework da Microsoft, que organiza a migração em fases de estratégia, planejamento, prontidão, adoção e governança. O que muda entre os parceiros é o nível de rigor em cada fase e a disposição de documentar decisões, riscos e critérios de aceite.
Assessment, business case e plano de ondas
O assessment é a fase em que o parceiro descobre o que realmente existe no ambiente. Isso inclui inventário de máquinas virtuais, servidores físicos, bancos de dados, aplicações legadas, certificados digitais, rotinas de backup e integrações entre sistemas. Um assessment superficial — baseado apenas em planilha fornecida pelo cliente — tende a gerar um plano de migração com lacunas que só aparecem no meio da execução.
O business case traduz o achado técnico em números de decisão: custo atual de manutenção do datacenter, custo projetado no Azure, riscos de fim de suporte de sistemas operacionais e oportunidades de modernização. O plano de ondas, por sua vez, agrupa as cargas de trabalho em lotes migráveis, priorizando sistemas de menor risco no início e deixando os críticos — como bases de dados transacionais de Pix — para ondas posteriores, com janelas mais controladas.
Ferramentas nativas usadas (Azure Migrate, Site Recovery, Data Box)
O Azure Migrate é o hub central de descoberta e avaliação. Ele coleta dados de desempenho, mapeia dependências e gera recomendações de dimensionamento para as máquinas virtuais no Azure. Um parceiro competente usa essa ferramenta como base, mas sabe interpretar os resultados — por exemplo, identificando quando a recomendação automática subdimensiona uma carga com picos de processamento em horários específicos.
O Azure Site Recovery atua na replicação de máquinas virtuais durante a migração, permitindo testar o ambiente no Azure antes do cutover definitivo. Para volumes massivos de dados, o Azure Data Box resolve o problema de transferência física: a Microsoft envia um appliance criptografado, o parceiro carrega os dados localmente e o equipamento retorna para ingestão no datacenter da Microsoft. Em cenários com dezenas de terabytes e links de internet limitados, essa é a rota mais realista.
Estratégias de cutover, janelas de mudança e rollback
Cutover é o momento em que a operação deixa o ambiente de origem e passa a rodar no Azure. Um parceiro experiente define esse ponto com base em testes de replicação, validação de dados e um runbook detalhado que especifica quem executa cada ação, em que ordem e com qual critério de sucesso. Janelas de mudança para sistemas críticos costumam ser negociadas fora do horário comercial, com comunicação prévia às áreas de negócio.
O plano de rollback é a prova de maturidade do parceiro. Ele precisa descrever como retornar ao ambiente de origem caso a migração falhe, quanto tempo isso leva e quais dados podem ser afetados. Parceiros que não apresentam plano de rollback documentado — ou que tratam o tema como detalhe — representam risco inaceitável para operações sensíveis, incluindo processamento de transações financeiras.
Escopo do serviço: o que está incluído e o que fica de fora
A clareza de escopo é o principal fator de previsibilidade em uma migração Azure. Propostas genéricas, que prometem "migrar o ambiente" sem especificar quantos servidores, quais aplicações e qual nível de responsabilidade por cada camada, tendem a gerar aditivos contratuais e atrito durante a execução. O ideal é que o escopo detalhe entregas por fase, com critérios objetivos de aceite.
Descoberta, dependências e mapeamento de aplicações
O escopo de descoberta precisa responder a perguntas específicas: quantas cargas de trabalho serão inventariadas, quais fontes de dados serão consultadas, como serão tratadas as aplicações sem documentação e quem valida o mapa de dependências. Aplicações legadas sem dono claro — comuns em empresas de médio e grande porte — costumam ser o maior obstáculo nessa fase.
O mapeamento de dependências identifica o que conversa com o quê: um servidor de aplicação que depende de um banco de dados específico, uma rotina de integração que roda em horário determinado, um serviço que usa autenticação via protocolo legado. Ignorar essas conexões gera falhas silenciosas após a migração, do tipo que só é descoberta quando um processo de fim de mês não roda.
Identidade, rede, segurança e conformidade (LGPD)
Identidade é a fundação de qualquer ambiente Azure bem arquitetado. O parceiro precisa definir como o Active Directory local será integrado ao Entra ID, quais políticas de acesso condicional serão aplicadas e como os privilégios administrativos serão segregados. Em ambientes financeiros, essa camada inclui autenticação multifator obrigatória, revisão periódica de acessos e trilhas de auditoria que permitam reconstruir qualquer ação relevante.
A conformidade com a LGPD atravessa o desenho de rede e segurança. Dados pessoais e dados sensíveis — como informações de transações via Pix — exigem definição clara de onde residem, quem acessa e como são protegidos em repouso e em trânsito. O parceiro deve demonstrar como a arquitetura atende aos princípios de finalidade, necessidade e segurança previstos na legislação brasileira, sem prometer eliminação absoluta de riscos — algo que nenhuma tecnologia entrega.
Modernização, containers e banco de dados após a migração
Migrar para o Azure não significa apenas mover máquinas virtuais para a nuvem. O escopo pode incluir modernização de aplicações para containers, adoção de serviços gerenciados como Azure Kubernetes Service e migração de bancos de dados SQL Server para Azure SQL ou instâncias gerenciadas. Essas decisões afetam custo, desempenho e a complexidade operacional do ambiente.
Para bancos de dados críticos, a estratégia de migração precisa considerar janelas de indisponibilidade, replicação e testes de consistência. Um parceiro que propõe modernizar um banco transacional de alto volume sem plano de contingência está priorizando o discurso de modernização em detrimento da estabilidade operacional — um erro caro em ambientes que processam pagamentos.
Experiência comprovada: como ler casos e referências sem se enganar
Casos de sucesso publicados em sites de parceiros são material de marketing, não evidência técnica. Eles servem para indicar setores e portes já atendidos, mas não substituem a validação direta com clientes. A leitura crítica de um case exige atenção ao que não está escrito: quantas cargas de trabalho foram migradas, em quanto tempo, com qual nível de indisponibilidade e quais problemas surgiram no caminho.
Projetos semelhantes ao seu setor e porte
A semelhança de setor importa mais do que o número total de projetos. Uma empresa que processa transações via Pix tem requisitos de segurança, auditoria e disponibilidade diferentes de uma indústria que migra sistemas administrativos. Um parceiro com dez migrações em varejo pode não ter a menor familiaridade com as exigências de um ambiente financeiro regulado.
O porte também é relevante. Migrar 20 servidores é um projeto de complexidade distinta de migrar 300 cargas de trabalho com integrações entre filiais, datacenters e serviços de terceiros. Pergunte ao parceiro qual foi o maior projeto já conduzido, quantas ondas foram executadas e qual o tempo total entre o assessment e a última migração.
Perguntas a fazer nas referências de clientes
Referências de clientes são a fonte mais subestimada de informação em processos de seleção de parceiros. O segredo está nas perguntas — genéricas geram respostas genéricas. Um roteiro eficaz inclui:
- Qual foi o desvio entre o cronograma prometido e o cronograma real da migração?
- Quantos incidentes não planejados ocorreram durante as janelas de cutover?
- O custo final ficou dentro do que foi estimado no business case inicial?
- Como o parceiro reagiu quando algo saiu do planejado — houve escalonamento ágil ou demora na resposta?
- O time interno conseguiu operar o ambiente após a transferência de conhecimento ou ficou dependente do parceiro?
- Quais itens do escopo precisaram de aditivo contratual e por quê?
Essas perguntas revelam padrões de comportamento que nenhum case de marketing mostra. Um cliente que responde com hesitação sobre custos ou incidentes está dando um sinal tão valioso quanto uma resposta detalhada e transparente.
Time, governança e modelo de relacionamento
A qualidade de uma migração Azure depende menos da marca do parceiro e mais das pessoas que executam o projeto. Um parceiro com selos impressionantes e um time júnior alocado ao seu projeto entrega menos que um parceiro com credenciais modestas e arquitetos experientes dedicados à sua migração. A estrutura de equipe precisa estar explícita na proposta.
Quem executa: arquitetos certificados, squads e parceiros terceirizados
Pergunte quem serão os profissionais alocados: quantos arquitetos de solução, quantos engenheiros de cloud, qual a senioridade de cada um e quais certificações técnicas eles possuem. Certificações como Azure Solutions Architect Expert ou Azure Security Engineer Associate indicam formação técnica, mas não substituem experiência prática em projetos semelhantes ao seu.
Um ponto frequentemente negligenciado é a subcontratação. Alguns parceiros terceirizam partes da execução para outras empresas, o que dilui a responsabilidade e dificulta a governança. Se houver subcontratação, ela deve ser declarada na proposta, com definição clara de quem responde por cada entrega e quem é o responsável final perante o contrato.
Papéis, SLAs, escalonamento e gestão de mudanças
A governança de um projeto de migração exige papéis definidos dos dois lados. Do lado do parceiro, um gerente de projeto dedicado e um arquiteto responsável técnico. Do lado do cliente, um sponsor com poder de decisão e um ponto focal técnico que conheça o ambiente. Sem esses papéis, decisões críticas ficam paradas em reuniões sem dono.
Os SLAs precisam ser realistas e mensuráveis. Tempo de resposta para incidentes, disponibilidade do ambiente durante a migração e prazo para correção de desvios são exemplos de métricas que devem constar no contrato. A matriz de escalonamento — quem acionar quando o problema não é resolvido no primeiro nível — também precisa estar documentada, assim como o processo de gestão de mudanças para alterações de escopo durante o projeto.
O que define o custo de um projeto de migração Azure
O custo de uma migração Azure não é uma variável única, mas o resultado de uma combinação de fatores que incluem complexidade do ambiente, número de cargas de trabalho, nível de modernização desejado e profundidade dos serviços de governança. Comparar propostas apenas pelo valor total é o erro mais comum — e o mais caro — em processos de seleção.
Modelos de contratação: projeto fechado, alocação e managed services
O modelo de projeto fechado define um escopo fixo com preço fixo, adequado quando o ambiente é conhecido e estável. O modelo de alocação de horas — também chamado de time allocation — é flexível e se ajusta a ambientes com muitas incertezas, mas transfere parte do risco de variação de escopo para o cliente. O modelo de managed services entra após a migração, com monitoramento contínuo, gestão de custos e operação do ambiente.
Cada modelo tem implicações contratuais distintas. No projeto fechado, qualquer descoberta fora do escopo vira aditivo. Na alocação, o cliente paga pelo tempo consumido, o que exige disciplina de gestão. No managed services, a receita é recorrente e o parceiro assume responsabilidade operacional de longo prazo — o que muda completamente o critério de seleção.
Como comparar propostas sem cair em escopo subdimensionado
Escopo subdimensionado é a estratégia mais comum para vencer concorrências com preço baixo. A proposta omite itens que inevitavelmente serão necessários — como migração de bancos de dados, configuração de segurança ou transferência de conhecimento — e os cobra como aditivo depois que o cliente já está comprometido com o parceiro.
Para comparar propostas de forma justa, normalize o escopo antes de olhar o preço:
- Verifique se todas as propostas incluem as mesmas fases: assessment, planejamento, execução e otimização
- Confirme se o número de cargas de trabalho é idêntico em todas as propostas
- Cheque se itens como segurança, identidade e conformidade estão detalhados ou apenas citados
- Compare o nível de senioridade da equipe alocada em cada proposta
- Identifique o que está fora do escopo em cada uma e estime o custo desses itens
Uma proposta com preço 30% menor que a concorrente quase sempre esconde algum item relevante fora do escopo. A pergunta correta não é "quanto custa", mas "o que exatamente está incluído neste valor".
Suporte pós-migração, otimização e FinOps
A migração não termina no cutover. O ambiente Azure precisa ser operado, monitorado e otimizado continuamente — e é nesse ponto que muitos projetos falham silenciosamente. Um parceiro que entrega a migração e desaparece deixa o cliente com uma fatura mensal crescente e sem capacidade interna para controlá-la.
Well-Architected Review e ajuste de custos contínuo
O Well-Architected Review é uma avaliação estruturada do ambiente Azure em cinco pilares: otimização de custos, excelência operacional, eficiência de desempenho, confiabilidade e segurança. Um parceiro maduro conduz essa revisão periodicamente, identifica desvios e propõe correções — como redimensionamento de máquinas superdimensionadas, adoção de instâncias reservadas e eliminação de recursos ociosos.
FinOps é a disciplina de gestão financeira da nuvem. Ela envolve visibilidade de custos por área, definição de orçamentos, alertas de estouro e otimização contínua. Para empresas que migram dezenas de cargas de trabalho, a ausência de FinOps significa perda de controle sobre o gasto mensal — um problema que se acumula silenciosamente e só aparece quando a fatura já está fora do esperado.
Transferência de conhecimento e capacitação do time interno
A transferência de conhecimento é o que separa um parceiro que quer um cliente de longo prazo de um parceiro que quer dependência permanente. Ela inclui documentação da arquitetura, runbooks operacionais, treinamento do time interno e sessões de acompanhamento pós-migração. O objetivo é que a empresa cliente ganhe autonomia progressiva para operar o ambiente.
Ambientes sensíveis, como os que processam transações via Pix, têm um desafio adicional: o conhecimento sobre segurança e conformidade precisa ficar registrado, não apenas na cabeça de quem executou. Documentação de políticas de acesso, procedimentos de resposta a incidentes e configurações de monitoramento são entregas obrigatórias — e devem constar no escopo desde o início. Se o parceiro não se compromete com essa transferência, o custo de saída futura será alto demais.
Sinais de alerta e checklist final de decisão
A decisão de contratar um parceiro Microsoft para migração Azure é institucional e tem ciclo longo. Errar na escolha significa retrabalho, custo adicional e, em ambientes financeiros, exposição regulatória. Por isso, os sinais de alerta precisam ser identificados cedo — de preferência, antes da assinatura do contrato.
Red flags: promessas vagas, escopo genérico e dependência excessiva
Promessas de "migração sem downtime" ou "proteção total contra ataques" são sinais imediatos de alerta. Nenhuma migração de ambiente complexo elimina completamente o risco de indisponibilidade, e nenhuma tecnologia garante segurança absoluta — especialmente em ambientes que lidam com dados sensíveis e transações via Pix. Parceiros sérios falam em redução de risco, janelas controladas e planos de contingência.
Outros sinais de alerta incluem:
- Proposta com escopo genérico, sem especificar número de cargas de trabalho ou fases detalhadas
- Ausência de plano de rollback documentado
- Resistência a fornecer referências de clientes para contato direto
- Equipe alocada sem nomes, senioridade ou certificações declaradas
- Modelo de contratação que cria dependência permanente, sem transferência de conhecimento
- Promessa de custo final sem assessment prévio do ambiente
Esses sinais, isolados, não desqualificam automaticamente um parceiro. Mas a combinação de dois ou mais deles em uma proposta deve acender o alerta para uma análise mais profunda antes de avançar.
Checklist de avaliação para levar à reunião com o parceiro
Um checklist estruturado transforma a reunião de seleção em um processo objetivo, reduzindo o peso de impressões subjetivas. Leve estes pontos para a conversa:
- Designações Microsoft ativas e verificáveis no diretório oficial
- Especializações avançadas relevantes para a carga de trabalho que será migrada
- Metodologia detalhada por fase, com critérios de aceite definidos
- Plano de ondas com justificativa para a ordem de migração das cargas críticas
- Estratégia de cutover e plano de rollback documentados
- Tratamento de identidade, rede, segurança e conformidade com a LGPD
- Equipe alocada com nomes, senioridade e certificações
- Modelo de contratação e itens explicitamente fora do escopo
- SLAs, matriz de escalonamento e processo de gestão de mudanças
- Plano de transferência de conhecimento e capacitação do time interno
- Referências de clientes do mesmo setor e porte, com contato direto disponível
Um parceiro que responde a todos esses pontos com clareza — e que aceita ter as credenciais verificadas em fontes oficiais — demonstra o nível de transparência que um projeto de migração Azure exige. A confiança técnica se constrói com evidências, não com promessas.
