Migración y multisite: Gestión avanzada de WordPress

Dos temas que asustan a los administradores principiantes: “¿Cómo muevo un sitio sin romper nada?” y “¿Qué es este Multisite y lo necesito?”. Vamos a abordarlos. Migración y Multisite son dos decisiones distintas que a menudo se mezclan: una migración mueve archivos, base de datos y DNS, mientras que Multisite cambia la forma en que varios sitios comparten una sola instalación de WordPress. La referencia oficial para la parte de red es el manual de WordPress Multisite.

Conoce más sobre los servicios de desarrollo WordPress en WPPoland.

#Cómo migrar WordPress a otro hosting

Mover un sitio (por ejemplo, del servidor local a producción o cambiando de hosting) es un proceso de 3 pasos:

1. Archivos: Copia todo desde public_html (mejor por SSH que por FTP, como se explica abajo).
2. Base de datos: Exporta el archivo .sql (por ejemplo, a través de phpMyAdmin).
3. Cambio de dominio (momento clave!): WordPress almacena la dirección del sitio en muchos lugares de la base de datos (en wp_options, pero también en el contenido de posts como enlaces de imágenes).

Error de principiante: Editar manualmente el archivo SQL en el bloc de notas. Esto rompe los “datos serializados” (arrays serializados) de plugins y widgets. Método profesional: Usa WP-CLI (wp search-replace 'viejo.com' 'nuevo.com') o Better Search Replace. Mantienen la integridad de los datos.

#Por qué un reemplazo SQL rompe los datos serializados de PHP

WordPress guarda buena parte de las opciones del tema, la configuración de widgets y los datos de plugins (por ejemplo Advanced Custom Fields o los diseños de un maquetador) como cadenas PHP serializadas. Así puede verse un ajuste en la tabla wp_options:

a:2:{s:4:"host";s:14:"sitio-viejo.es";s:4:"port";i:3306;}

Aquí s:14 declara que la cadena sitio-viejo.es tiene exactamente 14 caracteres. Si cambias el dominio con buscar y reemplazar en un editor de texto, o con un UPDATE wp_options SET option_value = REPLACE(...), por tienda-nueva.es (15 caracteres), la declaración sigue diciendo s:14.

La próxima vez que WordPress llame a unserialize(), PHP encuentra 15 caracteres donde esperaba 14, muestra el aviso unserialize(): Error at offset, abandona y descarta el array completo. Resultado: desaparecen widgets, las opciones de diseño vuelven a los valores por defecto y se pierden claves de API. WP-CLI evita el problema porque deserializa cada valor en memoria, reemplaza la cadena, recalcula las longitudes y vuelve a serializar antes de escribir en MySQL. Tampoco modifica los valores de las claves primarias.

#Pasos para migrar WordPress a otro servidor

#Paso 1: Preparación y respaldo completo

Antes de tocar cualquier cosa, crea un respaldo completo de ambos entornos:

# En el servidor de origen
wp db export respaldo-origen.sql
tar -czf respaldo-archivos.tar.gz .

Descarga ambos archivos a tu computadora local como seguro adicional.

#Paso 2: Transferencia de archivos

Copia todos los archivos al nuevo servidor. Para sitios grandes, evita FTP y usa SSH:

# Usando rsync para transferencia eficiente
rsync -avz -e ssh /ruta/local/ usuario@nuevo-servidor:/ruta/destino/

Rsync es superior a FTP porque:

• Solo transfiere archivos que han cambiado
• Mantiene permisos de archivo
• Puede reanudar transferencias interrumpidas
• Es significativamente más rápido para grandes cantidades de archivos

#Paso 3: Importación de base de datos

Importa la base de datos en el nuevo servidor:

# Vía WP-CLI
wp db import respaldo-origen.sql

# O vía línea de comandos MySQL
mysql -u usuario -p nombre_db < respaldo-origen.sql

#Paso 4: Buscar y reemplazar el dominio

Este es el paso crítico. Nunca hagas esto manualmente:

# Vista previa sin hacer cambios (mismas tablas y opciones que la ejecución real)
wp search-replace 'https://sitio-viejo.com' 'https://sitio-nuevo.com' --all-tables --skip-columns=guid --dry-run

# Con WP-CLI (método recomendado)
wp search-replace 'https://sitio-viejo.com' 'https://sitio-nuevo.com' --all-tables --skip-columns=guid

