Migrar de hosting compartido a VPS: plan y retorno

Migrar de hosting compartido a un VPS exige trasladar un servicio completo, no solo copiar archivos y cambiar una dirección IP. Antes del corte debes saber qué datos cambian, qué depende del alojamiento actual, cómo comprobar el destino y cómo regresar sin perder operaciones nuevas.

Esta guía organiza un plan de inventario, ensayo, corte y aceptación. No promete una migración sin interrupciones ni recomienda un VPS ante cualquier lentitud: si el problema es una consulta, una imagen pesada o una configuración, corregirlo en el servicio actual puede ser suficiente.

Confirma primero qué limitación resolverá el VPS

Identifica una necesidad comprobada: versión de software no disponible, permisos de administración necesarios, recursos insuficientes bajo una carga medida o una arquitectura incompatible con el hosting actual. Pide evidencia del límite y verifica que el destino lo elimine. Más control implica tareas de operación, no seguridad o rendimiento automáticos.

Compara conservar y optimizar, cambiar a hosting administrado adecuado o migrar a VPS. Para separar síntomas de causas usa la guía de diagnóstico de rendimiento. No combines la migración con una renovación completa del sitio si no puedes probar y revertir ambos cambios por separado.

1. Inventaría lo que realmente utiliza el alojamiento

No confundas registro del dominio, DNS autoritativo, web y correo: pueden estar en empresas diferentes. Mover la web no obliga a mover los buzones. Si vas a cambiar servidores de nombres, revisa toda la zona, no solo el registro del sitio.

2. Prepara una copia recuperable y ensaya el destino

Conserva un respaldo de archivos, base de datos y configuración necesaria fuera del único servidor que modificarás. Identifica fecha, alcance y responsable de restaurar. La existencia del archivo no prueba que puedas recuperar la aplicación; abre una restauración de ensayo y comprueba el flujo que importa al negocio.

La guía oficial de migración de WordPress distingue mover el servidor conservando dominio y URLs de cambiar esos identificadores. Para una mudanza de alojamiento, mantener las URLs evita introducir cambios innecesarios. No hagas reemplazos generales en la base de datos sin un procedimiento compatible con la aplicación y una copia recuperable.

En el destino, confirma versiones, extensiones, permisos, espacio, certificados y tareas. Una importación terminada no acredita compatibilidad. Si se usa una URL temporal o una resolución local de prueba, que el técnico documente cómo se evita confundirla con producción; protege el ensayo para que no publique contenido duplicado ni envíe notificaciones reales.

• Revisa inicio, páginas internas, imágenes, descargas y enlaces con las URLs esperadas.
• Comprueba acceso, permisos y creación/consulta de un registro de prueba autorizado.
• En tiendas, valida carrito, stock e integración de pago en modo de prueba admitido; no realices cobros reales como comprobación casual.
• Revisa formularios y correos transaccionales con destinatarios autorizados, no con clientes reales por defecto.
• Compara registros críticos y sus identificadores; un conteo igual no demuestra que todos los valores coincidan.

3. Decide cómo conservarás las escrituras recientes

Una tienda, foro o sistema de reservas puede cambiar mientras copias. Define qué sistema será la fuente de verdad en cada momento y cómo incorporarás los cambios ocurridos después de la primera copia. Según la aplicación, puede necesitarse una ventana de mantenimiento, una sincronización compatible o un procedimiento específico de corte.

Ejemplo hipotético: a las 10:00 se copia una tienda con 100 pedidos y antes del corte se crean tres pedidos más en el origen. Si el destino conserva solo los 100 iniciales, no está listo aunque la portada cargue. Debes verificar esos tres pedidos, sus estados, pagos relacionados e inventario; no basta cambiar DNS. El ejemplo no es una prueba de rendimiento ni una tasa esperada de ventas.

No permitas que ambos sistemas acepten escrituras independientes sin un diseño de reconciliación. Una copia adicional de archivos no integra automáticamente cambios de base de datos. La forma correcta depende de la aplicación y debe quedar a cargo de quien la administra.

4. Coordina el corte, DNS y correo

