Migrar Heroku Postgres sin una ventana de mantenimiento

Cada otra parte de una migración desde Heroku es mecánica: las config vars se copian y pegan, el Procfile se lee igual, los buildpacks construyen la app sin cambios. La base de datos es la única pieza que de verdad preocupa a la gente, porque es la única pieza donde “no funcionó” significa datos perdidos, no solo un redeploy.

Es más aburrido de lo que suena. Esto es exactamente lo que pasa.

Qué hace el importador en realidad

Applications → Import lee una cuenta de Heroku a partir de un token de API y muestra un plan por app antes de que corra nada — qué se traslada, qué vas a tener que agregar tú mismo. Para Heroku específicamente: las config vars, la formación completa (tipos de proceso y sus cantidades), y los add-ons de Postgres, Redis, MySQL y Memcached se trasladan todos, junto con los dominios personalizados.

Lo único que la API de Heroku de verdad no puede entregar es la propia URL de Git — Heroku no expone tu repositorio, así que ese es el único campo que tú mismo provees durante la importación.

Cómo se mueven los datos en realidad

La base de datos se copia transmitiendo un dump directamente desde el DATABASE_URL de Heroku hacia la nueva base de datos Postgres administrada en Railyard — no un pg_dump manual a una laptop y una subida de vuelta, sino un stream directo entre las dos. Eso importa porque significa que no hay un archivo de varias horas sentado en el disco de alguien como la única copia de los datos de producción a mitad de la migración.

La secuencia que de verdad evita el downtime:

1. Corre la importación. La app nueva ya existe, configurada, con su propia base de datos nueva ya transmitiendo desde la vieja.
2. Deja la app de Heroku corriendo todo el tiempo. Nada en la importación la detiene.
3. En cuanto el nuevo DATABASE_URL responde correctamente y lo verificaste contra el viejo, mueve el DNS.
4. Solo entonces suspende los dynos de Heroku — después del cutover, no antes.

No hay ventana de mantenimiento que programar porque no hay ningún momento en que ninguna de las dos bases de datos esté sirviendo tráfico. La vieja sigue respondiendo hasta que la nueva queda comprobada, y el cambio en sí es un cambio de DNS, no un evento de downtime.

Qué todavía necesita una persona

Los secretos guardados como config vars de Heroku se trasladan junto con todo lo demás — pero si tu app toma credenciales de algún lugar que la API de Heroku no expone (un valor inyectado por un buildpack, algo definido totalmente fuera de las config vars), eso te toca a ti volver a revisarlo. Y si la base de datos tiene extensiones más allá del Postgres de fábrica — pgvector, PostGIS — confirma que el destino las soporte antes del cutover, no después.

Para el camino más rápido, la salida de heroku config -s se pega directamente en Variables → Bulk import si estás haciendo alguna parte de esto a mano en vez de a través del importador.

Mapeo completo para cada plataforma de origen: Importar desde Heroku, Render, Fly o Railway y el recorrido completo en Migrar desde Heroku.