WP-CLI maneja los datos serializados por defecto: según la referencia de search-replace, el comando usa consultas SQL rápidas y cambia por su cuenta a PHP en las columnas que contienen datos serializados, recalculando los contadores de longitud. La opción --precise no es lo que protege esos datos; solo fuerza PHP en todas las columnas, lo que es más lento y útil únicamente con estructuras inusualmente complejas. --recurse-objects ya está activado por defecto. Lo que sí importa es --skip-columns=guid, por el motivo que se explica más abajo en la sección sobre la URL del sitio.

#Paso 5: Actualizar wp-config.php

Actualiza las credenciales de la base de datos en el nuevo servidor:

define('DB_NAME', 'nueva_base_datos');
define('DB_USER', 'nuevo_usuario');
define('DB_PASSWORD', 'nueva_contraseña');
define('DB_HOST', 'localhost');

#Paso 6: Verificación post-migración

Después de la migración, verifica:

1. Página principal: Carga correctamente sin errores
2. Panel de administración: Puedes iniciar sesión y navegar
3. Enlaces internos: Los enlaces apuntan al nuevo dominio
4. Imágenes: Todas las imágenes se muestran correctamente
5. Formularios: Los formularios de contacto envían correctamente
6. Plugins: Todos los plugins están activos y funcionando
7. SSL: El certificado SSL está configurado correctamente

#Cómo migrar WordPress sin tiempo de inactividad

Para mover tiendas con mucho tráfico o portales de captación de clientes sin perder transacciones ni confundir a los rastreadores de los buscadores, sigue esta secuencia de cuatro fases:

#Fase 1: reducir el TTL del DNS 48 horas antes

Baja el TTL (Time to Live) de los registros A del dominio a 300 segundos (5 minutos). Así las cachés DNS de todo el mundo se actualizan rápido cuando se publica la IP del nuevo servidor.

#Fase 2: sincronización incremental de archivos con rsync

El FTP tradicional es lento, no cifra y falla en silencio con bibliotecas de medios grandes. Usa rsync por SSH para copiar los archivos directamente entre servidores, excluyendo los directorios de caché temporales:

rsync -avzP --delete \
  --exclude 'wp-content/cache/*' \
  --exclude 'wp-content/uploads/cache/*' \
  --exclude '*.log' \
  [email protected]:/var/www/vhosts/sitio.com/public/ /var/www/html/

La opción -a conserva permisos y fechas de los archivos, y -z comprime los datos durante la transferencia.

#Fase 3: ventana de cambio

1. Activa el modo de mantenimiento en el servidor de origen: wp maintenance-mode activate.
2. Genera un volcado limpio de la base de datos: wp db export cambio.sql --add-drop-table.
3. Transfiere el volcado e impórtalo en el nuevo servidor: wp db import cambio.sql.
4. Ejecuta wp search-replace para actualizar las URL del sitio, el protocolo SSL o las diferencias de rutas.
5. Comprueba el sitio desde tu equipo asignando el dominio a la nueva IP en el archivo hosts local.

#Fase 4: cambio de DNS y verificación

Actualiza el registro A del DNS para que apunte a la IP del nuevo servidor. Como el TTL se redujo a 300 segundos en la fase 1, el tráfico pasa al nuevo servidor en cuestión de minutos. Cuando el DNS se haya propagado por completo, restaura el TTL habitual (86400 segundos).

#Cómo hacer copias de seguridad en WordPress

La regla 3-2-1:

• 3 copias de datos.
• 2 medios diferentes (ej. servidor + nube).
• 1 copia fuera del sitio (fuera de la oficina).

No dependas solo del hosting. Instala UpdraftPlus o Duplicator y envía copias a Google Drive/Dropbox. Es tu póliza de seguro contra ataques o contra incidentes como el incendio del centro de datos de OVH en Estrasburgo en marzo de 2021.

#Con qué frecuencia hacer copias de seguridad de WordPress

Respaldos diarios:

• Base de datos completa
• Archivos modificados (incremental)
• Retención: 30 días

Respaldos semanales:

• Todos los archivos y base de datos
• Retención: 12 semanas

Respaldos mensuales:

• Respaldo completo del sitio
• Retención: 12 meses

#Automatización de respaldos con WP-CLI

