Estudio de caso de migración de SaaS a VPS para cambios más seguros
Publicado el 28 de septiembre de 2026
La base de datos de producción estaba superando la capacidad de su entorno compartido mucho antes de fallar realmente. Los tiempos de respuesta aumentaban durante los periodos de mayor actividad, las ventanas de despliegue parecían arriesgadas y el equipo no tenía un procedimiento de recuperación claro si una actualización de un plugin o un problema de base de datos salía mal. Este estudio de caso de migración de SaaS a VPS sigue a un proveedor de software B2B compuesto que trasladó su aplicación a un VPS gestionado sin tratar la noche de la migración como un juego de azar.
La empresa tenía un portal de clientes, una API, procesos de trabajo, una base de datos PostgreSQL y tareas de correo electrónico en segundo plano ejecutándose desde una configuración de alojamiento que se había quedado demasiado pequeña para el trabajo. No fue una historia de una interrupción dramática. Esas rara vez son las más útiles. Fue una historia de gestión de riesgos: migrar antes de que el crecimiento normal se convirtiera en un incidente.
El punto de partida: una pila SaaS con poco margen
El proveedor de SaaS atendía aproximadamente a 3.500 usuarios activos, con el tráfico concentrado durante el horario laboral de EE. UU. Su aplicación se ejecutaba en una pila web convencional: Nginx, PHP-FPM, PostgreSQL, Redis y varios procesos de trabajo programados. El equipo tenía control de versiones y scripts de despliegue, pero la infraestructura se había acumulado de la manera práctica habitual: un servicio tras otro, hasta que nadie quería tocar el servidor un viernes.
La presión inmediata era el rendimiento de la base de datos. El uso de la CPU no era continuamente alto, pero los picos breves hacían que se acumularan consultas lentas. La contención de E/S del disco aparecía cada vez que las copias de seguridad se ejecutaban cerca de las tareas de informes. La aplicación normalmente podía recuperarse, pero «normalmente» no es un objetivo de recuperación.
El equipo también necesitaba más control sobre las versiones de PHP, la configuración de servicios, las reglas del cortafuegos y la monitorización. El alojamiento compartido había sido útil durante la etapa inicial, pero había alcanzado su límite natural. Un VPS ofrecía recursos asignados dedicados y control a nivel raíz sin exigir a la empresa operar hardware físico.
Había una restricción que condicionaba cada decisión: las sesiones de los clientes y los flujos de trabajo de pago no podían interrumpirse durante mucho tiempo. Una migración con horas de inactividad era técnicamente posible, pero poco atractiva desde el punto de vista comercial.
Qué se comprobó antes de la migración al VPS
Antes de aprovisionar el nuevo entorno, el plan de migración separó el sistema en componentes que podían trasladarse de forma independiente y componentes que requerían un cambio final. Los archivos estáticos de la aplicación, las imágenes de contenedor y la mayor parte de la configuración podían copiarse con antelación. La base de datos requería más cuidado porque seguía cambiando hasta el cambio definitivo.
El equipo midió primero el uso real en lugar de elegir un plan de VPS basándose en el optimismo. Revisaron el pico de CPU, el consumo de RAM, el tamaño de la base de datos, el crecimiento del almacenamiento, el comportamiento de IOPS, la transferencia de red y el número de procesos de trabajo simultáneos. El VPS resultante se dimensionó con margen para picos de tráfico y mantenimiento, no solo con la capacidad suficiente para reproducir los promedios actuales.
Se eligió un VPS gestionado porque el equipo interno de desarrollo podía mantener la aplicación, pero no quería convertirse en el punto de escalado nocturno para cada alerta del sistema operativo. Vale la pena expresar claramente esa compensación: el alojamiento VPS no gestionado puede costar menos sobre el papel, pero traslada la aplicación de parches, la monitorización, la validación de copias de seguridad y el triaje de incidentes a tu propio personal. Para los equipos con personal dedicado a la infraestructura, puede ser una opción sensata. Para un equipo SaaS pequeño, a menudo se convierte en una distracción costosa disfrazada de precio mensual bajo.
El nuevo VPS se protegió antes de recibir los datos de la aplicación. El acceso se limitó a claves SSH, se eliminaron los servicios innecesarios, las reglas del cortafuegos solo permitían el tráfico requerido y se revisaron las actualizaciones de seguridad automáticas para comprobar su compatibilidad con la pila. Se crearon usuarios del sistema separados para el despliegue y los procesos de servicio. Los secretos se sacaron del código y se introdujeron en archivos de configuración protegidos.
Las copias de seguridad se configuraron de dos formas: copias de seguridad fuera del servidor programadas para recuperarse de la pérdida del servidor y copias de seguridad específicas de la base de datos para restaurar los datos más rápidamente. Una copia de seguridad que nunca se ha restaurado no es más que un archivo esperanzador. El equipo restauró una copia de seguridad de la base de datos en una base de datos de prueba aislada y confirmó que la aplicación podía leerla correctamente.
El plan de migración utilizó un cambio por etapas
La aplicación se desplegó en el nuevo VPS varios días antes de la noche de la migración. Esto dio tiempo al equipo para comparar el comportamiento bajo una carga realista y resolver pequeñas diferencias en las extensiones de PHP, los permisos de archivos, la ejecución de cron, la configuración de Redis y la entrega de correo electrónico. Estos detalles son aburridos hasta que dejan de serlo.
Se utilizó un nombre de host de pruebas para las pruebas integrales. El personal interno comprobó el inicio de sesión, la creación de cuentas, las devoluciones de llamada de facturación, las cargas de archivos, los informes programados, la autenticación de la API y el portal administrativo. También probaron la ruta de reversión. Esta es la parte que muchas migraciones omiten porque planificar la reversión parece pesimista. En realidad, es lo que permite tomar una decisión serena durante un problema.
El cambio definitivo tuvo cuatro etapas operativas:
- Reducir de antemano el TTL de DNS para que los cambios de registros se propaguen más rápidamente.
- Realizar una sincronización inicial de la base de datos mientras la plataforma antigua seguía activa.
- Poner las funciones con muchas escrituras en modo de mantenimiento para la breve sincronización final.
- Actualizar DNS, verificar el tráfico de producción y mantener disponible el entorno antiguo hasta confirmar la estabilidad del nuevo servicio.
La transferencia de datos inicial trasladó la mayor parte de la base de datos sin afectar a los usuarios. A la hora de mantenimiento acordada, el equipo pausó las nuevas escrituras, ejecutó una sincronización incremental final e inició los servicios de producción en el VPS. La pausa de escrituras duró 11 minutos. Los usuarios que ya estaban navegando podían seguir leyendo la mayoría de las páginas públicas y de sus cuentas, mientras que acciones como actualizar los datos de facturación o enviar nuevos registros mostraban un breve aviso de mantenimiento.
Este enfoque no estuvo completamente libre de concesiones. Una migración con un tiempo de inactividad casi nulo mediante replicación de bases de datos puede reducir aún más la ventana de mantenimiento, pero añade complejidad y requiere más preparación previa. Para este proveedor de SaaS, una pausa controlada de 11 minutos en las escrituras era más segura que crear un diseño de replicación que el equipo no estuviera preparado para operar posteriormente. Una buena infraestructura no siempre es la infraestructura más complicada.
Qué ocurrió durante el cambio
El registro DNS se actualizó después de la comprobación final de la base de datos. El equipo de migración observó los registros de acceso y de errores, las conexiones de PostgreSQL, la actividad de los procesos de trabajo de PHP-FPM, los tiempos de respuesta y la profundidad de la cola en segundo plano a medida que el tráfico llegaba al nuevo VPS.
Aparecieron dos problemas durante la primera hora. Una tarea de informes programada utilizaba una ruta codificada del servidor antiguo y un proveedor de API externo había incluido en la lista de permitidos la dirección IP de salida anterior. Ninguno de los dos problemas requirió una reversión. Se corrigió la ruta de la tarea de informes y se actualizó la lista de permitidos del proveedor utilizando la nueva dirección del VPS. Los registros contaban ahora la misma historia.
El equipo mantuvo intacto el entorno antiguo, pero deshabilitó allí las escrituras públicas. Esto creó una opción de reversión protegida y evitó que los datos se dividieran entre dos sistemas. Tras 24 horas de comportamiento estable de la aplicación, copias de seguridad correctas y un procesamiento normal de las colas, el entorno antiguo se retiró del uso en producción.
Resultados después de migrar al VPS
La ganancia inmediata fue la consistencia. El tiempo de respuesta mediano de la aplicación mejoró porque la base de datos y los procesos de trabajo web ya no competían por recursos con otros clientes no relacionados. Más útil que la mejora de velocidad fue la visibilidad: el equipo podía ver la CPU, la RAM, el disco, la red, el estado de los servicios y el comportamiento de la base de datos en una única vista operativa.
El proveedor de SaaS también obtuvo una rutina de mantenimiento más limpia. Las actualizaciones podían probarse en pruebas antes de producción, las copias de seguridad se ejecutaban fuera de las horas punta de los informes y las alertas tenían responsables definidos. Con soporte operativo gestionado y monitorización activa de kodu.cloud, el equipo interno tenía una ruta de escalado más clara cuando el comportamiento de la infraestructura requería atención.
La migración no eliminó todas las responsabilidades. El cliente seguía siendo responsable de las versiones de la aplicación, la corrección de los datos, los permisos de usuario y las integraciones con proveedores. La capa de alojamiento podía monitorizarse, actualizarse, respaldarse y recibir soporte, pero ningún proveedor puede determinar si una funcionalidad recién desplegada contiene un error de lógica de negocio. Unos límites claros de responsabilidad forman parte de una configuración saludable.
Lecciones para equipos SaaS que planifican migrarse a un VPS
La principal lección es que la calidad de la migración se decide antes de la ventana de cambio. El mejor momento para descubrir una tarea cron no documentada, una credencial de API caducada o una tabla de base de datos sobredimensionada es durante las pruebas, no cuando los clientes están actualizando su navegador.
Empieza midiendo el uso de recursos y deja después margen para crecer. Prepara el nuevo servidor con suficiente antelación para probar flujos de trabajo reales. Confirma las copias de seguridad restaurándolas. Define qué provoca una reversión y quién puede tomar esa decisión. Por último, monitoriza el servicio después de los cambios de DNS en lugar de declarar la victoria cuando finalice el comando de despliegue.
Una migración a un VPS debería dejar a tu equipo con más control y menos conjeturas nocturnas. Si el plan incluye una recuperación probada, una transferencia por etapas y personas que supervisan el servidor después de que llegue el tráfico, el servicio puede volver a la calma.
Andres Saar Ingeniero de atención al cliente