En muchas ocasiones nos podemos ver con la tarea de migrar una web y su correo corporativo. Si no lo hacemos bien, corremos el riesgo de caídas prolongadas de nuestra web y correo o en casos mucho peores la perdida del control sobre la misma aquí aprenderemos a cómo migrar una web paso a paso.
En esta guía vamos a explicar como migrar una web wordpress con base de datos, correo y gestión completa del dominio desde una empresa que actualmente lo concentra todo, hacía un nuevo proveedor de este mismo servicio. Esta guía está diseñada para una pyme u organización que quiere conservar el mismo nombre de dominio y minimizar la interrupción o riesgo.
El Control
La empresa nunca debe perder o dejar en manos de otra el control operativo sobre toda la infraestructura de internet (web, correo, etc). La organización debe contratar directamente los servicios críticos o, como mínimo, ser capaz de recuperarlos en casos extremos, sobre todo figurando como propietario o titular.
| Activo | Titular o cuenta principal recomendada | Acceso del nuevo proveedor | Evidencia que conviene conservar |
|---|---|---|---|
| Dominio | La organización cliente, con su razón social y datos de contacto | Usuario delegado o rol técnico; nunca único titular | Factura, panel del registrador, datos del registrante y fecha de renovación |
| DNS | Cuenta corporativa del cliente | Acceso técnico delegado y revocable | Exportación de la zona DNS y lista de servidores de nombres |
| Hosting y copias | Cuenta facturada al cliente | Usuario técnico con permisos acotados | Contrato, panel, inventario de copias y prueba de restauración |
| WordPress | Cuenta administrativa corporativa, no una única cuenta de agencia | Administrador técnico separado | Listado de usuarios, licencias, tema hijo y repositorios de código |
| Correo | Tenant o cuenta de administración del cliente | Rol de administrador delegado, si es necesario | Relación de buzones, dominios, licencias y métodos de recuperación |
| Facturación y recuperación | Dos personas autorizadas de la organización | Sin control exclusivo por terceros | Gestor de contraseñas, 2FA, correo y teléfono de recuperación corporativos |
Una buena manera de evitar dependencias es crear un buzón externo y estable en una de las plataformas más conocidas de correo, como pueden ser Gmail, Office365, etc. Para en esta poder recibir códigos de recuperación en caso de perdida. No es conveniente que la recuperación de una o varias cuentas dependa del dominio principal en exclusividad y menos si es este el que se va a migrar.
Los cuatro movimientos
A la hora de migrar un dominio se puede hacer de muchas manera y unas no implican los mismos cambios que otras, podemos desde solo hacer que el dominio apunte a otro sitio, hasta transferir de un registrador a otro con los peligros que esto conlleva, aquí puedes ver una tabla de las diferentes “migraciones” que se suelen hacer con los dominios.
| Movimiento | Qué cambia | Qué no cambia necesariamente | Momento recomendado |
|---|---|---|---|
| Cambio de DNS | La zona DNS o los servidores de nombres que responden por el dominio | El registrador del dominio | Antes del corte, tras copiar y validar todos los registros |
| Migración de hosting web | Archivos, base de datos, PHP, certificado y configuración de WordPress | Dominio, correo o registrador | Primero, en un entorno de pruebas |
| Migración de correo | Buzones, mensajes, calendarios, contactos y registros MX | El registrador; la web puede seguir intacta | Con destino preparado y una sincronización previa completada |
| Transferencia de registrador | La empresa acreditada que custodia el registro del dominio | Web, correo y DNS, si se conservan los nameservers | Al final o en una ventana independiente, una vez estabilizados los servicios |
En dominios genéricos como el .com o .net, la política de transferencia la marca el ICANN y reconoce el derecho del titular registrado a trasladar el nombre entre registradores acreditados. El titular prevalece sobre los demás contactos administrativos que están de alta en el dominio sobre cualquier disputa. Las reglas de los dominios territoriales como el .es, suelen ser identicas o muy similares pero con mayor burocracia y seguridad.
Inventario y plan de proyecto
Primero de todo debemos identificar todo lo que tenemos y si somos propietarios, más tarde efectuaremos un plan para realizar la migración. A continuación tenemos una tabla de las cosas que debemos verificar y realizar el inventario necesario.
| Área | Información que hay que recopilar |
|---|---|
| Dominio | Registrador real, fecha de caducidad, estado de bloqueo, código AuthInfo/EPP, datos del registrante, contactos, auto-renovación, DNSSEC y servidores de nombres actuales |
| DNS | Exportación o captura completa de registros A, AAAA, CNAME, MX, TXT, SRV, CAA, NS y subdominios; valor TTL, prioridad, destino y finalidad de cada registro |
| WordPress | Versión de WordPress, PHP y base de datos; tema, tema hijo, plugins, licencias, usuarios administradores, tamaño de archivos y base de datos, tareas cron, CDN, caché, SSL, API y formularios |
| Base de datos | Nombre, usuario, host, prefijo de tablas, método de exportación y copia .sql verificable |
| Correo | Proveedor actual, IMAP/POP/Exchange, buzones, alias, grupos, reenvíos, listas, buzones compartidos, calendarios, contactos, tamaño por buzón y credenciales de migración |
Una vez tengamos todo esto y veamos que tenemos la capacidad técnica y operativa de realizar la operación:
- Somos los propietarios.
- Estamos capacitados para realizar este tipo de migración.
- Controlamos las DNS que tenemos que poner en el nuevo registrador.
- etc.
Crear las cuentas bajo nuestro control
En el nuevo proveedor haremos el alta con el correo que hemos creado en una plataforma externa que solo controlaremos nosotros. Al ser un correo tan crítico y sobre el que no tendremos ningún control, podemos asegurarnos el acceso en caso de perdida de contraseña mediante algún teléfono de la empresa.
En el caso que este correo tengamos que darlo a otra empresa para que realice los trabajos, debemos asegurarnos que posteriormente le cambiaremos la contraseña y que siempre tendremos una opción para recuperar el control del mismo.
Prepara el destino
Antes de tocar nada en nuestra web en producción debemos prepara el destino donde la vamos a migrar, la forma más segura de migrar es construir el entorno nuevo y comprobarlo antes de dirigir tráfico real hacia él. Esto exige una breve planificación y comprobación del mismo.
Recuerda que los cambios de DNS son lentos pero seguros, si migramos nuestra web a una que ya está en perfecto funcionamiento el cambio de DNS será transparente para el usuario final, simplemente algunos verán una web en un servidor y otros la misma web en otro servidor, pero ninguno verá ninguna diferencia entre una y otra.
Pero el problema viene si en el cambio de DNS nos damos cuenta que la web de destino está mal o da error, entonces nos tocará revertir el cambio rápidamente y durante un tiempo nuestra web se verá mal o no se verá. En algunos casos antes de volver atrás los cambios de los DNS conviene corregir el error ya que nos llevará menos tiempo y la web se verá mal durante menos tiempo.
También podemos bajar el TTL de los DNS para que los servidores guarden un menor caché y los cambios sean más rápidos.
Migrar WordPress y base de datos
Antes de saber cómo migrar una web paso a paso debemos saber que la gran mayoría de las webs que están publicadas lo hacen bajo la plataforma de wordpress.
Una instalación de wordpress normal requiere de dos componentes, archivos y base de datos. La documentación oficial recuerda que descargar la carpeta del sitio no incluye la base de datos, que normalmente vive en un myql o mariadb por lo que deberemos descargar y restaurar en el servidor nuevo el conjunto de los mismos.
- Revisar compatibilidad: Comprobaremos que el nuevo servidor soporta las mismas versiones que tenemos en nuestra instalación actual, tanto en php como en mysql y que este también soporta el envío de correos del mismo modo que se esten haciendo ahora mismo.
- Copia inicial completa: Hay que generar una copia de los archivos y la base de datos completa, además identificaremos algunos ficheros que podamos tener que cambiar, como el wp-config.php y los registros de la base de datos en el caso que vayamos a realizar algún cambio extra.
- Restaurar: Crearemos primero la base de datos en el entorno destino, si es posible con el mismo usuario y contraseña que tenemos actualmente, para así no tener que modificar nada más, en caso que no podamos deberemos introducir los nuevs valores en el wp-config.php cuando subamos los ficheros. Si el dominio fuese a cambiar, necesitaríamos modificar los registros que hay en la base de datos que hagan referencia al dominio anterior por el nuevo.
- Probar destino: Al tener el dominio apuntando al servidor antiguo la mejor manera para probar que la web funciona es tocando nuestro fichero hosts, donde introduciremos un registro que apunte ese dominio a la ip del servidor de destino, así poniendo el dominio en el navegador nos llevará directamente al nuevo servidor y veremos si la web funciona.
Aquí una tabla de las cosas que deberemos probar:
| Prueba | Criterio de aceptación |
|---|---|
| Navegación | Inicio, páginas de servicio, entradas, categorías, búsqueda, imágenes y documentos cargan sin enlaces rotos |
| Administración | Inicio de sesión, edición, subida de medios, roles y actualizaciones funcionan |
| Formularios | Envío, entrega, antispam y destino CRM o buzón funcionan con el SMTP previsto |
| Comercio o reservas | Carrito, pago de prueba, notificaciones, stock, reserva o área privada se comportan correctamente |
| SEO técnico | URLs canónicas, redirecciones existentes, robots.txt, sitemap y etiquetas noindex del entorno de pruebas están controlados |
| Seguridad y rendimiento | HTTPS válido, redirección HTTP→HTTPS, copia programada, caché, WAF y monitorización activados |
Migrar correo
El correo necesita de un planteamiento propio, ya que dependiendo de donde lo vayamos a migrar podemos disponer o no de herramientas de migración. Además existen múltiples casuísticas de migración de correo.
1. Correo externalizado: Muchas empresas tienen el correo externalizado en algún proveedor tipo Gmail u office, esto aparte de ser lo más recomendable, es también lo más cómodo cuando hacemos una migración. Tan solo necesitaremos dejar los mismos dns que teníamos puesto en el registrador de dominio anterior y el correo seguirá funcionando sin percepción de que haya habido ningún cambio.
2. Migración con herramientas: A veces cuando vamos a migrar el nuevo servidor o destino, dispone de herramientas de migración, tan solo tenemos que ejecutarlas y importará todos los correos y configuración que tengamos creada.
3. Migración manual: En este punto siempre se recomienda una cosa, conectar los dos servidores tanto el saliente como el entrante o mejor dicho el servidor viejo y el nuevo a un programa de gestión, estilo mail, thunderbird, etc, cada una de las cuentas y seleccionar todos lo correos tanto de la bandeja de salida como de la entrada copiando y pegando al nuevo servidor.
Esto dependiendo del tamaño de correos que tengamos se tirará un tiempo copiando y pegando todos los correos del viejo al nuevo servidor.
Copiar DNS
Antes de cambiar los DNS al nuevo servidor o de transferir el dominio, debemos copiar cada registro que tenga en la zona dns al nuevo servidor. Una zona incompleta puede no cargarse nuestra web, pero si nuestro servidor de correo o muchas otras cosas.
Debemos prestar especial atención a los subdominios en caso de que nuestro servidor de correo sea un proveedor externo pero debemos dejar los que a partir de ahora apunten a la nueva web, también podríamos hacerlo en dos pasos, primero copiar exactamente la zona dns y luego desde el servidor nuevo ir cambiando.
Transferencia del dominio
Una vez tengamos todo eso, procedemos a la transferencia del dominio, el flujo habitual consiste en iniciar una solicitud desde el nuevo registrador que es el destino, autorizarla desde el registrador saliente. Para esto deberemos aportar el Authcode.
El registrador saliente debe notificar la solicitud y, si no responde a la notificación del registro en cinco días naturales, la política prevé una aprobación por defecto, salvo una causa válida de denegación.
Es preferible no cambiar los datos del registrante de forma improvisada justo antes de iniciar la transferencia. En Algunos escenarios, un cambio de registrante puede activar un bloqueo de 60 días.
Al completarse la transferencia, debemos volver a activar la protección o bloqueo de transferencia.
Una migración exitosa no consiste solo en mover una web. Consiste en separar la propiedad de los activos de la prestación técnica del servicio. El cliente debe ser titular, pagador y administrador de recuperación; la agencia o proveedor debe ser un colaborador con permisos definidos, no el único propietario de las llaves.
El orden más seguro es: recuperar control e inventariar, crear el destino a nombre del cliente, copiar y probar WordPress, migrar el correo de forma gradual, cambiar DNS en una ventana controlada, observar el resultado y transferir el registrador cuando todo esté estable. Con copias verificadas, una lista DNS completa y un periodo de convivencia, el cambio deja de ser un salto de fe y pasa a ser un proceso controlable.
A continuación un listado con los checklist que debemos hacer antes de una migración.
Listado checklist
Titularidad y acceso
El dominio figura a nombre de la organización o existe documentación contractual suficiente sobre su titularidad.
El cliente controla el correo, teléfono y doble factor de recuperación de registrador, DNS, hosting y correo.
Existen al menos dos administradores internos autorizados y los accesos del proveedor son delegados y revocables.
La facturación, auto-renovación y avisos de caducidad están bajo control del cliente.
Se ha activado el bloqueo de transferencia una vez finalizado el traslado.
Web y WordPress
Hay una copia completa de archivos y base de datos, almacenada fuera del hosting, y se ha probado al menos una restauración.
El sitio carga por HTTPS, las URLs canónicas son correctas y no quedan avisos de contenido mixto.
Funcionan administración, imágenes, buscador, formularios, SMTP, analítica, conversiones, comercio y/o reservas cuando aplican.
Los usuarios administrativos internos, licencias, actualizaciones, copias y monitorización están documentados.
La versión de pruebas no es indexable y ninguna regla temporal de mantenimiento quedó activa por error.
Correo y DNS
Cada buzón, alias, grupo, reenvío, calendario y contacto relevante está creado y comprobado.
La migración informa de elementos completados, omitidos y fallidos, y se ha revisado el histórico de buzones críticos.
Se pueden enviar y recibir mensajes desde cuentas externas; los formularios web también entregan correo.
Los registros MX, SPF, DKIM y DMARC corresponden al entorno nuevo y todos los remitentes legítimos están contemplados.
Se ha guardado una exportación final de DNS y se han revisado subdominios, IPv6, TXT de verificación y DNSSEC.