#!/bin/bash
# Respaldo diario de base de datos y archivos
FECHA=$(date +%Y%m%d)
SITIO="/var/www/html"
DESTINO="/respaldos/$FECHA"

mkdir -p $DESTINO

# Exportar base de datos
cd $SITIO && wp db export $DESTINO/db-$FECHA.sql

# Comprimir archivos
tar -czf $DESTINO/archivos-$FECHA.tar.gz -C $SITIO .

# Subir a S3 (opcional)
aws s3 cp $DESTINO/ s3://mi-bucket/respaldos/$FECHA/ --recursive

#Cómo probar la restauración de una copia de seguridad

Un respaldo que no has probado no es un respaldo. Programa pruebas de restauración trimestrales:

1. Configura un entorno de staging
2. Restaura el respaldo más reciente
3. Verifica que todo funciona correctamente
4. Documenta el tiempo que tomo la restauración

#Qué es WordPress multisite y cuándo usarlo

Multisite (MU) es una funcionalidad que permite ejecutar 100, 1000 o un millón de sitios en una instalación de WordPress.

• Un conjunto de archivos (core, temas, plugins).
• Una base de datos (con tablas separadas para cada sitio).
• Un super-administrador.

¿Cuándo usarlo?

• Tienes una red de sitios de franquicia (ej. nuevayork.empresa.com, boston.empresa.com).
• Eres una universidad dando un blog a cada estudiante/profesor.
• Ejecutas un servicio multilingüe (aunque WPML/Polylang en una sola instalación a menudo funciona mejor aquí).

¿Cuándo NO usarlo?

• Cuando tienes 5 sitios para clientes completamente diferentes. Si un sitio “muere” (error PHP), todos caen. La base de datos de usuarios compartida también puede ser problemática.

• Cuando los sitios necesitan versiones de PHP, planes de hosting o zonas de seguridad distintas.

Multisite es una herramienta poderosa, pero requiere un servidor sólido y conocimiento de administración. No lo habilites “por diversión”.

#Tablas de la base de datos en WordPress multisite

Una instalación estándar de WordPress tiene 12 tablas principales. En Multisite, WordPress separa los datos globales de los datos de cada sitio:

• Tablas globales de la red: wp_users y wp_usermeta (cada cuenta existe una sola vez en toda la red, con roles distintos por sitio), y wp_blogs, wp_site y wp_sitemeta, que guardan los ajustes de la red, la política de registro y la lista de sitios.
• Tablas de cada sitio: cada sitio nuevo recibe su propio juego identificado por su ID; el sitio 2 trabaja con wp_2_posts, wp_2_options y wp_2_comments.

+-----------------------------------------------------+
|             Esquema de WordPress Multisite          |
+-----------------------------------------------------+
| Tablas globales:                                    |
| - wp_users / wp_usermeta                            |
| - wp_blogs / wp_site / wp_sitemeta                  |
+-----------------------------------------------------+
| Sitio principal (ID 1):                             |
| - wp_posts, wp_options, wp_terms...                 |
+-----------------------------------------------------+
| Subsitio (ID 2, p. ej. sevilla.marca.es):           |
| - wp_2_posts, wp_2_options, wp_2_terms...           |
+-----------------------------------------------------+

Para elegir con criterio: Multisite encaja cuando los sitios están relacionados (franquicias, campus, departamentos de una misma organización) y se acepta que una mala actualización de un plugin afecte a toda la red. Las instalaciones separadas encajan cuando los clientes son entidades jurídicas sin relación, porque entonces el aislamiento es un requisito. El manual añade otro matiz: si los sitios necesitan compartir muchos datos o usuarios, o solo requieren temas distintos por sección, una sola instalación con un plugin puede encajar mejor que una red.

#Requisitos antes de crear una red WordPress multisite

El capítulo Before you create a network enumera restricciones que la pantalla Configuración de red aplica, y la mayoría de las conversiones fallidas chocan con alguna de ellas.

No se puede crear la red cuando la dirección de WordPress usa un puerto distinto de 80 o 443. La instalación con subdominios queda bloqueada cuando la URL de WordPress contiene una ruta (WordPress no está en la raíz del documento), cuando la dirección es localhost o cuando es una IP como 127.0.0.1. Para pruebas locales, el manual sugiere asignar un nombre de host propio a 127.0.0.1 en el archivo hosts. La instalación con subdirectorios queda bloqueada cuando la instalación existente tiene más de un mes, porque las entradas del sitio principal chocarían con las rutas de los subsitios. En una red por rutas, las URL de las entradas del sitio principal reciben además el prefijo /blog/.

