Cómo sacar un sitio de cliente de una red WordPress Multisite

Si gestionas agencias o hosting en WordPress Multisite, este momento es inevitable: un cliente crece más que la red, quiere llevarse su sitio a su propio hosting, o simplemente necesitas aislarlo por cuestiones de facturación y soporte. En teoría, extraer un único subsitio parece una exportación de cinco minutos. En la práctica, es uno de los trabajos más sucios en WordPress. Esta guía explica el flujo de trabajo exacto para sacar un subsitio de forma limpia y reconstruirlo como un sitio independiente que el cliente pueda tener.

1. Por qué la extracción de un solo subsitio es tan dolorosa

Un subsitio de Multisite no es un sitio autónomo. Es un conjunto de tablas con prefijos (wp_5_posts, wp_5_options, y así sucesivamente) que comparten tablas globales para los usuarios, usermeta y ajustes de la red. La pantalla nativa de Tools > Export solo te da un archivo XML con entradas, páginas y multimedia. Deja atrás:

• Los usuarios y sus roles, que viven en las tablas globales compartidas
• Las configuraciones de plugins y themes guardadas en la tabla options del subsitio
• Las tablas personalizadas creadas por formularios, e-commerce o plugins de membresía
• Los datos serializados donde la antigua URL o ruta del subsitio está grabada a fuego

Si reconstruyes a partir de ese XML solamente, pasarás días volviendo a crear cuentas, reconfigurando plugins y cazando enlaces rotos. El objetivo en cambio es conseguir una copia completa, byte por byte, solo de los datos de ese subsitio, y luego hacer un restore limpio en una instalación que nunca fue un Multisite.

2. Elige la arquitectura de destino

Decide dónde vivirá el sitio extraído antes de exportar. Hay dos buenos resultados posibles:

• Una instalación independiente (single-site). Una instalación de WordPress normal en el hosting de tu cliente o en el tuyo. Esta es la opción totalmente independiente y la que los clientes normalmente quieren cuando se van.
• Un tenant de GrabWP aislado. Si quieres mantener los beneficios operativos de un único código base pero con separación real, reubica el sitio como un tenant utilizando el plugin gratuito GrabWP Tenancy. Cada tenant tiene uploads aislados, su propio prefijo de tablas y enrutamiento basado en domain o ruta, por ejemplo yoursite.com/site/client-a, sin hacer cambios de DNS.

De cualquier forma, el destino es un entorno single-site, no otro Multisite. Eso es clave para el paso de restore que veremos más abajo.

3. Exporta los datos del subsitio

La forma limpia de capturarlo todo es con un backup por tenant desde GrabWP Tenancy Pro. Su función de backup genera el archivo de exportación que la herramienta de restore lee: un paquete completo de la database y el wp-content del sitio, no solo un volcado XML.

1. En el entorno de origen, ejecuta el backup por tenant para el subsitio que vas a mudar.
2. El backup de 7 pasos funciona con progreso por AJAX para que puedas ver cómo avanza.
3. Descarga el archivo ZIP resultante. Este archivo es el único elemento que te llevas al nuevo hogar.

Esto es importante porque GrabWP Restore solo acepta archivos ZIP generados por la función de backup de GrabWP Tenancy Pro. No es un importador genérico para cualquier backup al azar, y esa limitación es lo que hace que el restore sea predecible.

4. Reconstrúyelo limpio con GrabWP Restore

Levanta una instalación de WordPress single-site nueva en el destino y luego instala el plugin gratuito GrabWP Restore.

1. Ve a Tools > GrabWP Restore (solo para administradores).
2. Sube el ZIP de exportación del paso 3.
3. Confirma la advertencia explícita del backup que requiere el plugin antes de continuar.
4. Ejecuta el restore de 8 pasos y mira el progreso por AJAX.

Por detrás, Restore hace el trabajo pesado en el que las migraciones manuales suelen fallar: una importación SQL en streaming que maneja databases grandes sin agotar la memoria, reescritura automática del prefijo de las tablas para que coincidan con las del destino, y compatibilidad de collation para MySQL 5.7 y 8.0, asegurando que la importación no se cuelgue por problemas de charset.

Una regla estricta: Restore está intencionalmente desactivado en Multisite. Las operaciones destructivas en toda la red necesitan un flujo de trabajo que entienda la red, por lo que siempre haces el restore en una instalación single-site nueva, nunca en una red en producción. Si intentas atajar haciendo el restore en otro Multisite, la herramienta te detendrá.

5. Verifica las URLs y los datos serializados

Aquí es donde las migraciones ingenuas fallan. La antigua URL o ruta del subsitio está escrita en cientos de filas, incluyendo arrays serializados que un simple buscar y reemplazar destruye. GrabWP Restore se encarga de esto por ti:

• Site URL auto-update configura las URLs del sitio y de inicio al nuevo destino.
• Database-wide URL search-and-replace reescribe la antigua dirección en todas partes, incluyendo los datos serializados y codificados por el theme, de modo que los diseños del page builder, las opciones de widgets y la configuración de plugins sigan funcionando.

Después de que termine el restore, haz una revisión rápida del resultado:

1. Inicia sesión y confirma que tu cuenta de admin y los roles se pasaron correctamente.
2. Abre una página creada con tu page builder y confirma que las imágenes y módulos se ven bien.
3. Busca en el front end si queda alguna referencia a la antigua ruta /subsite.
4. Confirma que los uploads resuelven bien, ya que Restore hace un restore de archivos seguro que renombra los directorios plugins, themes y uploads existentes a .old antes de escribir los nuevos, para que nada se sobrescriba silenciosamente.

6. Entrégalo o reubícalo como un tenant aislado

Llegado a este punto, tienes dos caminos limpios:

• Entrégalo. La instalación independiente es totalmente del cliente. Pásale las credenciales del hosting y habrás terminado. Sin tablas compartidas, sin dependencias de la red.
• Reubícalo como un tenant aislado. Mantenlo en la infraestructura que administras, pero como un verdadero tenant. Con GrabWP Tenancy Pro cada tenant puede usar un prefijo de MySQL compartido, una database de MySQL dedicada o SQLite, y obtiene su propio wp-content aislado. Esa es una separación real para soporte y facturación, sin el acoplamiento de tablas compartidas que hacía tan difícil la extracción en un principio.

7. Evita este dolor la próxima vez

La razón por la que este trabajo es difícil es de arquitectura: Multisite vincula cada subsitio a tablas globales compartidas. Si esperas que los clientes vengan y se vayan, empieza con una arquitectura de aislamiento de datos donde cada sitio ya sea independiente desde el inicio. Al ejecutar los sitios de los clientes como tenants de GrabWP, cada uno ya tiene sus uploads aislados, su propio prefijo y enrutamiento independiente, por lo que “sacar a un cliente” se convierte en “ejecutar un backup y un restore” en lugar de un trabajo de desenredo de varios días.

Empieza ahora

El flujo de trabajo de extracción que vimos arriba funciona con herramientas gratuitas más una de pago: GrabWP Restore y GrabWP Tenancy son gratis, y el backup por tenant que genera el archivo de exportación restaurable es parte de GrabWP Pro a $9.99/month. Si todavía estás evaluando si Multisite encaja en tu agencia, lee cuándo no usar WordPress Multisite a continuación.