Acuerda responsable del cambio, ventana, criterio para detenerse y contacto de cada dependencia. Conserva los valores anteriores y prepara el destino antes de modificar registros. El TTL documentado por Cloudflare describe cuánto tiempo puede conservarse una respuesta DNS en caché; no es una garantía de que todos los usuarios cambien al mismo instante.

Reducir el TTL justo al cortar no elimina respuestas que ya se guardaron con el valor anterior. Si el equipo decide ajustarlo, debe hacerlo con antelación suficiente según los valores y el servicio DNS, y comprobar la configuración real. No uses “48 horas” como plazo universal ni como excusa para omitir pruebas.

Si el correo permanece donde está, conserva sus registros y rutas. Cloudflare documenta por separado los registros de correo, incluidos MX y autenticación. Cambiar el registro web no traslada buzones ni conserva por sí solo la capacidad de enviar desde una aplicación. Si también migras correo, necesitas un plan específico de mensajes, cuentas, clientes y coexistencia; no lo ocultes dentro de “mover la página”.

Durante la transición, observa ambos extremos según el diseño acordado: accesos, errores, trabajos programados y datos nuevos. Evita ejecutar dos veces tareas como facturación, importaciones o avisos automáticos. Mantén disponible la información del origen mientras dure la validación, con los controles necesarios para que no reciba operaciones contradictorias.

5. Volver atrás también requiere un plan de datos

Un rollback no siempre consiste en regresar la IP. Si el destino ya recibió pedidos o modificaciones, devolver tráfico al origen antiguo puede ocultar esos datos. Define antes del corte qué condición activa el retorno, quién decide y cómo se conservan o reconcilian las operaciones posteriores.

Ensaya el procedimiento cuando sea posible. No borres el alojamiento anterior, sus copias o registros al ver la portada nueva. Tampoco lo dejes indefinidamente sin mantenimiento: acuerda un periodo de coexistencia y un cierre después de verificar integridad y recuperación. La cancelación debe seguir el contrato y la autorización del titular.

6. Acepta el servicio con una lista de resultados

• Las URLs y HTTPS responden desde conexiones representativas, sin depender de una configuración local de ensayo.
• Los flujos críticos completan su tarea y los usuarios tienen los permisos correctos.
• Los datos previos y los creados durante el corte están conciliados con su fuente de verdad.
• Correo, integraciones y tareas programadas funcionan una sola vez según lo previsto.
• Existe respaldo del destino y una restauración verificable, con responsables y alertas.
• El dueño del proceso registra aceptación o pendientes; el servidor encendido no equivale a aceptación del negocio.

Ficha de corte reutilizable

Servicio, dominio y motivo de migración: ____
Origen/destino y versiones: ____
Inventario de web, datos, correo, DNS e integraciones: ____
Responsables y accesos confirmados: ____
Respaldo recuperable y prueba: ____
Fuente de verdad y tratamiento de escrituras: ____
Ventana, pasos y criterio de detenerse: ____
Registros anteriores/nuevos y TTL: ____
Pruebas de aceptación, resultado y evidencias: ____
Retorno y reconciliación de datos posteriores: ____
Coexistencia, cierre y autorizaciones: ____

Cuándo ayuda un socio de migración

Un socio aporta valor si inventaría dependencias, coordina el corte, ensaya y entrega evidencia de aceptación y retorno. Pide alcance: web, correo, DNS, aplicación y soporte posterior pueden ser tareas distintas. No pagues por una garantía vaga de “cero pérdidas”; exige cómo se evitarán, detectarán y resolverán diferencias. Si el hosting actual cubre tu necesidad y puedes corregir el problema allí, no migrar también es una decisión válida.

IA: apoyar el inventario, no ejecutar el corte

Una herramienta autorizada de IA puede organizar una lista depurada de dependencias y proponer comprobaciones faltantes. Puede omitir servicios o sugerir cambios peligrosos; contrasta la lista con la configuración real y el fabricante. No compartas credenciales, copias de bases de datos ni mensajes privados sin autorización. El técnico y el dueño del proceso deben aprobar el plan: una salida de IA no autoriza cambios DNS, restauraciones o cancelaciones.

Siguiente paso: comparte la ficha sin secretos para delimitar con Cobalt una migración de hosting a VPS. Solicita un plan de ensayo, corte y aceptación, no solo la transferencia de archivos.