En el servidor, Apache necesita mod_rewrite con soporte para .htaccess, FollowSymLinks sin desactivar y AllowOverride en All o Options All para el vhost. Los enlaces permanentes amigables deben funcionar ya en el sitio único. Decide el dominio, incluida la cuestión del www, antes de activar la red. Si WordPress debe ejecutarse desde su propio directorio, ese cambio también va antes. El DNS comodín solo hace falta cuando los usuarios crean sitios en subdominios bajo demanda; los sitios añadidos a mano pueden usar registros DNS propios o hosts virtuales.

#Cómo crear una red WordPress multisite paso a paso

El procedimiento Create a Network tiene un orden que importa:

1. Copia de seguridad de la base de datos y de los archivos.
2. Desactivar todos los plugins. Se pueden reactivar cuando la red ya exista.
3. Habilitar Multisite en wp-config.php, encima de la línea /* That's all, stop editing! Happy publishing. */:

define('WP_ALLOW_MULTISITE', true);

4. Ir a Herramientas > Configuración de red en el panel de WordPress y elegir entre subdominios o subdirectorios:
   • Subdominios: sitio1.midominio.com (DNS comodín solo si los usuarios crean sitios bajo demanda)
   • Subdirectorios: midominio.com/sitio1/ (no disponible si la instalación tiene más de un mes)
5. Agregar las constantes generadas a wp-config.php, justo debajo de la línea de WP_ALLOW_MULTISITE:

define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'midominio.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

6. Sustituir el bloque de WordPress en .htaccess por las reglas que muestra la pantalla (en Nginx se convierten en reglas del bloque server). Haz copia de ambos archivos antes de editarlos.
7. Volver a iniciar sesión con el enlace que muestra WordPress; a veces hay que borrar las cookies del navegador. “Mis sitios” incluye entonces el menú Administración de la red.

Cambiar más adelante entre subdominios y subdirectorios es posible, pero el manual advierte que puede no ser sencillo, así que decide antes de crear el primer subsitio.

#Mapeo de dominios en multisite sin plugin

Desde WordPress 4.5 el mapeo de dominios es una función nativa, según el capítulo de mapeo de dominios. El orden de trabajo es este: primero, cada dominio debe apuntar al servidor en el DNS. Después, TLS para el dominio principal y certificados SNI para los demás, de modo que todo inicio de sesión en el panel vaya cifrado. Solo entonces se escribe la URL completa, por ejemplo https://cliente.es, en el campo Dirección del sitio (URL) del subsitio, en Sitios > Editar sitio. Baja el TTL un día antes y cambia la dirección solo cuando el servidor ya responda con el nuevo nombre de host. Si el inicio de sesión en un sitio mapeado falla con un error de cookies bloqueadas, o sin ningún mensaje, el manual indica añadir esta línea después de las constantes de la red:

define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );

#Gestión de plugins en Multisite

En Multisite, los plugins pueden activarse de dos formas:

• Network Activate: El plugin está activo en TODOS los sitios de la red
• Per-Site Activate: El plugin se activa solo en un sitio. Los administradores de cada sitio pueden hacerlo únicamente si el superadministrador habilita el menú Plugins en los ajustes de la red; instalar plugins sigue siendo tarea exclusiva del superadministrador

Mejor práctica: Activa a nivel de red solo los plugins que de verdad necesita cada sitio, porque un plugin activado en la red carga su código en cada petición de cada sitio. Los plugins de funcionalidad que usa un solo sitio se activan en ese sitio.

#Roles de usuario entre sitios en WordPress multisite

En Multisite todos los usuarios están en una tabla compartida. La pertenencia y los roles se asignan por sitio.

Qué significa en la práctica:

• Un administrador de sevilla.marca.es no puede instalar plugins. Esa es tarea del superadministrador.
• Eliminar un usuario desde la Administración de la red borra la cuenta en todas partes, no solo en una sucursal.
• Un inicio de sesión común para varias marcas llega de forma natural con Multisite; el aislamiento entre clientes, no.

