Rendimiento y datos
Migración de Heroku a Google Cloud
Heroku tuvo sentido cuando lanzaste. Si la factura, la acumulación de add-ons o la lista de regiones dejó de tenerlo, el paso a Cloud Run es un contenedor y un pipeline — no una reescritura. Lo planeamos, lo ejecutamos y te dejamos con la opción de volver atrás.
La misma app, sobre un runtime que sí controlas
Un dyno de Heroku y un servicio de Cloud Run hacen lo mismo: correr tu contenedor, escalarlo y ponerle una URL delante. La mayoría de las aplicaciones Node.js se mueven sin tocar su código. Lo que cambia es todo lo que rodea al código: cómo se construye, de dónde salen los secretos, con qué identidad corre y qué pasa cuando un despliegue sale mal.
Esa capa de alrededor es el trabajo completo. Contenerizamos la app, conectamos GitHub con Cloud Build y Artifact Registry, sacamos la configuración de las variables del dyno hacia Secret Manager, le damos al servicio su propia identidad de IAM en lugar de una llave compartida, y dejamos la app de Heroku corriendo hasta que la nueva se haya ganado el lugar.
- Sin reescritura
- Una app Node de doce factores está a un contenedor de Cloud Run. Cambiamos el build y la configuración, no la aplicación.
- Reversible por diseño
- La app de Heroku sigue arriba y el DNS sigue conmutable hasta que Cloud Run haya servido tráfico real. Volver atrás es una decisión, no un incidente.
- Los secretos dejan de ser variables
- La configuración pasa a Secret Manager con acceso acotado por IAM, así las credenciales dejan de ser legibles para cualquiera con acceso al panel.
Lo que cubre el trabajo
- Auditoría de dynos, add-ons, buildpacks y config vars actuales
- Contenerización y un build reproducible
- Pipeline GitHub → Cloud Build → Artifact Registry → Cloud Run
- Secret Manager para credenciales, con service account de runtime dedicada
- Health checks, logging y una ruta de rollback documentada
- Plan de cutover y ventana de operación en paralelo antes de mover el DNS
Tecnologías
- Google Cloud Run
- Cloud Build
- Artifact Registry
- Secret Manager
- IAM
- Node.js
- Docker
- GitHub
Dónde ayuda más
La factura creció más que la app
Las horas de dyno y los add-ons de pago superaron lo que justifica la carga, y quieres un runtime que escale a cero entre picos de tráfico.
Una API de ecommerce detrás de una tienda
Un servicio Node.js del que depende tu tienda necesita un modelo de despliegue con trazabilidad de build, secretos gestionados e identidad por servicio.
Necesitas una región, una VPC o una historia de IAM
Cumplimiento, latencia o una revisión de seguridad piden algo que el modelo de dynos no ofrece.
Cómo lo entregamos
Inventario
Listamos cada dyno, add-on, job programado y config var, y marcamos cuáles sostienen carga, cuáles están muertos y cuáles tienen equivalente gestionado en Google Cloud.
Contenerizar
La app recibe un Dockerfile y un build que produce la misma imagen en local y en CI, para que lo que pruebas sea lo que se despliega.
Conectar el pipeline
GitHub dispara Cloud Build, las imágenes llegan a Artifact Registry, Cloud Run despliega la revisión, y el servicio corre con su propia identidad IAM leyendo de Secret Manager.
Correr en paralelo y cortar
Ambos entornos corren mientras comparamos comportamiento y logs. El DNS se mueve al final, y la app de Heroku queda desplegable hasta que tú decidas lo contrario.
Migración de Heroku a Google Cloud
¿Voy a tener que cambiar el código de mi aplicación?
¿Qué pasa con mi add-on de Postgres o Redis en Heroku?
¿Cuánto tiempo fuera de línea implica?
¿Se puede volver atrás?
¿Listo para empezar con migración de heroku a google cloud?
Cuéntanos sobre tu tienda y tus objetivos. Volveremos con un plan claro y honesto y una cotización transparente.