Migrar uma aplicação para uma VPS não é apenas colocar o código em um container. Banco de dados, autenticação, arquivos, variáveis de ambiente e serviços externos fazem parte do comportamento do sistema. Uma transição confiável precisa inventariar essas dependências e validar o destino antes de alterar o domínio.
Ter acesso ao repositório não significa ter acesso a todos os dados. O código pode conter a estrutura do banco, enquanto os registros, usuários e arquivos permanecem em serviços separados.
Faça um inventário de aplicação e dados
Liste o comando de build, a forma de execução e as versões necessárias. Identifique se a aplicação usa renderização no servidor, tarefas agendadas, funções externas ou recursos específicos da plataforma de origem.
No banco, diferencie estrutura, dados e políticas de acesso. Na autenticação, confira usuários, provedores e URLs de retorno. No armazenamento, verifique tanto os metadados quanto os arquivos reais. Uma lista de nomes de arquivos não substitui a transferência dos objetos.
Prepare backup e retorno antes do corte
Guarde cópias recuperáveis da origem e registre o procedimento de restauração. Um backup só oferece confiança quando seu conteúdo pode ser validado. Faça uma restauração de teste sempre que o contexto permitir.
Defina também a janela de alterações. Se a origem continuar recebendo registros durante a importação, será necessário sincronizar a diferença ou estabelecer um período de bloqueio de gravações. Caso contrário, o destino pode entrar no ar com dados incompletos.
Valide o ambiente de destino
Antes de trocar DNS, teste o site em um endereço de homologação. Verifique navegação, consultas, formulários, login, permissões e arquivos. Confirme que chaves administrativas não estão presentes no código entregue ao navegador.
Para ambientes Supabase, a documentação de backup e restauração orienta avaliar separadamente os componentes da migração. Banco e objetos de Storage não devem ser presumidos como uma cópia única. Confira também as configurações de autenticação aplicáveis ao destino.
Faça o corte de domínio com o serviço preparado
Configure o proxy para aceitar os nomes públicos e planeje a emissão do certificado TLS. Verifique registros A e AAAA, quando existirem, para evitar que parte dos acessos vá para um destino diferente. Preserve registros de e-mail e verificações de outros serviços.
O cache DNS pode manter respostas antigas por algum tempo. Depois da alteração, confira o provedor e resolvedores públicos, além de testar o acesso ao IP de destino com o nome correto do domínio.
Confira mais do que a página inicial
- Rotas internas e páginas não encontradas.
- Autenticação e perfis de acesso.
- Leitura e gravação de dados autorizados.
- Download e upload de arquivos.
- Integrações, e-mails transacionais e tarefas agendadas.
- Redirecionamentos, certificado e URLs canônicas.
- Logs, monitoramento e procedimento de restauração.
Mantenha a operação depois da mudança
Defina responsáveis por atualizações, backups, alertas e renovação dos certificados. Documente como publicar uma nova versão e como voltar à anterior. Evite depender de um artefato temporário que não possa ser reconstruído.
Uma migração pode ser uma oportunidade para revisar integrações, mas mudanças funcionais grandes devem ser separadas sempre que dificultarem a identificação de falhas. Para discutir seu ambiente, fale com a A2CR com a lista de serviços e acessos disponíveis.