Documenta quién es superadministrador y mantén ese número bajo. Demasiados superadministradores es la causa habitual de “alguien activó un plugin en la Administración de la red y se cayeron tres sitios”.

#Cómo unir varios sitios WordPress en una red multisite

Activar la red sobre una instalación existente, como se describe arriba, no es lo mismo que fusionar cinco instalaciones independientes. Cada sitio adicional tiene que entrar mediante exportación e importación (WXR), WP-CLI o una herramienta que entienda los prefijos de tabla de Multisite.

Orden recomendado:

1. Copia completa de archivos y base de datos de todos los sitios de origen (3-2-1: tres copias, dos medios, una fuera de la oficina).
2. Montar la red en staging con la misma versión de PHP que producción.
3. Crear sitios vacíos en la Administración de la red con sus dominios o subdominios definitivos.
4. Importar el contenido sitio por sitio. Después, ejecutar search-replace de las URL antiguas solo dentro de las tablas de ese sitio, con --url=<sitio> y sin --network.
5. Asignar usuarios: los correos repetidos pasan a ser una sola cuenta y los roles se asignan por sitio.
6. Revisar los medios. Los archivos de un subsitio están en wp-content/uploads/sites/{id}/.
7. Bajar el TTL del DNS, cambiar y tener listo el SQL para revertir.

#Cómo sacar un sitio de WordPress multisite

A veces la red resulta ser el modelo equivocado. Entonces se exporta un sitio:

1. Identificar el blog_id y el prefijo de tablas (wp_5_, etc.), por ejemplo con wp site list --fields=blog_id,url.
2. Exportar el contenido (WXR) o clonar las tablas a una base de datos nueva con el prefijo estándar wp_.
3. Copiar los medios de uploads/sites/{id}/ a la carpeta normal uploads/.
4. Actualizar siteurl y home y después ejecutar search-replace.
5. Instalar solo los plugins y temas que ese sitio usaba de verdad, no todo el directorio de la red a ciegas.

Planifica redirecciones desde las antiguas URL en subdominio hacia el nuevo dominio. Si no, se pierde autoridad de enlaces y Search Console se llena de errores 404.

#Cómo cambiar la URL del sitio WordPress después de una migración

Ajustes > Generales tiene dos campos: Dirección de WordPress (URL), donde están los archivos del núcleo, y Dirección del sitio (URL), la que escriben los visitantes. Cuando tras una mudanza no se puede entrar al panel, el capítulo de migración documenta cuatro formas de corregirlas. Sirven para instalaciones únicas; para Multisite el manual remite a la base de datos, como se ve en la sección siguiente.

1. wp-config.php: define( 'WP_HOME', 'https://example.es' ); y define( 'WP_SITEURL', 'https://example.es' );. Los valores quedan fijados en el código y los campos de Ajustes generales ya no se pueden editar.
2. functions.php: dos llamadas a update_option() para siteurl y home en el tema activo, cargadas una vez y retiradas. El manual insiste en que el código no debe quedarse en el archivo.
3. RELOCATE: define('RELOCATE', true); en wp-config.php y después abrir wp-login.php en la nueva dirección. Solo corrige la URL del sitio y nada más. Dejar la constante es inseguro, porque en algunas configuraciones permite a un atacante cambiar la dirección del sitio. Elimínala en cuanto termines.
4. Base de datos o WP-CLI: editar siteurl y home en wp_options, o ejecutar wp option update home 'https://example.es' y wp option update siteurl 'https://example.es'.

El mismo capítulo tiene una regla que conviene repetir: nunca se modifica la columna guid de wp_posts. Los lectores de feeds usan el GUID para reconocer las entradas que ya mostraron, así que reescribirlo hace que las entradas antiguas reaparezcan como nuevas. Por eso el ejemplo de WP-CLI de la documentación usa --skip-columns=guid. Las direcciones antiguas también pueden quedar en transients; en la copia migrada se pueden borrar sin riesgo (wp transient delete --all), porque WordPress los vuelve a generar cuando los necesita.

Mover WordPress a otro directorio del mismo servidor tiene su propio orden: primero se cambian las dos URL en Ajustes y después se mueven los archivos. Si los archivos se movieron antes, el manual propone un enlace simbólico temporal de la ruta antigua a la nueva (ln -s /path/to/new /path/to/old), tras el cual los pasos normales funcionan.

