Inventariar el proyecto antes de reservar el traslado
Use un sitio web de consultas ilustrativo en client.example.com: los editores publican páginas del proyecto, los visitantes suben un brief y una tarea programada exporta las consultas a un sistema de la clienta. Trasladar solo sus páginas públicas cubriría una parte del trabajo. Confirme el acceso autorizado al origen y al destino, los controles de dominio y las copias de recuperación antes de fijar una fecha.
Para cada componente, registre su propietario, versión, ubicación, dependencias y comprobación de aceptación. Mantenga las ubicaciones de las credenciales en el inventario; guarde las contraseñas y claves privadas en el almacén de secretos aprobado.
Desplace horizontalmente para ver todas las columnas de la tabla.
| Componente | Registrar antes de trasladar | Quién lo confirma |
|---|---|---|
| Dominio y DNS | Registrador, operador de DNS, registros actuales y TTL | Propietaria de la cuenta de la clienta |
| Aplicación | Versión, entorno de ejecución, extensiones y método de despliegue | Responsable de mantenimiento de la agencia |
| Datos y subidas | Base de datos, rutas de subida, método de copia de seguridad y última copia utilizable | Operador de datos |
| Formularios e integraciones | Destinatarios, puntos de conexión de webhook y destino de prueba permitido | Responsable del flujo de trabajo de la clienta |
| Trabajo programado | Cron o planificador, zona horaria, cola y última ejecución correcta | Responsable de mantenimiento de la agencia |
Demostrar la copia de recuperación antes de tocar producción
Restaure en un destino de prueba separado, nunca sobre la base de datos en producción. En PostgreSQL, un volcado SQL representa una instantánea coherente de la base de datos, pero un volcado de una sola base de datos no incluye roles ni tablespaces de todo el clúster. Registre los objetos de apoyo que requiere su aplicación. Esa instantánea de la base de datos tampoco hace que las subidas copiadas por separado sean coherentes automáticamente. Documentación del volcado SQL de PostgreSQL.
Para un proyecto de WordPress, incluya sus archivos y su base de datos. Si las URL van a cambiar, siga su guía específica de migración: una búsqueda y reemplazo indiscriminados en la base de datos pueden dañar valores serializados. Ensaye el método elegido sobre la copia. Manual de migración de WordPress.
Registre una consulta conocida y su archivo adjunto, restáurelos y verifique ambos a través de la aplicación. Mantenga la copia de seguridad original protegida fuera del servidor que se traslada. Una transferencia de archivos completada no es la aceptación de la restauración.
Ensayar los flujos de trabajo que notará la clienta
Pruebe con un nombre de host temporal de acceso controlado o una asignación de nombres solo para operadores. Configure la aplicación para esa ruta de prueba, incluidos HTTPS y las URL de callback correspondientes. Evite que la copia envíe mensajes de producción, procese pagos reales o ejecute programaciones de producción. Use registros sintéticos aprobados en lugar de datos personales innecesarios.
Escriba un resultado esperado antes de cada comprobación. Registre si pasa o falla, dónde está la evidencia y quién la revisó; una captura de pantalla de la página de inicio no puede sustituir a toda la matriz.
Desplace horizontalmente para ver todas las columnas de la tabla.
| Flujo de trabajo | Resultado esperado | Evidencia que conservar |
|---|---|---|
| Formulario y archivo adjunto | Una consulta almacenada y un archivo legible; solo el destinatario de prueba | Identificador del registro sintético y observación de la entrega |
| Webhook | Un evento de prueba aprobado llega al consumidor de prueba previsto | Identificador del evento y resultado del consumidor |
| Exportación programada | Una ejecución controlada, zona horaria correcta, sin duplicado del servidor antiguo | Identificador de ejecución y comparación de los registros exportados |
| Rutas de editor y visitante | Permisos esperados, redirecciones, recursos y comportamiento de HTTPS | URL comprobadas y detalles de cualquier fallo |
Definir la última escritura en el sistema antiguo
Para este ejemplo, la agencia propone una breve ventana de mantenimiento: pausar el envío de consultas y la edición, detener la programación de exportación antigua, terminar o contabilizar el trabajo en cola y, después, crear la copia final de la base de datos y de las subidas. La clienta debe aprobar cómo se informa a los visitantes de que los envíos no están disponibles temporalmente.
Registre el identificador de la última consulta aceptada y la hora en que se detuvieron las escrituras. Valide que el destino incluya ese registro y su archivo adjunto antes de permitir nuevos envíos. Mantenga el origen incapaz de aceptar escrituras independientes mientras las respuestas de DNS puedan diferir. Un proyecto que no puede pausar las escrituras necesita un diseño de sincronización específico para la aplicación; no improvise uno durante el cambio.
Mantener un registro de decisiones de DNS
El TTL controla cuánto tiempo se almacenan en caché las respuestas de DNS. Reducirlo en el momento del cambio no invalida las respuestas ya almacenadas en caché con el valor anterior, así que prepare cualquier cambio de TTL con antelación y observe la transición desde las redes relevantes. Cloudflare también señala que la caché local puede retrasar un cambio visible. Documentación de TTL de DNS de Cloudflare.
Registre el nombre y tipo de registro, el valor antiguo, el valor previsto, el TTL anterior, la aprobación, la hora del cambio y el resultado observado. Compruebe los registros IPv6 además de los registros IPv4 si existen ambos. Conserve los registros de correo no relacionados. Tras el cambio, verifique que el nombre de host público llega a la aplicación prevista y a su flujo de trabajo crítico, no solo a la dirección IP prevista.
Hacer de la reversión una decisión sobre datos
Acuerde condiciones de parada concretas: falta la consulta final, no se pueden abrir los archivos adjuntos, falla el inicio de sesión o un webhook llega al destinatario equivocado. Antes de que comiencen las nuevas escrituras, puede ser posible un retorno ensayado al origen conservado. Una vez que el destino acepta nuevas consultas, restaurar una copia de seguridad antigua o invertir solo el DNS puede perder esos registros.
Si aparece una condición de parada después de reabrir, pause las escrituras, conserve ambas copias y haga que el operador designado reconcilie los cambios antes de elegir el sistema autoritativo. La persona aprobadora de la clienta decide si continuar la recuperación o usar la alternativa acordada. Mantenga un registro de incidente breve en lugar de cambiar el DNS repetidamente.
Cerrar el traslado con evidencias y responsabilidad
Haga que la clienta revise la matriz de aceptación. Confirme un único planificador activo, la nueva ruta de copia de seguridad, la titularidad de las alertas y el próximo punto de control de observación. Conserve el origen durante el periodo acordado y, después, apruebe explícitamente su retirada. Elimine los accesos temporales y los datos de prueba según el acuerdo del proyecto.
Use el resultado para actualizar la hoja de responsabilidad operativa y presupuesto del proyecto. Este procedimiento organiza el trabajo de su equipo; no implica asistencia de migración incluida ni servicio ininterrumpido.
Fuentes y revisión
Las referencias técnicas se verificaron en septiembre de 12, 2026. Los ejemplos son ejercicios de planificación; la documentación de software referenciada no establece capacidades de servicio de PrivateHostLab.