Migración WooCommerce sin cortar ventas
Caso anonimizado: tienda retail de Santiago con 8k pedidos/mes migrada desde hosting saturado a operación gestionada.
Cliente anonimizado: Tienda WooCommerce de retail en Santiago con 8k pedidos/mes
El problema no era “WordPress lento”. Era una tienda vendiendo sobre una base cansada.
El cliente tenía WooCommerce, catálogo grande, campañas activas y un hosting compartido que ya no daba más. El síntoma visible era simple: carrito lento, checkout intermitente, administrador pesado. El síntoma de negocio era peor: cada caída coincidía con ventas, reclamos y conversaciones internas que partían con “¿quién está viendo esto?”.
No entramos cambiando todo. Primero congelamos el riesgo.
Pedimos accesos, inventariamos DNS, correo, plugins, versión de PHP, tamaño de base de datos, tareas cron, pasarelas de pago, integraciones de despacho y reglas de caché. Antes de tocar producción hicimos respaldo completo: archivos, base de datos y configuración crítica. También dejamos claro qué no íbamos a hacer: instalar cinco plugins mágicos ni prometer puntajes perfectos que no mueven ventas.
La migración se preparó en un entorno paralelo. Misma tienda. Misma data. Otra infraestructura.
Ahí aparecieron las causas reales: consultas pesadas en búsquedas internas, sesiones acumuladas, imágenes enormes, caché mal aplicada sobre páginas que no debían cachearse y un plugin de reportes ejecutando procesos en horas de alto tráfico. Nada raro. Cosas comunes cuando una tienda crece por años sin operación técnica constante.
Ordenamos por impacto.
Primero estabilidad: separar recursos, ajustar PHP workers, configurar caché de objeto, revisar límites, dejar backups automáticos y monitoreo básico. Luego performance: reglas de caché cuidadas para catálogo, producto y carrito; limpieza de tablas transitorias; compresión de assets; revisión de imágenes críticas. Después operación: bitácora de cambios, ventana de migración, plan de reversa y checklist de post-migración.
La noche del cambio fue aburrida, como debe ser.
Bajamos TTL antes. Sincronizamos archivos. Congelamos edición por minutos, no por horas. Exportamos base final. Cambiamos DNS. Revisamos home, búsqueda, producto, carrito, checkout, Webpay, emails transaccionales y panel de administración. Dejamos el hosting antiguo vivo como respaldo temporal, sin borrar nada. El cliente no tuvo que explicar internamente una caída larga porque no hubo una.
Después vino la parte que muchas migraciones omiten: observar.
Durante los primeros días miramos logs, errores 500, tiempos de respuesta, consumo de CPU, consultas lentas y comportamiento de caché. Ajustamos lo pequeño: cron real en vez de tráfico simulando cron, límites de memoria donde correspondía, exclusiones para carrito y checkout, y alertas para saber antes que el cliente cuando algo se degrada.
El resultado práctico: la tienda dejó de vivir al borde. El administrador respondió mejor. El checkout dejó de sentirse como apuesta. El equipo comercial pudo planificar campañas sin preguntar si el servidor iba a aguantar.
No fue una “optimización”. Fue operación responsable.
La lección: WooCommerce puede sostener volumen serio, pero no sobre hosting genérico y decisiones acumuladas al azar. Necesita una base técnica que entienda comercio: caché sin romper carrito, backups antes de tocar, monitoreo real, ventanas de cambio y alguien que responda cuando hay plata pasando por el sitio.
Si una tienda ya vende, migrarla no es mover archivos. Es proteger caja.