Checklist antes de migrar una tienda WooCommerce

Antes de migrar WooCommerce, decide cómo impedirás que un pedido nuevo quede solo en el servidor antiguo. Una copia de pruebas sirve para detectar incompatibilidades, pero su base de datos deja de estar actualizada en cuanto la tienda recibe pedidos, clientes, cambios de stock o reembolsos. Nunca publiques una copia antigua sobre la base de datos que contiene operaciones recientes.

La misma precaución rige para respaldos de una tienda activa. Si además cambias versión, separa la migración del ensayo de la actualización para poder localizar fallos.

Inventario previo de la tienda

• Registra versiones de WordPress, WooCommerce, tema, extensiones y PHP; revisa el informe del sistema de WooCommerce.
• Identifica pasarelas, pagos recurrentes, webhooks, impuestos, envíos, facturación, integraciones ERP/CRM, tareas programadas y correo transaccional.
• Anota número y estado de los pedidos, clientes y productos en el origen, así como las últimas operaciones, devoluciones y existencias. Comprueba cómo almacena pedidos tu instalación y qué tablas usan las extensiones.
• Prepara copias verificadas de archivos y base de datos, además de un responsable, una ventana de trabajo y una ruta de recuperación. El procedimiento oficial de WooCommerce recuerda que tienda y datos se reparten entre archivos y base de datos.

Prueba el destino sin convertirlo en una segunda tienda activa

En un entorno de pruebas no público, verifica compatibilidad, SSL, catálogo, variantes, búsqueda, carrito, impuestos y checkout con el modo de prueba autorizado por la pasarela. Desactiva o aísla envíos reales, webhooks y correos a clientes desde la copia para evitar cargos o mensajes duplicados. Comprueba también cron y tareas en segundo plano. Si hay suscripciones o pagos tokenizados, solicita un plan específico: WooCommerce advierte del riesgo de copiar una base de staging sobre producción.

Plan del corte: una sola fuente de pedidos

1. Comunica una ventana razonable y establece quién puede cerrar temporalmente el checkout. No basta con activar una página de mantenimiento si la API, webhooks o pasarelas siguen escribiendo en origen.
2. Detén nuevas escrituras o implanta una sincronización transaccional diseñada y probada para tu arquitectura. Si no puedes garantizarla, pausa la venta durante el corte en lugar de prometer «cero interrupciones».
3. Con las escrituras detenidas, toma la copia final y coherente de archivos y base de datos; restaura esa versión en destino. No importes encima una copia de staging anterior.
4. Compara los últimos pedidos por ID, fecha, estado e importe, además de clientes, stock y reembolsos. Resuelve diferencias antes de cambiar DNS o reabrir el checkout.
5. Cambia la ruta pública y valida el certificado, la pasarela, webhooks, correo y una compra de prueba segura. Solo entonces vuelve a aceptar pedidos.

Ejemplo: entre la copia de ensayo del lunes y el traslado del miércoles entran doce pedidos. Restaurar el ensayo el miércoles eliminaría esos pedidos del destino. La solución no es «fusionar tablas» a mano: hay que trasladar el estado final tras detener escrituras o emplear un procedimiento de sincronización probado, con conciliación y respaldo. Una importación de órdenes con IDs coincidentes también puede sobrescribir datos, como explica la documentación de importación de WooCommerce.

Después de reabrir

Vigila pedidos, pasarelas, stock, correos y tareas programadas durante el periodo acordado. Conserva el servidor anterior accesible para diagnóstico, pero no como segunda tienda que acepte ventas. La guía de verificación posterior amplía las pruebas de WordPress; la guía de requisitos de hosting WooCommerce ayuda a evaluar el destino. IDEIHOSTING no anuncia aquí una migración incluida: consulta el alcance para tu tienda antes de contratar.

Si se plantea volver a una copia anterior, revisa cómo preservar pedidos y stock creados después. Reabrir ventas antes de conciliar esos datos puede ocultar pérdidas que no aparecen en la portada.