Migración a hosting especializado sin interrupciones: checklist para WordPress, e-commerce y aplicaciones

Una migración a hosting especializado no consiste únicamente en copiar archivos y cambiar el DNS. En un proyecto empresarial también deben trasladarse bases de datos, tareas programadas, certificados, correos transaccionales, integraciones, reglas de seguridad, almacenamiento, monitoreo y procedimientos de respaldo.

Si el cambio se realiza sin inventario ni pruebas, pueden aparecer formularios que no envían, pedidos perdidos, usuarios que llegan a versiones diferentes, rutas rotas o páginas bloqueadas para Google. En cambio, una migración planificada permite reducir la interrupción, validar el nuevo entorno y conservar una ruta de reversa.

Esta guía presenta un checklist aplicable a WordPress, WooCommerce, Moodle, tiendas virtuales y aplicaciones web. Aunque suele hablarse de “cero downtime”, en la práctica conviene definir con precisión el tiempo máximo de afectación y las operaciones que podrían necesitar una breve pausa para conservar consistencia.

¿Cuándo conviene migrar a un hosting especializado?

El rendimiento cambia demasiado durante los picos

El sitio funciona bien la mayor parte del día, pero se vuelve lento durante campañas, matrículas, evaluaciones o cierres. Esto puede indicar límites de CPU, RAM, almacenamiento, procesos o base de datos que un entorno genérico no gestiona adecuadamente.

El proveedor actual no conoce la aplicación

WordPress, Magento, PrestaShop, WooCommerce, Moodle y los aplicativos a medida tienen patrones distintos. Un hosting especializado ajusta versiones, caché, base de datos, seguridad, tareas programadas y recursos según la tecnología.

El equipo interno dedica demasiado tiempo a la infraestructura

Actualizaciones, copias, monitoreo y respuesta a incidentes compiten con el desarrollo del negocio. Un servicio administrado permite asignar esas responsabilidades a un equipo especializado con procedimientos y niveles de atención definidos.

La organización necesita crecer o mejorar continuidad

Una migración puede ser el momento adecuado para separar componentes, implementar almacenamiento más rápido, CDN, balanceo, copias externas o monitoreo continuo. El objetivo no debe ser replicar las mismas limitaciones en un servidor nuevo.

Fase 1. Descubrimiento e inventario

Identifique todos los componentes

Documente:

• Dominios, subdominios y DNS.
• Código, repositorios y versiones.
• Base de datos, tamaño, motor y extensiones.
• Archivos subidos por usuarios.
• Certificados TLS.
• Tareas programadas y colas.
• Cuentas SMTP y correo transaccional.
• APIs, webhooks y servicios externos.
• CDN, almacenamiento y reglas de caché.
• Firewall, listas permitidas y bloqueos.
• Monitoreo, logs y alertas.
• Backups, retención y restauración.
• Integraciones con pagos, ERP, CRM, SSO o analítica.

El inventario debe incluir propietarios y credenciales gestionadas por mecanismos seguros. No envíe contraseñas en documentos o canales informales.

Defina RPO, RTO y ventana de cambio

El RPO indica cuántos datos podría perder la organización en un incidente. El RTO define cuánto tiempo puede tardar la recuperación. Estos objetivos determinan la estrategia de sincronización y rollback.

Una web institucional con pocos cambios puede aceptar una copia final. Una tienda con pedidos continuos o una plataforma con evaluaciones necesita sincronización y control de escrituras para no perder transacciones.

Registre una línea base

Antes de migrar, mida:

• Tiempo de respuesta y Core Web Vitals en páginas representativas.
• Tasa de errores.
• CPU, RAM, I/O y red.
• Solicitudes y usuarios concurrentes.
• Rendimiento de base de datos.
• Disponibilidad.
• Estado de indexación y tráfico orgánico.
• Conversiones, formularios, compras o finalizaciones.

Sin línea base no es posible demostrar que la migración mejoró el servicio ni detectar regresiones.

Fase 2. Diseñar el entorno de destino

Dimensione según la carga real

Use datos de concurrencia, transacciones, crecimiento y picos para escoger CPU, RAM, almacenamiento y red. Reserve capacidad y defina umbrales para ampliar.

Revise compatibilidad

