El VPS suele ser lo más viejo que tiene una empresa pequeña. Alguien lo configuró hace años y ya no trabaja ahí, corre la app de reservas o el portal de facturación, y nadie lo reinicia porque nadie está seguro de que vuelva a encender. Hasta que el proveedor avisa de una migración de hardware, o el disco se llena a las 2am, y la pregunta cae un martes: ¿podemos mover esto a Google Cloud sin cerrar un fin de semana?
Casi siempre sí, y el fin de semana no es lo importante. El orden sí. Todas las migraciones rotas que nos ha tocado arreglar fallaron en uno de dos puntos: se apuntó el tráfico a la máquina nueva mientras los datos venían atrás, o se cambió el DNS sin revisar cuánto seguiría el registro viejo en la caché de los resolvers. Con la secuencia correcta, el cambio es aburrido.
Qué leemos antes de que alguien toque el servidor
El primer día es inventario, no ingeniería. Anotamos qué procesos escuchan en qué puertos, con qué habla la app que no vive en esa máquina, cada cron y qué escribe, de dónde salen los certificados TLS, si el servidor manda correo por su cuenta, qué escribe en el disco local y si el sistema operativo todavía recibe actualizaciones de seguridad. Pongamos una empresa de logística de 12 personas con un solo VPS: casi siempre hay un cron olvidado que le manda un reporte al contador, y es justo lo que se rompe tres días después.
Luego una pregunta define el plan: ¿cuántos minutos de caída puede aceptar el negocio? La guía de migración de Google ata la estrategia a esa tolerancia y es directa con el costo: las cargas que no pueden aceptar caída necesitan enfoques de cero o casi cero downtime, más caros y más complejos de operar. Una tienda que recibe pedidos a las 11pm y un portal B2B que nadie abre el domingo son proyectos distintos.
Compute Engine, Cloud Run, o las dos cosas más adelante
La guía de Google para elegir una opción de cómputo es clara: Cloud Run sirve para aplicaciones en contenedores sin estado y se encarga del sistema operativo, el kernel, la red y la capacidad, mientras que Compute Engine es la opción cuando necesitas control del sistema operativo, las imágenes de disco, la CPU, la RAM y el disco, el camino típico para migrar una aplicación que ya existe.
El sistema de archivos decide el caso en casi todo VPS. Las instancias de Cloud Run no tienen estado, y cada contenedor recibe una capa de archivos en memoria que se puede escribir pero no persiste cuando el contenedor se apaga. Si tu app guarda en una carpeta los archivos que suben los clientes, mantiene sesiones en disco o corre sobre SQLite, todavía no es una app de Cloud Run. Puede llegar a serlo, pero eso es trabajo de aplicación con sus propias pruebas, y hacerlo la misma semana del traslado es la receta para que un corte de un día se vuelva tres semanas de problemas.
Nuestro camino por defecto para una app de negocio que ya funciona es Compute Engine primero, sacando la base de datos a Cloud SQL en el mismo movimiento. Aterrizarla, comprobarla, y después ir pasando piezas a Cloud Run cuando nada esté en llamas. Dos cambios a la vez significa que, cuando algo se rompe, no puedes saber cuál lo rompió.
Qué acepta y qué no acepta la herramienta de migración
Si buscas cómo migrar un servidor, te van a mandar a Migrate to Virtual Machines, que replica una VM de origen de forma continua y te deja armar un clon de prueba antes del corte. Es buena, y probablemente no aplica a tu caso: sus orígenes documentados son un centro de datos vSphere, AWS, Azure y Google Cloud VMware Engine. Un VPS en DigitalOcean, Linode, Hostinger o un hosting regional no es ninguno de esos, así que ese camino queda fuera.
Quedan dos opciones honestas. Reconstruir el servidor en una instancia nueva de Compute Engine a partir de tu configuración, instalando los paquetes y restaurando la aplicación y los datos con cada paso escrito. O importar el disco: la importación de discos virtuales de Compute Engine acepta archivos .vmdk y .tar.gz, solo VMDK monolítico, un disco de arranque a la vez, y el viejo comando gcloud compute images import está quedando obsoleto a favor de gcloud migration vms image-imports.
Nosotros reconstruimos siempre que podemos. Un disco importado se trae el kernel viejo, los paquetes viejos y todo lo que dejó el último administrador: pagaste una migración y te quedaste con cada problema que hacía temible al servidor. Reconstruir te obliga a averiguar qué necesita de verdad la máquina, que es la documentación que nadie escribió la primera vez.
La base de datos define tu ventana de corte
Si respaldas la base, copias el archivo y lo restauras, tu caída dura lo que duren ese respaldo y esa restauración, y crece con los datos. Está bien para una base pequeña y un domingo tranquilo. Para algo con más movimiento, Database Migration Service cambia la forma del problema: un trabajo de migración continua hace una carga inicial completa y después sigue replicando los cambios desde el origen. Cuando el destino es una instancia de Cloud SQL que ya existe, el servicio la degrada y la convierte en réplica de lectura mientras dura el trabajo.
El corte es entonces un solo paso llamado promoción, que desconecta el destino del origen y lo pasa de réplica a principal para que las bases migradas acepten lecturas y escrituras. La secuencia recomendada vale memorizarla: detener las escrituras en el origen, esperar a que el retraso de replicación llegue a cero, y promover. Google aclara que puedes promover antes de que llegue a cero para recortar la caída, con la advertencia honesta de que puede afectar la exactitud de los datos en el destino, y que las aplicaciones dependientes pueden tener una caída de al menos ese retraso de replicación.
Léelo como regla de planeación. Tu ventana de corte es el retraso de replicación, no el tamaño de la base. Si el retraso son cuatro segundos un miércoles a las 9am, no necesitas un fin de semana.
DNS: baja el TTL días antes de necesitarlo
Este paso se lo salta todo el mundo y no se puede arreglar el mismo día. La guía de Cloud DNS es explícita: si planeas un cambio que necesita una ventana corta, baja primero el TTL, porque el valor más corto solo aplica después de que venza el TTL anterior en la caché de los resolvers. Si tu registro A lleva meses en 24 horas, bajarlo esta mañana no sirve de nada durante las próximas 24 horas.
Tres cosas más sobre el día del DNS. Algunos resolvers ignoran tu TTL y usan el suyo, así que una cola lenta de tráfico hacia la IP vieja es normal y no una falla. Muchos resolvers guardan las respuestas negativas hasta 15 minutos, así que un error de dedo te cobra más tiempo del que toma corregirlo. Y Cloud DNS envía un cambio a sus servidores autoritativos en unos 120 segundos, así que mientras esperas consulta directo a esos servidores de nombres en lugar de preguntarle a un resolver público y adivinar.
La consecuencia: deja el servidor viejo encendido y alcanzable hasta que el tráfico a su IP de verdad se detenga. El TTL lo vuelves a subir una o dos semanas después.
El corte, en orden
Este es el plan en una página. La columna de la derecha es la compuerta: si no es cierta, no pasas a la fila siguiente, y esa regla es la que evita que un corte se convierta en un incidente.
| Cuándo | Qué hacemos | Qué debe ser cierto antes del siguiente paso |
|---|---|---|
| 7 días antes | Bajar el TTL de los registros que van a cambiar e inventariar a todo tercero que apunte a la IP vieja | El TTL anterior ya venció en todas partes, así que el valor corto ya está en vigor |
| 3 días antes | Construir las instancias de Compute Engine y Cloud SQL, restaurar una copia de los datos y correr la app de punta a punta en un host de prueba | Existe un ensayo cronometrado: sabes cuánto toma cada paso y la app responde recorridos reales |
| 1 día antes | Arrancar el trabajo de migración continua hacia Cloud SQL y dejarlo estabilizar | La replicación corre y el retraso es pequeño y estable |
| Hora cero | Poner la app en mantenimiento o solo lectura para que se detengan las escrituras en el origen | Ninguna escritura nueva llega a la base vieja y el retraso va bajando a cero |
| Cero más minutos | Promover el destino, apuntar la app a él y cambiar los registros DNS | Las pruebas de humo pasan en el camino nuevo y los servidores autoritativos responden con la dirección nueva |
| Cero más una hora | Vigilar logs, tasa de errores y el correo que manda la app, con el servidor viejo todavía encendido | Los errores están en su nivel normal y nada falla en silencio |
| 1 a 2 semanas después | Dar de baja el VPS viejo y volver a subir el TTL | Ya restauraste una vez los respaldos de la base nueva y ningún tráfico llega a la IP vieja |
Rollback, y la hora que le das
Las buenas prácticas de Google para validar un plan de migración piden dos cosas que los proyectos pequeños se saltan: una estrategia de rollback para cada paso, probada en lugar de supuesta, y un tiempo máximo de ejecución por paso, pasado el cual empiezas a revertir en vez de seguir empujando. Eso lo convertimos en un número escrito antes del día. Si el camino nuevo no sirve tráfico limpio a las 09:40, nos regresamos, y nadie tiene que decidirlo a las 09:38 con el dueño mirando.
Sé honesto con lo que cuesta regresarse. La guía de Google señala que revertir una migración puede costar más esfuerzo que arreglar hacia adelante, y que deshacer el movimiento de datos implica volver a copiarlos, razón por la cual conservas los datos del origen un tiempo después del corte. La línea real es la primera escritura: cuando ya cayeron pedidos en la base nueva, regresarse significa perderlos o unirlos a mano. Para eso existe la ventana de solo lectura.
Notas de costo y de riesgo
Un VPS es una cuota mensual fija y Google Cloud se mide por uso, así que la primera sorpresa suele ser una factura con forma en lugar de un número. En cada proyecto dejamos un presupuesto con umbrales de alerta el día uno, antes de que exista la primera instancia, y revisamos las tarifas vigentes en las páginas de precios de Google en lugar de confiar en cualquier blog, incluido este.
Dos riesgos que vale nombrar. Si la app manda correo directo desde el servidor, el camino nuevo de envío necesita su autenticación configurada, o la primera semana después del traslado será un problema de entregabilidad y no de hosting. Y el 19 de octubre de 2026 las notas de lanzamiento de Google registraron el apagado controlado de Compute Engine como disponible de forma general: viene desactivado, y al activarlo le da al sistema operativo huésped un periodo de gracia para terminar su trabajo cuando detienes o eliminas la instancia, con 10 minutos por defecto si no defines otro valor, y los scripts de apagado corren después de que ese proceso termina. En una máquina que escribe a una base de datos, es protección barata contra un apagón en el momento equivocado.
Cómo ayuda Guanacos Tech
Esto lo hacemos como un trabajo de alcance fijo: leer el VPS y escribir el inventario, elegir entre Compute Engine y Cloud Run con la pregunta del sistema de archivos contestada con honestidad, construir el destino, hacer un ensayo cronometrado y ejecutar el corte en una hora agendada con el tiempo de rollback acordado de antemano. Te queda el runbook, con las compuertas de la tabla de arriba llenas para tu stack. Ese trabajo va dentro de nuestra consultoría de Google Cloud. Agenda una llamada de 30 minutos si quieres una segunda opinión sobre un traslado que ya estás planeando, y te decimos dónde creemos que va a doler.
Fuentes
- Google Cloud: choose compute options
- Google Cloud: what is Cloud Run
- Google Cloud: Migrate to Virtual Machines architecture and sources
- Google Cloud: import virtual disks to Compute Engine
- Google Cloud: promote a Database Migration Service migration job
- Google Cloud: Cloud DNS overview (TTL and caching)
- Google Cloud: best practices for validating a migration plan
- Google Cloud: Compute Engine graceful shutdown overview