--- title: "Perguntas a um parceiro de migração cloud antes de assinar" description: "Perguntas a um parceiro de migração cloud: inventário, estratégia por aplicação, landing zone, segurança, transição e reversão, custos e passagem de testemunho." canonical: https://sdk.enterprises/pt/insights/questions-before-hiring-a-cloud-migration-partner language: pt --- # Perguntas a um parceiro de migração cloud antes de assinar Atualizado a: 2026-09-26 > Antes de assinar com um parceiro de migração para a cloud, pergunte como vai inventariar o que a empresa tem em funcionamento, escolher uma estratégia de migração para cada aplicação, desenhar e proteger o ambiente de destino, reverter cada transição, mostrar os custos e preparar a equipa interna para operar o resultado. Respostas concretas e escritas dizem mais sobre a migração que se segue do que a tarifa diária. ## Perguntar como vão descobrir o que realmente está em funcionamento Um plano de migração só vale o inventário que tem por trás. Pergunte ao parceiro como o vai construir: a partir de entrevistas com os responsáveis pelas aplicações, de dados de infraestrutura como métricas de servidores e ligações de rede, do próprio código, ou das três fontes. A documentação existente é um ponto de partida, não uma prova, porque se vai afastando do que realmente está em funcionamento. Pergunte o que o inventário vai registar e a quem pertence depois. Uma boa resposta enumera os campos e confirma que o inventário fica com o cliente, seja qual for a decisão seguinte. - Cada aplicação, o seu responsável de negócio e o seu grau de criticidade - Runtimes, frameworks e sistemas operativos, com tudo o que estiver em fim de vida assinalado - Bases de dados, partilhas de ficheiros, tarefas agendadas e filas de que cada aplicação depende - Integrações nos dois sentidos, incluindo as que ninguém documentou - Licenças associadas ao hardware ou ao número de processadores que podem não transitar para a cloud - Indisponibilidade aceitável e calendário do negócio: fecho do mês, época alta, prazos regulamentares ## Esperar uma estratégia por aplicação, não uma para todo o parque As aplicações passam para a cloud de formas diferentes. As opções habituais são realojar uma aplicação tal como está (lift and shift), fazer um replatform com pequenas alterações, como uma base de dados gerida, refatorizá-la para usar serviços cloud, substituí-la por um produto em modo SaaS, mantê-la onde está por agora, ou desativá-la. Um parceiro que propõe a mesma abordagem para tudo não olhou com atenção suficiente. Peça os critérios que usa para escolher, e peça para os ver aplicados a três ou quatro das suas aplicações antes de assinar. O raciocínio sobre os sistemas reais diz mais do que um diapositivo de metodologia. Pergunte em especial como trata as aplicações em runtimes em fim de vida, porque mudá-las sem alterações leva os riscos antigos para a nova plataforma. ## Saber quem desenha e protege a landing zone A landing zone é o ambiente de destino preparado: estrutura de contas, identidade e acessos, rede, registos, cifragem e as salvaguardas que todas as aplicações herdam. Um erro aqui repete-se em cada aplicação que lá assenta. Pergunte quem a desenha, se é definida como código, por exemplo com Terraform, e se a equipa de segurança interna a revê antes de a primeira aplicação mudar. A segurança na cloud é partilhada. O fornecedor protege a infraestrutura subjacente, e o cliente continua responsável pela forma como a configura e utiliza. Pergunte ao parceiro que controlos vai implementar, quais ficam a cargo da equipa interna, e como os acessos dos seus próprios engenheiros são concedidos, registados e retirados no fim. - Contas ou projetos separados por ambiente, com a produção isolada - Autenticação única (SSO) com utilizadores nominais e funções de privilégio mínimo, sem credenciais de administrador partilhadas - Registos centralizados e trilhos de auditoria que os engenheiros do projeto não conseguem desligar - Cifragem em repouso e em trânsito por omissão, com os segredos fora do código - Regiões escolhidas para cumprir as obrigações de localização dos dados e do RGPD ## Pedir que expliquem uma transição e uma reversão passo a passo A transição é o momento em que o tráfego e os dados passam para o novo ambiente, e é aí que a migração fica mais visível para o negócio. Peça ao parceiro que descreva passo a passo a transição de uma das suas aplicações: como são sincronizados os dados, como é mudado o tráfego, que verificações correm depois e quem decide que correu bem. Depois, pergunte como voltaria atrás. Um plano credível indica as condições que desencadeiam uma reversão, a pessoa que toma a decisão e durante quanto tempo o ambiente antigo continua disponível. Se os utilizadores escreveram dados no novo ambiente desde a mudança, pergunte como esses dados regressam ao antigo. Os planos fracos saltam essa pergunta. O nosso artigo sobre a migração de centenas de aplicações legadas para a AWS mostra como estes passos se tornam runbooks num parque de grande dimensão. ## Exigir ver os custos antes de chegar a primeira fatura Os custos da cloud comportam-se de forma diferente dos de um centro de dados. Paga-se o que está a correr, incluindo ambientes de teste que ninguém desligou, armazenamento que não para de crescer e dados transferidos para fora da rede do fornecedor. Peça uma estimativa de custos por aplicação com os pressupostos por escrito, e pergunte como o parceiro a vai comparar com a utilização real nos primeiros meses. A visibilidade dos custos é uma decisão de desenho, não um relatório mensal. Peça regras de etiquetagem que associem cada recurso a uma aplicação e a um responsável, orçamentos e alertas desde o primeiro dia, e uma revisão da dimensão das instâncias quando as aplicações já tiverem corrido sob carga real. Dimensionar os servidores cloud à imagem do hardware antigo é uma forma segura de pagar capacidade que ninguém usa. ## Sinais de alerta de que uma proposta de migração não está pronta Qualquer um destes sinais pode ter explicação. Vários na mesma proposta costumam significar que o risco ficou para o cliente descobrir. - Um calendário fixo antes de alguém ter visto o inventário - Uma única estratégia de migração aplicada a todas as aplicações - Nenhum plano de reversão escrito, ou uma reversão que depende de restaurar cópias de segurança sob pressão - Contas cloud, código de infraestrutura ou pipelines detidos pelo parceiro e não pelo cliente - Estimativas de custos sem pressupostos, e nenhum plano de etiquetagem ou de orçamentos - Transferência de conhecimento marcada para a última semana ## Planear a transferência de conhecimento desde a primeira semana, não na última A migração termina; a operação da plataforma não. Pergunte como a equipa interna vai aprender a operar o que for construído: trabalho em par em tarefas reais durante a migração, runbooks para as operações recorrentes, e uma apresentação da monitorização e dos alertas às pessoas que vão estar de prevenção. Peça que tudo fique nas contas e nos repositórios do cliente desde o início: código de infraestrutura, pipelines, runbooks e diagramas. Depois, combine como é aceite a passagem de testemunho, por exemplo a equipa interna faz o deploy e a reversão de uma aplicação sem a ajuda do parceiro. Trabalhámos na equipa que levou 600+ aplicações internas do Crédit Agricole de VM legadas para a AWS, tendo realizado nós próprios 50+ dessas migrações. Se pretende uma segunda opinião sobre uma proposta de migração, ou uma equipa para realizar parte do trabalho, os nossos engenheiros de infraestrutura cloud podem analisar estas perguntas consigo. ## Pontos essenciais - Perguntar como o inventário vai ser construído e verificado, porque todas as estimativas e o plano de vagas dependem dele. - Esperar uma estratégia de migração escolhida por aplicação, com critérios que se possam ver aplicados aos próprios sistemas. - Ter a landing zone definida como código, revista pela equipa de segurança interna e guardada nas contas do cliente. - Não aceitar um plano de transição sem um critério de reversão com responsável identificado e uma forma de recuperar os dados escritos depois da mudança. - Combinar a etiquetagem, os orçamentos e a forma de aceitar a passagem de testemunho antes de a primeira aplicação mudar. ## Perguntas frequentes ### O parceiro que avalia o parque deve ser também o que o migra? Pode ser, e muitas vezes poupa tempo, porque a equipa que construiu o inventário conhece os casos-limite. Compre a avaliação como um entregável à parte, que fica com a empresa, para a poder levar a outro parceiro se a proposta de migração não convencer. ### Como comparar propostas de diferentes parceiros de migração? Dê a todos os parceiros o mesmo extrato do inventário e as mesmas perguntas, e peça a cada um que aplique os seus critérios às mesmas poucas aplicações. Compare o raciocínio, os planos de reversão e os pressupostos por trás das estimativas, e não apenas o preço total. ### A equipa pode continuar a lançar funcionalidades durante a migração? Sim, se o plano disser como. Combine uma janela de congelamento de alterações para cada aplicação, uma forma de manter os dois ambientes sincronizados enquanto ela muda e quem aprova as entregas em produção enquanto uma aplicação está em trânsito. ## Serviços relacionados - [Migração para a cloud](https://sdk.enterprises/pt/services/cloud-infrastructure) - [Auditoria técnica e consultoria](https://sdk.enterprises/pt/services/consulting) ## Para saber mais - [Migrar centenas de aplicações legadas para a AWS sem travar](https://sdk.enterprises/pt/insights/migrating-hundreds-of-apps-to-aws) - [Perguntas a fazer antes de contratar um parceiro de software](https://sdk.enterprises/pt/insights/choosing-a-software-partner)