Confirme versiones de PHP, Java, Node.js, Python, base de datos, extensiones, servidor web y librerías. No actualice muchos componentes críticos al mismo tiempo sin pruebas, porque será difícil identificar la causa de un error.

Diseñe seguridad y recuperación

Incluya mínimo privilegio, acceso administrativo restringido, firewall, gestión de secretos, TLS, copias separadas, monitoreo y registro. Defina quién puede ejecutar el cambio y quién autoriza una reversa.

Fase 3. Crear un entorno de pruebas

Realice una primera copia

Migre código, archivos y una copia de la base de datos al nuevo entorno. Manténgalo aislado o protegido para evitar que usuarios y motores de búsqueda accedan a una versión de prueba.

Pruebe mediante una resolución controlada

El equipo puede usar un dominio temporal o una modificación local de resolución para probar el servidor nuevo sin cambiar el tráfico público. Si se utiliza un dominio temporal, revise cookies, URLs absolutas, CORS, callbacks y licencias.

Ejecute pruebas funcionales

No valide solo la página de inicio. Pruebe rutas críticas:

• Inicio y cierre de sesión.
• Recuperación de contraseña.
• Formularios y archivos adjuntos.
• Búsqueda y filtros.
• Compra, pago y confirmación.
• Inscripción, avance y evaluación.
• Paneles administrativos.
• Integraciones, webhooks y APIs.
• Correos transaccionales.
• Tareas programadas.

Ejecute pruebas de rendimiento

Compare la línea base y simule carga representativa. Observe tiempos P95 y P99, errores, uso de CPU, memoria, almacenamiento y base de datos. Ajuste caché, procesos, consultas y límites antes del cambio.

Fase 4. Preparar el cambio

Reduzca el TTL con anticipación

El TTL indica cuánto tiempo los resolvers pueden conservar un registro DNS. Reducirlo antes del cambio permite que una actualización o reversa sea visible más rápido. AWS recomienda hacerlo con anticipación y esperar a que expire el valor anterior antes de migrar.

No deje un TTL muy bajo de forma permanente sin necesidad. Después de estabilizar la migración puede volver a un valor normal según la estrategia de DNS.

Defina un plan minuto a minuto

El runbook debe indicar:

1. Hora de inicio.
2. Responsable de cada acción.
3. Pausa de escrituras, si es necesaria.
4. Backup final.
5. Sincronización final.
6. Validaciones previas.
7. Cambio de DNS, proxy o balanceador.
8. Pruebas de aceptación.
9. Criterios de éxito.
10. Criterios y procedimiento de rollback.

Comunique a los interesados

Informe a soporte, operaciones, marketing, ventas y responsables del sistema. Si existe una ventana de mantenimiento, indique alcance, horario y canal de estado. Una comunicación clara reduce cambios simultáneos y reportes duplicados.

Fase 5. Sincronización y cutover

Controle las escrituras

En sistemas dinámicos, una copia antigua puede quedar desactualizada minutos después. Las opciones incluyen replicación, sincronización incremental o una breve ventana de solo lectura mientras se hace la copia final.

En e-commerce, los pedidos y pagos requieren especial cuidado. En un LMS, se deben proteger entregas, intentos de evaluación, mensajes y calificaciones.

Ejecute la copia final y valide

Compruebe conteos, tamaños, fechas y, cuando sea apropiado, hashes o consultas de control. Revise que el destino tenga los últimos archivos y transacciones.

Cambie el tráfico

El cambio puede realizarse mediante DNS, proxy inverso, balanceador o reglas de enrutamiento. Mantenga el entorno anterior disponible durante el periodo de observación, salvo que exista una razón de seguridad para aislarlo.

Pruebe desde el exterior

Valide resolución DNS, certificado, páginas críticas, operaciones, correos y paneles desde diferentes redes. Compruebe que los logs y alertas están llegando al sistema correcto.

Fase 6. Monitoreo posterior

Durante las primeras horas, observe:

• Tasa de errores HTTP y de aplicación.
• Latencia y percentiles.
• CPU, memoria, disco y conexiones.
• Consultas lentas.
• Colas y tareas programadas.
• Entrega de correos.
• Pagos, pedidos, formularios e inscripciones.
• Logs de seguridad.
• Tráfico y conversiones.