#Cómo ejecutar wp search-replace en una red multisite

En Multisite, wp search-replace solo toca por defecto las tablas del sitio actual. La referencia del comando define los alcances:

• sin opción: las tablas registradas en $wpdb para el sitio indicado con --url (el principal por defecto),
• --network: todas las tablas registradas en $wpdb en toda la red,
• --all-tables-with-prefix: cualquier tabla con el prefijo de WordPress, registrada o no,
• --all-tables: todas las tablas de la base de datos, sea cual sea su prefijo. Anula --network, de modo que en una base compartida con otras aplicaciones también alcanza sus tablas.

Las tablas sin clave primaria se omiten sin aviso; wp db query 'DESCRIBE <tabla>' muestra si existe PRI. La forma documentada de convertir una red de producción en una copia local reescribe también las tablas de la red de manera explícita:

wp search-replace --url=example.es example.es example.test \
  'wp_*options' wp_blogs wp_site --network --skip-columns=guid

--export=red.sql escribe los datos transformados en un archivo en lugar de en la base de datos en uso, algo útil cuando la importación se hace en el servidor nuevo. Antes y después del cambio, wp site list lista todos los sitios para comparar las direcciones guardadas:

for url in $(wp site list --field=url); do
  echo "$url $(wp option get siteurl --url="$url")"
done

Las notas del manual sobre mover Multisite fijan el alcance. Mismo dominio en un servidor nuevo: se copian archivos y base de datos igual que en una instalación única. Dominio nuevo: se mueven los archivos, se actualiza DOMAIN_CURRENT_SITE en wp-config.php y el .htaccess si cambió la carpeta, y luego se revisan wp_site y wp_blogs (dominio y ruta) y, en cada tabla wp_N_options, los valores home, siteurl y fileupload_url. Pasar de subdominios a subdirectorios, o al revés, exige además cambiar SUBDOMAIN_INSTALL y las reglas de reescritura.

#Errores habituales de staging en WordPress multisite

Multisite suele fallar en staging, no en producción.

URL fijadas en la red. Una herramienta de clonado que solo cambia el dominio principal pero deja wp_blogs y wp_site apuntando a producción hace que los editores inicien sesión en el entorno equivocado o mezcla cookies.

Search-replace sin excluir el GUID o sin prueba en seco. Ejecuta siempre el --dry-run. Limita las tablas cuando solo muevas un sitio.

Cron y correo. El cron de la red (wp-cron.php) y el correo saliente de staging no deben llegar a clientes reales. Bloquea el SMTP saliente en staging o envíalo a un buzón de pruebas.

Subdominios de staging. staging.marca.es necesita su propio DNS y normalmente su propio certificado TLS. Un certificado comodín para *.marca.es no cubre staging.otramarca.es. Prueba HTTPS antes de invitar a los editores.

Activación de plugins a nivel de red. Un plugin de prueba en staging está bien. La misma acción en producción sin un sitio canario, no. Mantén al menos un sitio canario donde los plugins nuevos se activen primero.

WooCommerce en una red. Si la red es una cadena de tiendas, prueba las llamadas de retorno de la pasarela de pago por cada URL de sitio. Los webhooks que siguen apuntando a staging después del lanzamiento salen caros. Sin comercio electrónico, la migración se limita a contenido, medios y roles.

#Multisite, migración simple o instalación separada

#Qué debe incluir la lista de comprobación de una migración de WordPress

1. Copia de seguridad verificada con una prueba de restauración, no solo por el tamaño del archivo.
2. Misma versión de PHP y extensiones en staging y producción.
3. wp search-replace --dry-run sin sorpresas, con las mismas opciones que la ejecución real.
4. Acceso probado como superadministrador y como administrador de un sitio.
5. Las URL de medios cargan por HTTPS en todos los dominios mapeados.
6. wp site list --field=url coincide con la lista de direcciones esperada.
7. TTL del DNS reducido y plan de reversión escrito (quién cambia el registro A, dónde está el volcado SQL anterior).

La migración es mecánica. Multisite es un modelo de operación. Si se mezclan, se acaba arreglando el DNS cuando lo que había que hacer era separar a los clientes, o al revés.

#Preguntas frecuentes

Si preparas una migración compleja o una red Multisite, conoce nuestros servicios de desarrollo WordPress.