Descubre los errores frecuentes en migración WooCommerce que nadie documenta bien: datos rotos, integraciones caídas y cómo evitar downtime real.
Tabla de contenidos
- Por qué fallan las migraciones de WooCommerce: el problema de fondo
- Los errores más frecuentes en una migración de WooCommerce
- El error estructural: migrar sin entorno de staging
- Checklist de validación post-migración
- Migración entre proveedores de hosting: los problemas específicos
- Preguntas frecuentes sobre errores en migración de WooCommerce
- Cómo reducir el riesgo antes de empezar
La migración de WooCommerce concentra algunos de los errores más frecuentes y costosos del ecosistema WordPress. No porque sea un proceso especialmente complejo en papel, sino porque cada tienda lleva años de configuración acumulada: tablas de base de datos personalizadas, plugins con datos propietarios, integraciones con ERPs o CRMs, y reglas de envío que nadie documentó. Cuando todo eso se mueve a un servidor nuevo o a una infraestructura diferente, los problemas aparecen donde menos se esperan. Esta guía documenta los fallos reales que ocurren con más frecuencia, por qué ocurren exactamente y qué hacer para evitarlos antes de que lleguen a producción.
Por qué fallan las migraciones de WooCommerce: el problema de fondo
La mayoría de las guías de migración se centran en el proceso técnico: exportar la base de datos, copiar los archivos, actualizar el wp-config.php, cambiar las URLs. Es lo correcto, pero es solo el 40% del trabajo. El otro 60% son las dependencias invisibles que esa lista de pasos no cubre.
WooCommerce no es un plugin aislado. Es un ecosistema que integra tablas propias en la base de datos (wc_orders, wc_order_stats, wc_product_meta_lookup), configuraciones guardadas en wp_options con rutas absolutas, y extensiones que a veces almacenan datos en tablas completamente separadas. Un error frecuente en la migración de WooCommerce es asumir que mover los archivos y la base de datos es suficiente. No lo es si esas extensiones guardan claves de API con rutas hardcodeadas al dominio antiguo.
Según datos del repositorio de soporte de WordPress.org, los problemas post-migración son la segunda causa más común de consultas técnicas en tiendas WooCommerce, por detrás únicamente de los conflictos de plugins después de actualizaciones.
Los errores más frecuentes en una migración de WooCommerce
1. URLs absolutas rotas en la base de datos
Es el error más clásico y, aun así, el más repetido. Cuando se mueve una tienda de http://antiguo-dominio.com a https://nuevo-dominio.com, la base de datos sigue guardando la URL antigua en cientos de registros: imágenes de productos, descripciones, metadatos de pedidos, configuraciones de plugins.
El síntoma más visible son las imágenes rotas y los enlaces internos que redirigen al dominio anterior. La solución estándar es usar Better Search Replace con la opción de serialización activada, pero el error frecuente aquí es hacer el reemplazo sin serialización, lo que corrompe los arrays de PHP almacenados en la base de datos. El resultado: configuraciones de plugins que dejan de funcionar silenciosamente, sin mensajes de error evidentes.
2. Tablas de WooCommerce con datos huérfanos
WooCommerce introduce su propio sistema de pedidos (HPOS — High-Performance Order Storage) desde la versión 7.1. Si la tienda de origen tiene HPOS activado y el destino no, o viceversa, los pedidos migrados quedan en tablas distintas y la administración del panel no los muestra correctamente.
Este problema afecta especialmente a tiendas que llevan tiempo sin actualizar WooCommerce, porque al migrar también suelen actualizar la versión, y el cambio de sistema de almacenamiento de pedidos puede activarse automáticamente sin que el equipo lo haya planificado.
3. Integraciones de pago que pierden configuración
Las pasarelas de pago como Stripe, PayPal o Redsys guardan sus claves API y configuraciones de webhook en la base de datos, pero muchas también necesitan que el dominio esté verificado en el panel del proveedor. Después de una migración a un nuevo dominio, los webhooks de confirmación de pago siguen apuntando al dominio anterior. El resultado es que los pedidos se cobran pero no se actualizan en WooCommerce: el cliente paga, no recibe confirmación, y el equipo de soporte recibe reclamaciones.
La verificación de webhooks post-migración es uno de los pasos que más se omite en las checklist genéricas, porque requiere acceder al panel de cada proveedor de pago por separado.
4. Permisos de archivos incorrectos en el nuevo servidor
Al transferir archivos entre servidores, los permisos de carpetas y archivos cambian según la configuración del servidor de destino. WooCommerce necesita escribir en la carpeta uploads/ para guardar facturas PDF, certificados de producto y archivos descargables. Si los permisos son demasiado restrictivos (por ejemplo, 644 en lugar de 755 en carpetas), estas funciones fallan sin mensaje de error claro.
El error frecuente en este caso es no verificar los permisos en el servidor de destino antes de la migración, asumiendo que el proveedor de hosting los configura correctamente por defecto.
5. Diferencias de versión de PHP entre entornos
Un cambio de servidor casi siempre implica un cambio de versión de PHP. Si la tienda original corría en PHP 7.4 y el servidor nuevo usa PHP 8.2, los plugins que usan funciones obsoletas o deprecadas pueden fallar. WooCommerce en sí es compatible con las versiones modernas de PHP, pero sus extensiones de terceros, especialmente las más antiguas o las comerciales de menor calidad, no siempre lo son.
La buena práctica es revisar la compatibilidad de cada plugin activo con la versión de PHP del servidor destino antes de ejecutar la migración, no después. La herramienta PHP Compatibility Checker permite hacer este análisis en minutos.
El error estructural: migrar sin entorno de staging
Más allá de los errores técnicos específicos, el fallo más grave en una migración de WooCommerce es hacerla directamente en producción sin un entorno de staging intermedio. Es el error que convierte un proceso de cuatro horas en una crisis de dos días.
Un entorno de staging permite replicar exactamente el servidor de destino, ejecutar la migración completa, probar cada funcionalidad crítica (checkout, confirmaciones de pago, correos automáticos, integraciones con ERP) y solo después activar el cambio de DNS. El tiempo de inactividad visible para el cliente se reduce a minutos en lugar de horas.
p>El problema es que muchas migraciones se plantean «para el viernes por la noche» sin staging previo porque «no hay tiempo». Lo que no se calcula es el coste de tener la tienda caída durante el fin de semana porque el checkout no funciona en el nuevo servidor.Checklist de validación post-migración
Una vez completada la migración técnica, estos son los puntos que deben verificarse antes de dar el proceso por cerrado:
- Proceso de compra completo: añadir producto al carrito, checkout, pago real (en modo test si es posible), confirmación por email.
- Webhooks de pasarelas de pago: verificar en el panel de cada proveedor que la URL de callback apunta al nuevo dominio.
- Correos automáticos de WooCommerce: confirmación de pedido, cambio de estado, recuperación de carrito abandonado.
- Redirecciones 301: las URLs de productos y categorías del dominio anterior deben redirigir correctamente al nuevo dominio.
- Inventario y stock: verificar que los niveles de stock se corresponden con los de la tienda original.
- Integraciones externas: ERP, CRM, herramientas de email marketing. Comprobar que siguen recibiendo datos de la tienda.
- Logs de PHP y WooCommerce: revisar
wp-content/debug.logy los logs de WooCommerce durante las primeras 24 horas post-migración.
Este último punto —revisar los logs— es el que más se posterga. Los errores silenciosos que no rompen la tienda visualmente pero sí degradan su funcionamiento (pedidos que no sincronizan, emails que no llegan, inventario que no se actualiza) solo son visibles en los logs.
Migración entre proveedores de hosting: los problemas específicos
Cuando la migración implica cambio de proveedor de hosting, aparecen fallos adicionales relacionados con la infraestructura. Los más frecuentes son:
Configuración del servidor de correo
WooCommerce envía emails usando la función wp_mail(), que por defecto usa el servidor de correo del hosting. Al cambiar de proveedor, la configuración SMTP cambia. Si no se configura un plugin de SMTP o no se actualizan las credenciales, los correos de confirmación de pedido simplemente no llegan. Es uno de los problemas post-migración más reportados y uno de los más evitables.
Caché del servidor y objetos persistentes
Muchos proveedores de hosting gestionado para WordPress incluyen caché a nivel de servidor (Varnish, LiteSpeed Cache, Nginx FastCGI). Después de una migración, si la caché del nuevo servidor no está correctamente configurada, puede servir páginas del sitio antiguo o mezclar sesiones de usuario, lo que genera comportamientos erráticos en el carrito y en el proceso de checkout.
Las tiendas WooCommerce requieren que las páginas de carrito, checkout y cuenta de usuario estén excluidas de la caché. Esta configuración no es automática en todos los proveedores y debe verificarse explícitamente.
Preguntas frecuentes sobre errores en migración de WooCommerce
¿Se pueden perder pedidos durante una migración de WooCommerce?
Sí, si la migración se ejecuta mientras la tienda está activa y recibiendo pedidos. La práctica correcta es activar el modo mantenimiento o poner la tienda en modo solo lectura durante el proceso de transferencia de base de datos. Cualquier pedido registrado entre el backup y la activación del nuevo servidor no estará en la base de datos migrada.
¿Cuánto tiempo debe mantenerse el dominio antiguo activo tras la migración?
Al menos 48-72 horas. La propagación de DNS puede tardar hasta 48 horas en algunos proveedores. Durante ese tiempo, parte del tráfico puede seguir llegando al servidor antiguo. Mantenerlo activo y sin modificaciones evita que esos visitantes encuentren una web caída.
¿Los rankings SEO se ven afectados por una migración de WooCommerce?
Depende de cómo se gestionen las redirecciones. Si el dominio no cambia y solo cambia el servidor, el impacto es mínimo. Si el dominio cambia, las redirecciones 301 correctamente implementadas transfieren la mayor parte de la autoridad de SEO, pero es normal ver una fluctuación temporal en las primeras semanas. Lo que sí impacta directamente son las URLs rotas y los errores 404 que quedan sin redirigir.
¿Qué diferencia hay entre migrar con un plugin y hacerlo manualmente?
Los plugins de migración como Duplicator o All-in-One WP Migration automatizan la parte técnica básica, pero no verifican ni resuelven los problemas específicos de WooCommerce: webhooks de pago, integraciones de terceros, configuración de caché o compatibilidad de HPOS. Una migración manual bien planificada, con staging previo, permite identificar y resolver estos problemas antes de afectar a producción.
Cómo reducir el riesgo antes de empezar
La preparación previa es lo que diferencia una migración sin incidentes de una que deja la tienda caída un fin de semana. Antes de mover nada, conviene hacer un inventario completo de todas las integraciones activas: pasarelas de pago, plataformas de email marketing, sincronización con ERP o CRM, y plugins que generan datos propietarios.
Con ese inventario, la verificación post-migración se convierte en una lista de comprobación concreta, no en una revisión a ciegas. Si el proceso te genera dudas o implica una tienda con volumen alto de pedidos, los servicios de desarrollo WordPress especializados pueden asumir la ejecución técnica y la verificación completa, reduciendo el riesgo operativo real.
Mi opinión como desarrollador WordPress
Lo que más me sorprende después de años trabajando en migraciones de WooCommerce es que los errores frecuentes rara vez son puramente técnicos. La mayoría tienen un componente de planificación: nadie documentó las integraciones activas, nadie comprobó la versión de PHP del servidor destino, nadie configuró los webhooks de pago en el nuevo dominio. El proceso técnico en sí es manejable. Lo que lo complica es ejecutarlo bajo presión, sin staging y sin un inventario previo de dependencias. Cada vez que afronto una migración, lo primero que hago es ese inventario, antes de tocar un solo archivo. Esa hora de preparación es la que evita la crisis del domingo por la noche.
¿Necesitas ayuda con tu proyecto? Trabajo con negocios y agencias en WordPress, WooCommerce, IA e integraciones. Escríbeme y lo vemos juntos.
