Redacción: 4SYSTEMPublicado el Actualizado el
9 lectura mínima
Una migración de WordPress a otro host, con el mismo dominio, debe preservar los pedidos, sus pagos y actualizaciones de stock. El punto crítico no es la copia: es el momento en que el antiguo servidor deja de escribir y el nuevo pasa a ser la única autoridad.
Una copia de seguridad restaura un estado anterior. Una migración organiza la continuidad entre dos estados. Prepare el nuevo servidor mientras la tienda permanece abierta, luego congele las escrituras, sincronice y abra solo después de la validación.
Se corrigió la autoridad y el acceso antes de cualquier copia.
Combine el acceso a hosting, DNS y servicios de pago. Identifique quién autoriza la congelación, quién ejecuta el cambio y quién valida los comandos. El director de la tienda debe poder rechazar la reapertura.
Realice un inventario de las versiones, extensiones, almacenamiento de comandos, medios, tareas programadas, remitentes de correo y conexiones logísticas de PHP y WordPress. Agregue webhooks entrantes y salientes, API modificando stock y datos almacenados en otro lugar.
WordPress solicita guardar los archivos del sitio y su base de datos antes de cambiar de servidor [3]. Una restauración completa requiere estos dos juegos. [2]. Comprobar también su restauración en un ambiente aislado.
Acuerde una regla operativa: solo un servidor puede aceptar escrituras. Valide las condiciones de procesamiento de datos en el nuevo host, restrinja el acceso a los clones y planifique su eliminación después de la validación.
Copia para preparar, sin abrir una segunda tienda
El ejemplo es ficticio y no describe a un cliente de 4SYSTEM: una tienda de repuestos todavía está recibiendo pedidos durante la copia preparatoria. El antiguo sitio sigue siendo la referencia. El clon se utiliza para verificar el alojamiento, los medios, el carrito de compras y las conexiones, no para producir pedidos reales.
Aislar este clon antes de su primer inicio: bloquear el envío de correos electrónicos, pagos reales, llamadas logísticas y la ejecución de tareas. Una vista previa local con el dominio habitual no constituye protección.
Con WooCommerce Suscripciones, mantener el mismo dominio después de copiar la base de datos no activa el modo provisional: las renovaciones se pueden procesar en modo real [9]. Así que no se deje engañar por la palabra "preproducción" en el panel de alojamiento.
Mantener las URL públicas habituales y ajustar la conexión a la base de datos si sus parámetros cambian: WordPress distingue entre mantener el dominio y cambiar la configuración [3]. Posponer las actualizaciones funcionales: complicarían el diagnóstico y la reversión.
Migración de WordPress a otro host: congelar y luego sincronizar
La copia preparatoria queda obsoleta tan pronto como llega un nuevo pedido. Para obtener el estado de alternancia, siga este orden:
- Cerrar el paso de pedidos y suspender cambios de back office, importaciones, sincronizaciones y escribir llamadas API. Una simple página de mantenimiento no es suficiente.
- Conciliar los pagos ya realizados con los pedidos del sitio anterior. Las notificaciones en tránsito deben procesarse allí antes de cortarlas o mantenerse en una cola duradera para su reproducción probada.
- Verifique las opciones de recuperación del proveedor de pago. No confirme la recepción de un webhook sin una conservación duradera. Sin una repetición documentada o una posible reconciliación, posponga el cambio.
- Detener WordPress tareas, alojamiento de crons y archivos de extensiones. Registre el último estado permitido y los eventos aún pendientes.
- Cree la copia de seguridad final, base y luego archivos; restaure los archivos y luego la base de datos al destino aislado, de acuerdo con el orden recomendado por WordPress [2].
La sincronización final reemplaza el estado preparatorio con el conjunto coherente de datos congelados, incluidas las tablas de extensión y los medios recientes. No se limite a copiar pedidos: deben seguir las acciones, las cuentas, las notas y los estados relacionados. Exigir prueba de congelación y conciliación de órdenes pendientes antes de autorizar DNS.
Alternar DNS sin crear dos sitios activos
Tenga en cuenta los registros que realmente dirigen el tráfico web: IPv4, IPv6 y posiblemente CDN. Verifique que el cambio planificado no afecte los registros de correo electrónico. Si reduce el TTL, hágalo con anticipación y anote su valor anterior.
DNS no cambia a todos los visitantes simultáneamente. Es posible que algunos cachés aún conduzcan al servidor anterior mientras que otros lleguen al nuevo. Así que elija el nuevo como autoridad de escritura, independientemente de lo que vea su navegador.
El servidor antiguo debe seguir sin poder aceptar comandos, devoluciones de llamadas o modificaciones administrativas. Mantenlo en mantenimiento; una retransmisión al destino solo es aceptable después de la validación técnica de las firmas de enrutamiento y webhooks.
Control HTTPS, dominio canónico, administración y cachés desde múltiples accesos. La pantalla no prueba que la base correcta esté respondiendo, ni que todos los pagos estén llegando a ella. Conserve un comprobante de la dirección del servidor contactado.
Recibir la recuperación y neutralizar las automatizaciones antiguas.
La receta comienza antes de la apertura: conexión de administrador, medios, cesta, entrega, impuestos y proceso de pago en modo de prueba, sin cobro real en el clon. Luego compare los pedidos de muestra y los pagos pendientes con el estado final guardado y las referencias del proveedor de servicios. Consulta sus estados asociados, valoraciones y stocks.
Reactive el procesamiento en el nuevo servidor solo después de esta validación. Verifique cada cola antes de iniciarla para evitar repetir una acción que ya se realizó. La reproducción de webhooks debe controlar sus identificadores para evitar el doble procesamiento. Vuelva a abrir pedidos y luego realice un seguimiento de un pedido autorizado mediante notificación y procesamiento logístico.
El hosting antiguo conserva sus automatismos mientras no los neutralices. Para las suscripciones, el modo de preparación no detiene todos los eventos programados y otras extensiones aún pueden enviar correos electrónicos [9]. Controle por separado el Programador de acciones, WP-Cron, crons externos y el remitente SMTP. Detener el ejecutor del Programador de acciones también puede bloquear eventos de otras extensiones que usan esta biblioteca [9].
Documente las comprobaciones recurrentes en su proceso de gestión mantenimiento y copias de seguridad. Elimine el entorno anterior únicamente después de que se hayan conciliado los eventos diferidos y se haya confirmado el enrutamiento y la ausencia de escrituras residuales.
Registro de cambios: decisiones rastreables
El siguiente registro proporciona entradas completadas para la tienda ficticia. El piloto técnico tiene la evidencia; el gerente de la tienda firma la decisión de apertura. Las partes mostradas son validaciones esperadas, no resultados observados.
| Fase | Decisión a tomar | Evidencia a conservar |
|---|---|---|
| Copia preparatoria | Mantenga el sitio anterior como único productor y aísle el clon. | Inventario de bloqueos de acceso y salida. |
| Congelar | Cerrar órdenes y conciliar pagos comprometidos. | Registro de notificaciones procesadas y retenidas. |
| Sincronización final | Retener el archivo congelado y mantener el destino cerrado. | Referencia de archivo y comparación de órdenes de testigos. |
| DNS | Designe el nuevo servidor como la única autoridad. | Declaración de altas y dirección de contacto. |
| Reanudación | Acondiciona la apertura de la receta y neutraliza antiguos automatismos. | Controles de tienda, colas y correos electrónicos registrados. |
| Incidente después de la apertura | Preservar escritos nuevos y prohibir la restauración antigua. | Exportación protegida de estado reciente y lista de eventos externos. |
Ingrese para cada línea la hora real, el orador y la ubicación segura de la evidencia. Anote los identificadores útiles para la conciliación, nunca los datos de la tarjeta.
Regresar sin eliminar nuevas entradas
La reversión depende de las escrituras, no solo del funcionamiento del servidor. Aplique este árbol de decisión:
- ¿No hay nuevas entradas en el destino? Mantenga ambos sitios cerrados, confirme esta ausencia y luego restablezca el antiguo como autoridad antes de modificar el DNS y reactivar su procesamiento.
- ¿Han cambiado los pedidos, pagos, cuentas o stocks? Preservar el nuevo estado inmediatamente. Priorizar una corrección en el nuevo servidor; una copia de seguridad antigua borraría estos cambios.
- ¿Sigue siendo necesaria la devolución del alojamiento? Congele el destino, guarde su estado completo y restaure este estado reciente en el antiguo servidor aislado. Revalide las integraciones y eventos pendientes antes de devolverle la autoridad.
- ¿Ambos servidores escribieron? Congele todas las escrituras en ambos servidores según el procedimiento anterior y luego mantenga sus estados por separado. Conciliar pedidos, pagos y acciones logísticas antes de cualquier recuperación; ninguna combinación de SQL improvisada garantiza su coherencia.
Un reembolso, correo electrónico o envío ya activado no se cancela mediante la restauración. Concilie las referencias de los proveedores de servicios y los registros de logística para decidir qué eventos reanudar. Si la ausencia de nuevas entradas no es demostrable, se tratará el caso como una recuperación tras entradas.
Preguntas frecuentes
Un webhook llega al servidor antiguo después de abrirlo: ¿qué hacer?
No intente reactivar su tienda para procesar este evento solo. Verifique si el proveedor planea un reintento y si la notificación está en su cola duradera. Concilie su referencia con el pago registrado en el nuevo sitio y luego aplique el mecanismo de recuperación probado. Sin pruebas suficientes, mantener el caso en revisión manual.
¿Podemos conservar el hosting antiguo solo para correos electrónicos?
Sí, si las casillas y sus registros DNS permanecen voluntariamente con este proveedor de servicios. Luego separe el mantenimiento de la mensajería del de WordPress: la aplicación antigua, sus tareas y su envío automático deben permanecer neutralizados. Verifique las dependencias del contrato antes de la terminación y pruebe la recepción, envío y autenticación del servicio seleccionado.
¿Se puede garantizar una cesta abierta antes de las heladas?
No con solo copiar los comandos. Un carrito de compras puede depender de sesiones, cookies o almacenamiento externo cuya reanudación debe ser verificada. Advierta a los compradores sobre la congelación y pruebe este caso en el destino. No confunda el carrito abandonado y el pago comprometido: este último requiere una conciliación antes de pedir al cliente que comience de nuevo.
Prepare el siguiente cambio
Comience completando el inventario de entradas y asignando decisiones de diario. Luego programe la congelación solo cuando la copia aislada y la reanudación de notificaciones estén habilitadas. Si nadie puede confirmar la autoridad exclusiva o preservar las órdenes que aparecieron después de la apertura, posponga el cambio. Para enmarcar esta preparación, puedes consultar el servicios web de 4SYSTEM.
Fuentes
- Backups : Advanced Administration Handbook | Developer.WordPress.org (consultado 2026-10-08)
- Migrating WordPress : Advanced Administration Handbook | Developer.WordPress.org (consultado 2026-10-08)
- How Subscriptions Handles Staging Sites and Migrations Documentation - WooCommerce (consultado 2026-10-08)
