Un despliegue de WordPress puede cambiar más que los archivos de una versión. Una actualización de plugin o un desarrollo a medida también puede crear tablas, modificar opciones, transformar registros o alterar la forma en que se interpretan los datos existentes. Si código y base de datos quedan en estados incompatibles, el sitio puede fallar aunque la copia de archivos parezca completa.
Gestionar un despliegue WordPress con cambios de base de datos exige tratar cada modificación según su impacto y reversibilidad. El objetivo no es solo publicar código: es asegurar una transición controlada, comprobar los flujos críticos y saber qué hacer si la versión nueva no funciona como se esperaba.
Por qué restaurar archivos no siempre recupera el sitio
El código ejecuta operaciones sobre la base de datos, pero no contiene necesariamente el estado actual de esta. Si una versión nueva crea una tabla o cambia el formato de un valor, volver a los archivos anteriores no deshace esos cambios. El código antiguo podría no reconocer el esquema nuevo, o el sitio podría haber recibido datos que la versión anterior no sabe procesar.
También puede ocurrir lo contrario: restaurar una base de datos anterior mientras se mantienen los archivos nuevos puede dejar el sistema en un estado incoherente. En WooCommerce, por ejemplo, los pedidos y otros datos operativos pueden seguir cambiando durante y después del despliegue. Restaurar una copia previa de la base de datos podría borrar operaciones legítimas realizadas desde que se tomó esa copia.
Por eso conviene distinguir entre reversión de código, que devuelve los archivos a una versión anterior; reparación de datos, que corrige cambios concretos; y restauración, que recupera una copia de seguridad. No son acciones equivalentes ni tienen el mismo coste o impacto.
Inventariar cambios y dependencias antes de publicar
Antes de desplegar, registra qué cambia y dónde reside. Una lista útil separa cuatro categorías:
- Código: temas, plugins, código a medida, tareas programadas y dependencias.
- Esquema: tablas, columnas, índices u otras estructuras que se crean, modifican o eliminan.
- Datos: registros que se insertan, actualizan, transforman o eliminan, incluidas opciones y metadatos.
- Configuración y contenido: valores por entorno, credenciales, reglas, páginas o ajustes gestionados desde el panel.
Documenta quién ejecuta cada migración, cuándo se ejecuta y si es segura al repetirse. Comprueba si se activa automáticamente al actualizar un plugin o si requiere un comando, una tarea manual o una acción administrativa. Identifica también las dependencias: qué versión de código necesita la nueva estructura y qué procesos escriben en las tablas afectadas.
En WordPress, parte de la configuración puede estar en la base de datos y ser distinta entre producción y pruebas. No des por hecho que copiar una base de datos de un entorno a otro sea inocuo. Asimismo, los datos serializados o almacenados como opciones pueden requerir una transformación compatible con su formato, no una sustitución textual indiscriminada.
Diseñar una secuencia compatible y gradual
Cuando el cambio lo permita, utiliza una estrategia de expansión y contracción. Primero añade estructuras compatibles con la versión actual; después despliega código que pueda trabajar con el estado anterior y el nuevo; a continuación migra los datos y valida el resultado. Solo cuando la versión nueva esté estable se retiran columnas, rutas o estructuras antiguas que ya no se necesiten.
Esta secuencia reduce el riesgo de que una reversión de archivos deje el sitio sin una estructura que el código anterior espera. No todas las modificaciones pueden hacerse así: una transformación destructiva o un cambio incompatible puede exigir una ventana de mantenimiento, bloquear escrituras o requerir pasos específicos del proveedor del plugin. La decisión depende de la operación, el volumen de datos, la duración prevista y la capacidad de mantener el servicio.
Evita mezclar en una sola operación cambios de código, migraciones y limpieza irreversible sin puntos de control. Si una tarea tarda o falla a mitad, debe ser posible saber qué pasos terminaron. Define cómo reanudarla de forma segura, cómo evitar ejecuciones duplicadas y quién autoriza continuar. En despliegues por etapas, confirma que las versiones que conviven pueden operar sobre la base de datos compartida.
Probar en un entorno representativo
Un entorno de prueba aporta valor si reproduce las condiciones relevantes: versiones de PHP y WordPress, plugins, integraciones, configuración y tipos de datos. No tiene que copiar todos los datos reales, pero sí permitir probar las rutas afectadas. Si usas datos de producción, protege la información personal y limita accesos; una copia debe tratarse con las mismas precauciones que el origen.
Ensaya la migración y mide su duración con una cantidad de datos razonablemente representativa. Comprueba qué sucede si se interrumpe y si puede repetirse sin duplicar registros ni perder información. Después valida, como mínimo, la lectura y escritura de los datos afectados y los flujos de negocio relevantes: compra, pago, confirmación, gestión de pedidos o sincronización con sistemas externos, según corresponda.
Incluye pruebas de compatibilidad, permisos, tareas programadas y errores de integración. Una portada que carga no demuestra que el flujo de compra funcione. Si no puedes reproducir una integración en pruebas, define una comprobación alternativa y quién la realizará tras publicar.
Definir señales posteriores al despliegue
Antes de iniciar, establece qué significa que el despliegue ha salido bien y durante cuánto tiempo se observará. Las señales deben corresponder a los riesgos identificados, no limitarse a comprobar que el servidor responde. Pueden incluir:
- Errores de PHP, registros de aplicación y fallos de tareas programadas.
- Resultados de la migración: estructura esperada, recuentos o consistencia de los registros afectados.
- Operaciones de lectura y escritura y ejecución de los flujos críticos.
- Estado de pagos, webhooks, sincronizaciones y otras integraciones implicadas.
- Indicadores habituales del negocio, comparados con su comportamiento esperado en ese contexto.
Asigna responsables para revisar esas señales y fijar umbrales de pausa o reversión. Si aumenta un error, identifica primero si afecta a la aplicación, a la integración o a los datos; una alerta sin procedimiento de respuesta no basta para controlar el riesgo.
Preparar la recuperación y decidir si se autoriza
El plan debe indicar qué puede revertirse con seguridad y qué requiere reparación o restauración. Verifica que las copias de seguridad existan y que se puedan recuperar; una copia no probada no es una garantía operativa. Define el punto de recuperación, las dependencias del procedimiento y el impacto de descartar cambios legítimos posteriores a la copia. En una tienda activa, valora cómo preservar pedidos y operaciones recibidas durante la intervención.
Antes de publicar, acuerda quién decide, quién ejecuta y quién valida. Autoriza el despliegue solo si la migración se ha ensayado, las dependencias están identificadas, las comprobaciones tienen responsables y la recuperación es viable. Pausa si hay dudas sobre la compatibilidad entre versiones, si falla una prueba crítica o si no se puede proteger la actividad en curso. Revierte código cuando baste para recuperar compatibilidad; repara datos cuando el problema esté acotado; restaura únicamente conociendo qué cambios posteriores se perderían.
Lista de salida: inventario completo; respaldo verificado; secuencia y ventana definidas; pruebas aprobadas; señales y responsables asignados; y criterio explícito para continuar, pausar o recuperar. Esa disciplina convierte un cambio de base de datos en una operación controlada, no en una apuesta por que los archivos antiguos basten.
