Estudio de caso de migración de WordPress para Safer Moves
Publicado el 9 de agosto de 2026
Un estudio de caso de migración de WordPress es más útil cuando muestra lo que ocurrió entre el alegre plan de «mover los sitios este fin de semana» y el momento en que cada dominio vuelve a servir correctamente. Esa parte intermedia es donde las migraciones se ganan su reputación. Los archivos, las bases de datos, el DNS, los certificados SSL, la configuración del correo electrónico, los trabajos cron, el almacenamiento en caché y el comportamiento de los plugins pueden tener todos su propia opinión.
Este ejemplo sigue a una pequeña agencia digital que traslada 18 sitios web de WordPress desde un entorno de hosting compartido saturado a un servidor Linux administrado. Sus objetivos eran directos: mejorar la velocidad de las páginas, dar a cada cliente límites de cuenta más claros, reducir los tickets de soporte recurrentes y dejar de tratar cada actualización como un pequeño incidente de producción.
El resultado no fue magia. Fue un traslado estructurado, una breve ventana de mantenimiento para los sitios más activos y una mejor forma de administrar el servidor después del lanzamiento.
El punto de partida: 18 sitios, demasiados compromisos
La agencia había crecido gradualmente. Se añadían nuevos sitios de clientes a la misma cuenta de hosting, a menudo copiando la configuración que había funcionado la vez anterior y corrigiendo los detalles después. Era algo familiar, pero ya no resultaba cómodo.
Un pico de tráfico en un sitio de ecommerce podía afectar a sitios informativos no relacionados. Las copias de staging estaban repartidas en varios lugares. Existían copias de seguridad, aunque nadie podía decir con confianza qué copia de seguridad restauraría exactamente el sitio necesario. La agencia también tenía una visibilidad limitada del uso de CPU, memoria y disco, por lo que diagnosticar un sitio web lento normalmente empezaba con suposiciones.
El proveedor de hosting ofrecía un servicio de migración, pero la agencia necesitaba trasladarse según su propio calendario y conservar el control sobre cómo funcionarían después las cuentas, los accesos y las copias de seguridad. Ese requisito era importante. Una migración no consiste solo en llevar un sitio a otro servidor. Es una oportunidad para dejar de repetir las decisiones de configuración que crearon fricción desde el principio.
Estudio de caso de migración de WordPress: el plan de migración
La agencia dividió el trabajo en tres grupos: sitios de marketing con poco tráfico, sitios de publicación con mucho contenido y sitios de ecommerce o generación de leads donde incluso una interrupción breve podía costar dinero real. Esa categorización determinó el orden de la migración y el nivel de comprobación necesario.
Antes de copiar nada, el equipo creó un inventario para cada dominio. Incluía la versión de WordPress, la versión de PHP, el tamaño de la base de datos, el uso de disco, los plugins activos, los registros DNS, el estado de SSL, las tareas programadas, las dependencias del correo electrónico y los servicios externos, como pasarelas de pago o herramientas de formularios. No era un trabajo glamuroso, pero evitó el problema clásico de descubrir una configuración antigua pero necesaria después de que el DNS ya hubiera cambiado.
También definieron criterios de éxito. Una migración se consideraría completa solo cuando se hubieran comprobado la página de inicio, las páginas de destino clave, los formularios de contacto, el acceso a wp-admin, la biblioteca multimedia, las tareas programadas, las redirecciones HTTPS y los registros de errores. En los sitios de ecommerce, la lista de comprobación también incluía pedidos de prueba, correos electrónicos transaccionales, inicio de sesión en la cuenta y actualizaciones de inventario.
Elección de la configuración de destino
El nuevo servidor utilizaba cuentas separadas para cada cliente en lugar de colocar todos los sitios bajo un único usuario del sistema compartido. Esto mejoró el aislamiento y facilitó la entrega de accesos sin exponer los entornos de otros clientes.
La agencia eligió un panel de control porque las operaciones diarias debían seguir siendo prácticas tanto para desarrolladores como para gestores de cuentas. Con FASTPANEL, podían crear sitios web, administrar bases de datos y certificados SSL, organizar cuentas separadas y supervisar el uso de recursos del servidor desde un solo lugar. Eso no eliminó la necesidad de criterio técnico, pero sí eliminó muchas búsquedas innecesarias entre herramientas desconectadas.
Al principio mantuvieron la versión de PHP alineada con la de cada sitio existente. Actualizar PHP durante un traslado puede ser sensato, pero combinar dos cambios importantes dificulta la resolución de problemas. El equipo decidió migrar primero, estabilizar después y programar las actualizaciones tras verificar la compatibilidad de los plugins.
Copiar archivos y bases de datos sin copiar problemas antiguos
Para cada sitio, el equipo creó el sitio web y la base de datos de destino, luego transfirió los archivos de WordPress e importó una exportación de la base de datos. Actualizó las credenciales de la base de datos en el archivo de configuración y cambió con cuidado los valores específicos del entorno.
El principal riesgo técnico no era la transferencia de archivos. Era el manejo de las URL. Un sitio trasladado desde una dirección temporal de destino puede desarrollar enlaces incorrectos, redirecciones o datos serializados si el trabajo de buscar y reemplazar se realiza sin cuidado. El equipo utilizó un método de migración que respetaba las estructuras de datos de WordPress y luego comprobó el código fuente de la página, los enlaces internos, las imágenes y la configuración de los plugins, en lugar de asumir que la nueva página de inicio demostraba que todo funcionaba.
También revisaron qué no debía trasladarse. Las carpetas de caché antiguas, los archivos de copias de seguridad sin usar, los registros de desarrollo y los plugins abandonados aumentaban el uso de almacenamiento sin aportar nada al nuevo entorno. Eliminarlos redujo el desorden, pero solo después de verificar una copia de seguridad separada. Limpiar es útil. Limpiar antes de tener un punto de restauración es optimismo con cinturón de herramientas.
Probar antes de que el DNS haga el trabajo de verdad
Cada sitio migrado se probó en el servidor de destino antes de que cambiaran los registros DNS públicos. La agencia utilizó un método de acceso temporal para confirmar que el sitio resolvía al nuevo entorno para los probadores internos, mientras los visitantes seguían usando el host antiguo.
Esta fase encontró cuatro problemas que habría sido desagradable descubrir después del lanzamiento. Un sitio tenía una URL codificada de forma fija en la configuración de un page builder. Otro dependía de una configuración de correo vinculada al host anterior. Un plugin de membresía necesitaba que se restaurara su programación de tareas en segundo plano. Un sitio de ecommerce tenía una configuración de callback de pasarela de pago que solo reconocía la dirección del servidor anterior.
Ninguno de estos problemas fue catastrófico. Ese es el objetivo de las pruebas previas al lanzamiento. Un buen proceso de migración convierte las sorpresas en tickets que pueden resolverse antes de que los clientes las vean.
La agencia probó los formularios usando bandejas de entrada receptoras reales, no solo un mensaje de éxito verde en el sitio web. Comprobó los certificados SSL y forzó las redirecciones HTTPS. Revisó los registros del servidor y de la aplicación en busca de advertencias que no eran visibles en el front end. En los sitios más grandes, el equipo comparó una muestra de los tamaños de las tablas de la base de datos y de los directorios de uploads con el servidor de origen para detectar transferencias incompletas.
El cambio de DNS y la breve ventana de mantenimiento
Para los sitios con poco tráfico, la agencia cambió el DNS durante el horario comercial normal después de la aprobación de las pruebas. Para los sitios de ecommerce, eligió una franja nocturna de menor tráfico y activó brevemente el modo de mantenimiento mientras capturaba una exportación final de la base de datos.
Ese paso final de la base de datos es importante para los sitios web dinámicos. Los archivos cambian con menos frecuencia, pero los pedidos, las entradas de formularios, los registros de usuarios y los comentarios pueden escribirse en la base de datos en cualquier momento. Si la copia inicial se completó varias horas antes, una sincronización final de la base de datos evita que esos registros recientes se queden atrás.
El equipo redujo por adelantado los valores de tiempo de vida del DNS cuando fue posible. Aun así, esperaba que algunos visitantes llegaran brevemente al servidor antiguo porque la propagación de DNS no es un interruptor que se activa en todas partes al mismo tiempo. La antigua cuenta de hosting permaneció activa durante varios días como red de seguridad, pero se puso en un estado controlado para evitar cambios conflictivos.
Ningún sitio experimentó una caída prolongada. Dos sitios web tuvieron problemas menores de caché después del lanzamiento, y un formulario de contacto necesitó un ajuste de SMTP. Todos se solucionaron en la primera hora porque la agencia había asignado responsabilidades de monitorización en lugar de asumir que el trabajo terminaba cuando cambiaba el DNS.
Qué cambió después del traslado
La mejora inmediata fue la visibilidad. En lugar de esperar a que los clientes informaran de que un sitio parecía lento, la agencia podía ver la actividad de los recursos e investigar patrones. Las cuentas separadas también facilitaron identificar qué sitio consumía recursos y gestionar el acceso de los clientes con menos soluciones improvisadas.
La migración dejó al descubierto una verdad operativa: las mejoras de rendimiento no provinieron solo del nuevo servidor. Provinieron de corregir configuraciones de PHP desactualizadas, eliminar plugins abandonados, revisar el comportamiento de la caché y dar a los sitios con alta demanda espacio para operar sin competir con todos los demás proyectos.
La agencia también cambió su rutina de soporte. Ahora, cada nuevo sitio web de cliente recibe una cuenta documentada, una política de copias de seguridad, un proceso de actualización y una lista de comprobación de migración desde el primer día. Esa coherencia ahorra más tiempo que cualquier comando o plugin por sí solo.
Lecciones que vale la pena llevar a tu propio traslado
Primero, no trates todos los sitios de WordPress por igual. Un sitio de negocio local de cinco páginas y una tienda que procesa pedidos necesitan planes de cambio diferentes. Cuanto más dinámico sea el sitio, con más cuidado tendrás que gestionar los cambios finales en la base de datos y las pruebas.
Segundo, una copia de seguridad solo es útil cuando puede restaurarse. Verifica las copias de seguridad antes del día de la migración, mantén disponible una opción de rollback y decide quién puede tomar la decisión de revertir si algo sale mal. Una decisión clara de rollback es más tranquila que una improvisada a medianoche.
Tercero, evita acumular actualizaciones no relacionadas dentro de la migración, a menos que haya una razón clara. Un nuevo servidor, una nueva versión de PHP, un nuevo tema y una nueva capa de caché pueden funcionar juntos, pero también multiplican las posibles causas de un problema. Mueve primero. Mejora deliberadamente después de que el nuevo entorno sea estable.
Por último, planifica el trabajo posterior al cambio. Supervisa los recursos, revisa los registros, prueba las acciones críticas para el negocio y mantén disponible el entorno antiguo hasta que tengas confianza en que el tráfico y los datos se comportan correctamente. Una migración exitosa no es el momento en que un dominio apunta a una nueva dirección IP. Es el momento en que tu equipo puede administrar el sitio con más confianza que antes.
El mejor siguiente paso es sencillo: crea el inventario antes de elegir la fecha de la migración. Una vez que sepas de qué depende cada sitio, el traslado se convierte en un proyecto manejable en lugar de un juego nocturno de adivinanzas.