Defina una sala o canal de coordinación con responsables técnicos y del negocio. Un error que no aparece en el monitoreo técnico puede detectarse en una caída de conversiones o en reportes de usuarios.

Plan de rollback: qué debe contener

Una reversa no es improvisar el regreso. Debe especificar:

• Señales que activan el rollback.
• Persona autorizada para decidir.
• Forma de devolver el tráfico.
• Tratamiento de datos escritos en el entorno nuevo.
• Validaciones después de regresar.
• Comunicación a usuarios y equipos.

El punto más delicado es la divergencia de datos. Si ambos entornos reciben escrituras, volver al anterior puede perder pedidos, entregas o cambios. Por eso, la estrategia de datos debe diseñarse antes.

Consideraciones según la plataforma

WordPress

Revise URLs absolutas, serialización de datos, reglas de enlaces permanentes, caché, cron, formularios, SMTP, almacenamiento de medios, plugins y licencias. Confirme que el entorno de pruebas no dejó activa una etiqueta noindex.

WooCommerce, PrestaShop o Magento

Pruebe catálogo, inventario, carrito, impuestos, pasarelas, webhooks, confirmaciones y tareas. Coordine la ventana con operaciones y evite perder pedidos durante la sincronización final.

Moodle, Chamilo o Totara

Valide rutas de datos, tareas programadas, cachés, sesiones, autenticación, SSO, correo, repositorios, videoconferencia, certificados y evaluaciones. Programe el cambio fuera de eventos académicos críticos.

Aplicaciones a medida

Documente variables de entorno, secretos, almacenamiento persistente, versiones de runtime, colas, workers, APIs, CORS, dependencias y migraciones de base de datos. Automatice pruebas de salud cuando sea posible.

Controles SEO para no perder visibilidad

Conserve las URL si no existe una razón para cambiarlas

Una migración de infraestructura no exige modificar la estructura del sitio. Mantener rutas reduce riesgo. Si se cambian, cree redirecciones 301 uno a uno y evite cadenas.

Revise canonical, robots y noindex

El sitio público debe apuntar a su URL canónica correcta. Retire bloqueos usados en staging y confirme que robots.txt permite rastrear las secciones que deben aparecer en buscadores.

Verifique sitemap y enlaces internos

El sitemap debe contener URLs canónicas indexables y estar accesible. Google aclara que enviarlo ayuda al descubrimiento, pero no garantiza la indexación. Revise enlaces internos y páginas huérfanas.

Mantenga analítica y medición

Confirme etiquetas, consentimiento, objetivos y eventos. Compare tráfico orgánico, impresiones, errores de rastreo, indexación y conversiones después del cambio.

Solicite indexación solo cuando sea necesario

Si las URLs no cambiaron, Google puede procesar la migración como un cambio de infraestructura. Use Search Console para inspeccionar páginas críticas, verificar el sitemap y monitorear; no es necesario solicitar manualmente cada URL.

Checklist final de migración

• Inventario técnico y propietarios completos.
• RPO, RTO y ventana aprobados.
• Línea base de rendimiento y negocio.
• Recursos del destino dimensionados.
• Compatibilidad validada.
• Backup íntegro y restauración probada.
• Entorno de staging protegido.
• Pruebas funcionales, carga y seguridad aprobadas.
• TTL reducido con anticipación.
• Plan de cutover y rollback documentado.
• Sincronización final verificada.
• Monitoreo y alertas activos.
• DNS, TLS, correo e integraciones confirmados.
• Robots, canonical, sitemap y analítica revisados.
• Responsables disponibles durante la estabilización.

Migrar con método para crecer con confianza

Una migración a hosting especializado es una oportunidad para resolver límites de rendimiento, seguridad, escalabilidad y administración. Su éxito depende de conocer el sistema, probar el destino, controlar los datos, preparar la reversa y observar el comportamiento después del cambio.

INTERNET YA ofrece hosting especializado y administrado para plataformas e-learning, e-commerce, WordPress y aplicaciones web. Nuestro equipo se encarga de infraestructura, migración, seguridad, monitoreo, copias y soporte para que la organización pueda concentrarse en su operación.

¿Está evaluando migrar un proyecto crítico? Solicite un diagnóstico con INTERNET YA y construya un plan de migración adaptado a su aplicación.