Migrar una tienda WooCommerce activa exige mover un sistema que sigue cambiando. Mientras preparamos el nuevo servidor entran pedidos, se registran clientes, se renuevan suscripciones y continúan las sincronizaciones. El desafío real no es mover la tienda. Es moverla sin perder lo que pasó durante el movimiento.
El sitio no es una foto
En un sitio institucional, una migración puede tratarse casi como una fotografía: copiamos archivos, exportamos la base de datos, importamos todo en el nuevo servidor y hacemos el cambio. WooCommerce es distinto. Mientras preparamos la nueva infraestructura, la tienda vieja sigue cambiando.
Puede entrar:
- Un pedido
- Un nuevo cliente
- Una devolución
- Un cambio de stock
- Una renovación
- Una actualización de dirección
- Un webhook de un proveedor externo
Eso significa que un backup tomado a las 10:00 ya puede estar desactualizado a las 10:05. La migración necesita contemplar esa diferencia desde el principio.
Primero hay que saber qué datos están vivos
Antes de mover nada conviene identificar qué partes del sistema cambian constantemente y cuáles pueden copiarse con anticipación. Themes, plugins, imágenes o archivos estáticos pueden prepararse antes. Pedidos, usuarios, sesiones, stock y algunos metadatos no. También hay plugins que mantienen sus propias tablas y servicios externos que guardan referencias a IDs internos, URLs o credenciales del entorno actual.
No alcanza con revisar las tablas estándar de WordPress. Hay que entender qué escribe cada pieza importante del sistema.
El tiempo de corte importa
En una migración grande casi siempre existe un momento donde hay que limitar los cambios. Puede ser una ventana de mantenimiento breve, poner temporalmente la tienda en modo catálogo o detener determinados procesos mientras se hace la sincronización final. La clave es reducir ese período al mínimo.
Una estrategia habitual es mover primero todo lo pesado: archivos, plugins, configuración, imágenes y una copia inicial de la base de datos. Después, cerca del cambio definitivo, sincronizar solamente los datos que cambiaron desde esa copia. Cuanto menos haya que hacer durante el corte, menor es el riesgo.
DNS no cambia instantáneamente para todos
Cambiar un registro DNS no significa que todos los usuarios empiecen inmediatamente a usar el servidor nuevo. Durante un período pueden existir clientes llegando al servidor viejo mientras otros ya están usando el nuevo. Eso es especialmente peligroso en una tienda. Si ambos servidores aceptan pedidos al mismo tiempo, podemos terminar con dos fuentes de verdad.
Por eso una migración no debería depender de la idea de que "cambiamos el DNS y listo". Hay que pensar qué sucede durante esa transición.
Los pagos necesitan atención especial
Una tienda puede verse perfectamente bien después de migrarla y aun así tener problemas importantes. Los gateways de pago suelen depender de:
- URLs de retorno
- Webhooks
- Claves
- Certificados
- Reglas de firewall
- IPs autorizadas
- Tareas programadas
Un checkout exitoso en pantalla tampoco garantiza que todo el flujo haya funcionado. Hay que comprobar que el pedido haya quedado registrado correctamente, que el proveedor haya enviado sus notificaciones y que WooCommerce haya procesado los cambios de estado esperados. En una migración, probar el botón Pagar es apenas el comienzo.
Cron y procesos en segundo plano
WooCommerce y muchos de sus plugins dependen de tareas programadas para emails, renovaciones, sincronizaciones, limpiezas, colas e importaciones. Una migración puede dejar el frontend funcionando mientras esos procesos están detenidos o, peor, ejecutándose simultáneamente en los dos servidores.
Antes del cambio conviene saber qué cron jobs existen y quién los está ejecutando. Después hay que verificar que solamente el entorno correcto siga haciéndolo.
Las integraciones no saben que nos mudamos
ERP, CRM, proveedores de inventario, servicios de marketing, sistemas de fulfillment y aplicaciones internas pueden estar conectados al WooCommerce viejo. Algunos usan la API. Otros webhooks. Otros acceden directamente a archivos o endpoints personalizados.
Incluso puede haber procesos que nadie recuerda porque llevan años funcionando. Antes de migrar hay que armar un mapa de esas conexiones. Encontrarlas después porque dejaron de funcionar es bastante más caro.
Search-replace: hacerlo bien importa
Cambiar URLs dentro de WordPress parece sencillo hasta que aparecen datos serializados. Un reemplazo directo sobre SQL puede alterar la longitud almacenada dentro de una estructura serializada y romper el valor completo. Herramientas como WP-CLI entienden estas estructuras y permiten hacer el reemplazo correctamente. El mismo riesgo aparece al importar un WordPress de producción a local.
También conviene revisar URLs absolutas en configuraciones de plugins, contenido generado, cachés y archivos que no necesariamente viven dentro de la base de datos. El dominio está en más lugares de los que parece.
La migración termina después del cambio
Que la Home cargue desde el servidor nuevo no significa que la migración terminó. Después del corte hay que mirar lo que realmente importa. Hacer un pedido completo. Crear un usuario.
La validación incluye probar emails transaccionales, verificar stock, confirmar webhooks, ejecutar tareas programadas, revisar logs y comprobar integraciones. También hay que comparar pedidos recientes entre origen y destino y seguir observando durante las primeras horas.
Los problemas más importantes rara vez aparecen mirando la portada.
Tener vuelta atrás también forma parte del plan
Una migración debería tener un criterio claro para decidir cuándo seguir y cuándo volver. Si durante el cambio aparece un problema crítico, improvisar el rollback en ese momento es una mala estrategia. El servidor anterior debería permanecer disponible hasta confirmar que el nuevo entorno está estable.
Los backups deberían estar identificados. Y el equipo debería saber exactamente qué implica volver atrás. Un rollback no es admitir que la migración salió mal. Es una herramienta más de una migración bien preparada.
Mover datos es la parte fácil
Una migración de WooCommerce no es principalmente un problema de infraestructura. Es un problema de estado. Hay que saber qué información cambia, quién puede modificarla, qué procesos dependen de ella y cómo evitar que dos versiones distintas de la tienda empiecen a divergir.
Copiar WordPress es la parte mecánica. La migración se decide en el control del estado, la ventana de corte y la capacidad de volver atrás sin perder operaciones.