Migrar un SaaS de AWS a DigitalOcean con Claude Code

A quién le sirve. Programadores o dueños de un SaaS pequeño que quieren cambiar de proveedor de alojamiento para ahorrar y se manejan con servidores y GitHub; el método vale para cualquier otra migración entre proveedores.

Qué hicieron

El desarrollador pidió a Claude Code que construyera flujos de GitHub Actions (tareas automáticas) para preparar DigitalOcean: servidor virtual, base de datos Postgres gestionada, almacenamiento Spaces y Docker. Claude leyó los registros de las ejecuciones fallidas con la herramienta gh, encontró la causa y corrigió los flujos. Arregló el ajuste SSL de psql, reescribió las referencias de propietario del volcado de la base de datos, generó certificados de origen de Cloudflare para nginx y corrigió el proxy del enrutado de la aplicación.

Cómo salió

El autor dice que la migración llevó cuatro horas sin ninguna caída y que movió 29 tablas y más de 3.000 filas. El coste mensual bajó de unos 120 $ a unos 44 $. Las cuatro horas y la ausencia de caídas son afirmaciones suyas.

Conviene saber

Comprueba que los nombres de las variables de entorno coincidan con los que lee tu código. Una diferencia entre VITE_API_URL y VITE_API_BASE hizo que la parte visible llamara a localhost y le costó 20 minutos.

Qué necesitas

• Claude Code con un plan de pago de Claude
• Tu aplicación en un repositorio de GitHub, con la herramienta gh instalada, que sirve para usar GitHub desde la terminal
• Cuentas en el proveedor de origen y en el nuevo (AWS y DigitalOcean en el caso)
• Acceso a tu DNS, que es el sistema que dirige tu dominio a tu servidor, como Cloudflare
• Una copia de seguridad completa de la base de datos

Cómo hacerlo tú, paso a paso

1. Haz una copia de seguridad completa de la base de datos y de los archivos, y comprueba que puedes restaurarla.
2. Pega el prompt de esta ficha para que Claude Code revise el repositorio y escriba un plan paso a paso con preparación de servidores, migración de datos, SSL (el candado que cifra la conexión), cambio de DNS y vuelta atrás.
3. Pide que construya los flujos de GitHub Actions (tareas automáticas) que preparan el servidor nuevo, la base de datos gestionada, el almacenamiento y Docker (que empaqueta la aplicación para moverla de un servidor a otro).
4. Cuando un flujo falle, pide que lea los registros con la herramienta gh, encuentre la causa y lo corrija.
5. Migra la base de datos con un volcado y comprueba que las tablas y las filas coinciden con las del original.
6. Verifica SSL, el proxy (el intermediario que reparte las peticiones) y las variables de entorno en el servidor nuevo antes de tocar el DNS.
7. Cambia el DNS cuando todo funcione y mantén el servidor viejo unos días como plan B.

Actúa como mi compañero de programación para migrar mi aplicación de [alojamiento actual, por ejemplo AWS] a [alojamiento nuevo, por ejemplo DigitalOcean]. Primero revisa el repositorio y escribe un plan paso a paso que cubra la preparación de los servidores, la migración de la base de datos, el SSL, el cambio de DNS y cómo volver atrás. Avanza conmigo de paso en paso y, antes de cualquier cosa que toque producción, el DNS o borre datos, párate y enséñame el comando o el cambio.

Consejos

• Comprueba que los nombres de las variables de entorno, los ajustes que lee tu código, coinciden en el servidor nuevo: una diferencia mínima dejó la parte visible llamando a localhost.
• Las cuatro horas sin caídas son palabras del autor. Planifica con margen y con un plan de vuelta atrás.
• No dejes que toque producción, el DNS ni borre datos sin enseñarte antes el comando.

Preguntas frecuentes

Fuentes

• @anand_rathnas_d5b608cc3de en DEV ↗

En el directorio desde el 3 de octubre de 2026.