Migrando o Heroku Postgres sem janela de manutenção

Todo o resto de uma migração do Heroku é mecânico: as config vars são copiar e colar, o Procfile lê do mesmo jeito, os buildpacks fazem o build da aplicação sem mudar nada. O banco de dados é a única parte que realmente preocupa as pessoas, porque é a única parte onde “não funcionou” significa dados perdidos, não só um redeploy.

É mais tranquilo do que parece. Veja exatamente o que acontece.

O que o importador realmente faz

Applications → Import lê uma conta do Heroku a partir de um token de API e mostra um plano por aplicação antes de qualquer coisa rodar — o que vem automaticamente, o que você vai precisar adicionar você mesmo. Especificamente para o Heroku: as config vars, a formation completa (tipos de processo e suas contagens), e os add-ons de Postgres, Redis, MySQL e Memcached todos vêm junto, além dos domínios customizados.

A única coisa que a API do Heroku realmente não consegue entregar é a própria URL do Git — o Heroku não expõe o seu repositório, então esse é o único campo que você mesmo preenche durante a importação.

Como os dados realmente se movem

O banco de dados é copiado fazendo streaming de um dump direto do DATABASE_URL do Heroku para o novo banco de dados Postgres gerenciado na Railyard — não um pg_dump manual pra um laptop e de volta, mas um stream direto entre os dois. Isso importa porque significa que não existe um arquivo de várias horas parado no disco de alguém sendo a única cópia dos dados de produção no meio da migração.

A sequência que de fato evita downtime:

1. Rode a importação. A nova aplicação já existe, configurada, com o próprio banco de dados novo já em streaming a partir do antigo.
2. Mantenha a aplicação do Heroku rodando o tempo todo. Nada na importação a interrompe.
3. Quando o novo DATABASE_URL responder corretamente e você tiver verificado contra o antigo, mude o DNS.
4. Só então suspenda os dynos do Heroku — depois do cutover, não antes.

Não existe janela de manutenção pra agendar porque não existe um momento em que nenhum dos dois bancos está servindo tráfego. O antigo continua respondendo até o novo estar comprovado, e a própria troca é uma mudança de DNS, não um evento de downtime.

O que ainda precisa de uma pessoa

Os secrets armazenados como config vars do Heroku vêm junto com todo o resto — mas se a sua aplicação busca credenciais de algum lugar que a API do Heroku não expõe (um valor injetado por buildpack, algo definido totalmente fora das config vars), isso é responsabilidade sua checar de novo. E se o banco de dados tem extensões além do Postgres padrão — pgvector, PostGIS — confirme que o destino tem suporte a elas antes do cutover, não depois.

Pelo caminho mais rápido, a saída de heroku config -s cola direto em Variables → Bulk import se você estiver fazendo alguma parte disso manualmente em vez de pelo importador.

Mapeamento completo pra cada plataforma de origem: Import from Heroku, Render, Fly or Railway e o passo a passo completo em Migrating from Heroku.