Como migrar de uma VPS para o Hangar: aplicação, dados e DNS

A migração termina quando a aplicação funciona no novo ambiente e seus dados estão consistentes. Copiar o repositório é apenas uma parte. Este roteiro separa preparação, ensaio e troca de tráfego para que você consiga avaliar cada etapa antes de avançar.

O destino considerado é uma aplicação web no Hangar, com PostgreSQL quando necessário. Dependências como outros motores de banco, tarefas agendadas, filas ou acesso ao sistema operacional precisam de uma decisão própria; não presuma equivalência com todos os processos da VPS.

Faça o inventário da aplicação

Registre o comando de início, a versão da linguagem, a porta, as variáveis, os domínios e as integrações. Liste também arquivos fora do repositório: uploads, certificados, tarefas do sistema e scripts de manutenção costumam ficar escondidos na máquina antiga.

Item	Decisão antes da migração
Código	Repositório, branch e Railpack ou Dockerfile
Banco	Versão, extensões, tamanho, permissões e conexões
Uploads	Diretórios que precisam de volume ou armazenamento externo
Integrações	Webhooks, endereços permitidos e credenciais
Operação	Responsável pela janela, validação e recuperação

Crie projeto, ambiente e serviço no Hangar. Escolha um plano considerando aplicação, banco, volumes e capacidade adicional necessária durante o ensaio. Confira que o destino suporta as extensões e o padrão de acesso de que você depende.

Ensaie a transferência dos dados

Para PostgreSQL, pg_dump em formato custom e pg_restore são ferramentas de exportação e importação. Use clientes compatíveis com as versões dos bancos e consulte a documentação de pg_dump e pg_restore.

Os comandos abaixo pressupõem serviços de conexão origem e destino já configurados em libpq, uma máquina autorizada com acesso aos dois bancos e um banco de destino novo e vazio. Configure credenciais e TLS sem colocá-los no repositório ou no histórico do terminal. A documentação de arquivos de serviço PostgreSQL explica essa configuração.

pg_dump --dbname=service=origem --format=custom --file=migracao.dump
pg_restore --list migracao.dump
pg_restore --dbname=service=destino --no-owner --no-acl --exit-on-error migracao.dump

Confirme o código de saída de cada comando antes do seguinte. O segundo lista o conteúdo; não prova que a restauração funciona. O terceiro importa os objetos sem reaplicar proprietários e permissões da origem, portanto revise os acessos depois. Proteja o arquivo de exportação e seu local de armazenamento.

Esse é um procedimento externo, não um recurso de backup do Hangar. Backup, restauração e recuperação pontual nativos do PostgreSQL ainda não estão disponíveis na plataforma.

Teste com dados de ensaio

Aponte as variáveis do novo serviço para o banco de teste. Publique e verifique login, leitura, gravação, uploads e as integrações essenciais. Evite disparar cobranças, emails ou webhooks reais durante o ensaio; use contas e configurações de teste dessas integrações.

Compare quantidades e amostras de dados importantes, permissões e sequências do banco. Meça quanto demorou a exportação e a importação para planejar sua janela com evidência do seu caso. Não existe uma duração universal para essa migração.

Planeje uma única origem de escrita

Para uma migração com pausa de gravações, combine uma janela e faça o seguinte:

1. Coloque a aplicação de origem em manutenção e interrompa todos os escritores, inclusive tarefas e integrações.
2. Gere a exportação final e restaure em um destino vazio preparado para o corte, não sobre a cópia usada no ensaio.
3. Configure a aplicação do Hangar para esse banco e repita as verificações essenciais.
4. Atualize o DNS conforme os registros fornecidos e confirme domínio e HTTPS.
5. Libere gravações apenas no novo destino e acompanhe erros, dados e tráfego.

Ajustar o TTL com antecedência pode reduzir a duração de caches, mas não garante troca instantânea em todos os clientes. Mantenha o destino antigo em manutenção ou encaminhando requisições de forma controlada para evitar duas bases recebendo escrita.

Defina recuperação antes de mudar o DNS

Enquanto o destino novo não recebeu gravações, a volta à origem pode ser mais simples. Depois de aceitar novos dados, apenas reverter DNS pode perdê-los. Defina como interromper escritas, reconciliar alterações e decidir qual base será a fonte correta.

Mantenha a origem preservada pelo período acordado para validação e retenção. Desative-a somente depois de confirmar os critérios de aceite, remover dependências antigas e documentar a recuperação. O Hangar concentra deploys, logs, métricas e ajustes de capacidade; código, consistência dos dados e o plano de migração continuam exigindo sua validação.

Para preparar o serviço antes do ensaio, siga o guia de primeiro deploy. Para necessidades de migração assistida, converse com o time sobre escopo e disponibilidade.