Migración de servidores y hosting sin cortes

Trasladamos sitios web, tiendas, bases de datos, servicios en segundo plano y correo a un nuevo servidor o proveedor de alojamiento. El servidor nuevo funciona en paralelo hasta que cada sitio supera sus comprobaciones, y el cambio en sí es una modificación de DNS que se puede revertir.

Cuando le toca a usted una migración

Nadie cambia de servidor por gusto. Normalmente la fecha la fija otro, y el servidor contiene más cosas de las que nadie recuerda.

Su proveedor retira el plan, y en el servidor hay correo, cinco sitios y una tarea cron que nadie documentó
La factura del hosting ha vuelto a subir, y mudarse parece más arriesgado que seguir pagando
El sistema operativo o el panel de control ya no recibe actualizaciones, y quien lo configuró ya no está
Quiere reunir varios servidores antiguos en uno o pasar a servidores ARM más baratos
El correo de sus dominios está en la misma máquina, y nadie sabe de qué registros DNS depende
Un intento anterior de migración acabó con imágenes rotas, pedidos perdidos o correos devueltos

Qué trasladamos

Primero, el inventario

Antes de copiar nada, listamos lo que realmente se ejecuta: sitios, bases de datos, tareas cron, procesos en segundo plano, buzones y reenvíos, cuentas FTP, certificados y registros DNS. La lista suele sacar a la luz algunas cosas que el propietario desconocía.

Stack web y bases de datos

nginx y Apache, varias versiones de PHP en paralelo, MySQL y PostgreSQL, y paneles de control como aaPanel y FastPanel. Los sitios se trasladan con su configuración, sus usuarios y sus permisos de archivos, no solo con sus archivos.

Node, Docker y servicios

Aplicaciones Node.js bajo PM2 o systemd, contenedores Docker y los procesos que se ejecutan en segundo plano. Las dependencias se reconstruyen en la máquina nueva, algo importante cuando cambia la arquitectura del procesador.

Correo

Buzones con sus contraseñas y su historial, alias y reenvíos, filtrado de spam y DKIM, SPF y DMARC. Cuando un proveedor bloquea el puerto 25 de salida, el correo saliente pasa por un relay para que nada se devuelva.

DNS y Cloudflare

Las zonas se reconstruyen a partir de los registros del panel del registrador o de Cloudflare, no se deducen de consultas. El TTL se reduce con antelación, y los servidores de nombres solo se cambian en el registrador cuando la nueva zona está completa.

Copias de seguridad y monitorización

El servidor nuevo recibe copias de seguridad en un almacenamiento separado con política de retención y una restauración de prueba, además de monitorización de disponibilidad, certificados y espacio en disco. Un servidor sin ellas está solo medio migrado.

Una migración planificada para que el cambio sea lo más aburrido

Cada sitio funciona primero en el servidor nuevo bajo una dirección temporal. Abrimos sus páginas, enviamos sus formularios, hacemos un pedido de prueba si hay proceso de compra, enviamos y recibimos correo y esperamos a que se ejecuten las tareas cron. Justo antes del cambio, los datos se sincronizan una vez más, para no perder los pedidos y comentarios hechos desde la primera copia. Después, el DNS se cambia zona por zona. El servidor antiguo queda intacto hasta que el nuevo lleva un tiempo funcionando, así que volver atrás es cambiar un registro.

Un inventario por escrito de todo lo que se ejecuta en el servidor antiguo
Cada sitio comprobado en el servidor nuevo antes de cualquier cambio de DNS
Una sincronización final de datos justo antes del cambio
El servidor antiguo se mantiene como respaldo hasta que usted lo confirme

Los problemas que ya conocemos

Hemos trasladado diez proyectos y veintitrés sitios entre servidores, incluida una migración completa de máquinas x86 a ARM64, y hemos anotado cada problema por el camino. En ARM, las dependencias de Node deben reinstalarse en lugar de copiarse, y PHP puede caerse con ciertas configuraciones de JIT. MySQL puede empezar a distinguir mayúsculas y minúsculas en los nombres de tablas y romper consultas que funcionaban desde hacía años. Un nginx más nuevo o más antiguo rechaza partes de la configuración anterior, y las bases de datos llegan con la intercalación (collation) equivocada. Una zona de Cloudflare puede quedarse atascada en la activación, el filtro de spam puede no firmar el correo hasta que se reinicia en el orden correcto, y una regla del cortafuegos puede bloquear una oficina entera que comparte una misma IP. Las herramientas de migración de los paneles pueden dar por buena una copia incompleta, y los certificados pueden dejar de renovarse sin avisar. Cada una de estas cosas se comprueba ahora en minutos, en lugar de descubrirse tras horas.

Una lista de comprobación basada en migraciones reales, no en la documentación
Cambios de arquitectura, como de x86 a ARM64, tratados de forma deliberada
Diferencias de versión en PHP, MySQL y nginx comprobadas antes del cambio
Correo, certificados y reglas del cortafuegos probados, no dados por supuestos

Después de la migración: soporte en lugar de una carpeta de traspaso

Una migración es el momento en que un equipo por fin conoce el servidor completo: qué se ejecuta, por qué y qué depende de qué. Es un desperdicio perder ese conocimiento al día siguiente del cambio. La mayoría de nuestros clientes de migración se quedan con el soporte mensual de servidores, en el que las mismas personas aplican las actualizaciones, vigilan las copias de seguridad y la monitorización, renuevan los certificados y se encargan del siguiente cambio. Si prefiere administrar el servidor usted mismo, recibe la documentación de la nueva configuración y acceso a todo.

Cómo transcurre una migración

Inventario

Obtenemos acceso de lectura al servidor antiguo, los dominios y el DNS. Usted recibe una lista de lo que se ejecuta allí y de lo que implica el traslado.

Plan y servidor nuevo

Acordamos el proveedor de destino y el tamaño del servidor, y después preparamos la máquina nueva con las mismas versiones de software o más recientes. Recibe un plan de cambio por sitio y por dominio.

Copia y pruebas

Los sitios, las bases de datos, los servicios y el correo se copian y se comprueban bajo direcciones temporales. Los problemas se corrigen mientras el servidor antiguo sigue atendiendo a todos.

Cambio

Tras una sincronización final de datos, el DNS se cambia zona por zona en el momento que usted elija. Vigilamos el tráfico, los registros y el correo mientras ocurre.

Observación y decisión

El servidor nuevo funciona bajo observación mientras el antiguo espera como respaldo. Después se apaga el servidor antiguo, y usted elige entre el soporte mensual y un traspaso documentado.

Desde dónde y hacia dónde migramos

Paneles y servidores web

Bases de datos y aplicaciones

Correo y DNS

Infraestructura

Formas de trabajar con nosotros

Proyecto de migración

Un alcance cerrado, acordado tras el inventario: qué sitios, servicios y dominios se trasladan y adónde.

Migración y soporte mensual

Trasladamos el servidor y después seguimos ocupándonos de él: actualizaciones, copias de seguridad, monitorización y los próximos cambios.

Ayuda por horas

Un inventario y un plan de migración para su propio equipo, o ayuda con una parte delicada concreta, como el correo o el DNS.

Opiniones

Tratamos a cada cliente y su proyecto con atención.

El equipo de Revol sigue reforzando la capacidad de desarrollo del cliente gracias a un trabajo de alta calidad y un soporte fiable. Se comunican con eficacia y demuestran una comprensión sólida de las necesidades y del negocio del cliente.

Tomas

CEO (Yukón, Canadá)

El trabajo de Revol ha cumplido plenamente las expectativas y ha dejado satisfecho al cliente. Su enfoque fresco y su disponibilidad para dar soporte han sido muy valiosos. Quien busque un equipo comunicativo y orientado al cliente para alcanzar sus objetivos puede contar con ellos.

Andrey

CEO, Stellium (EE. UU.)

Preguntas frecuentes

¿Se caerán nuestros sitios durante la migración?

No deberían. El servidor nuevo funciona en paralelo y solo recibe tráfico cuando cada sitio se ha comprobado en él. Mientras se propaga el DNS, algunos visitantes siguen llegando al servidor antiguo durante un breve periodo, por eso se mantiene encendido hasta que el cambio se ha extendido.

¿Qué pasa con los pedidos y los formularios enviados durante el cambio?

Sincronizamos los datos una vez más justo antes del cambio, así que solo queda un margen breve. Para tiendas con mucho movimiento acordamos cómo cerrarlo: cambiar en una hora tranquila, pausar el proceso de compra unos minutos o incorporar a mano los últimos pedidos de la base de datos antigua.

¿Pueden trasladar también nuestro correo?

Sí. Los buzones se trasladan con sus mensajes y contraseñas cuando el sistema antiguo lo permite, junto con los alias y reenvíos. Reconstruimos DKIM, SPF y DMARC para el servidor nuevo y comprobamos que el correo saliente se entrega, no solo que se envía.

Estamos en servidores x86. ¿Podemos pasar a ARM64?

Normalmente sí, y los servidores ARM suelen ser más baratos para la misma carga. La mayoría de cargas de PHP, WordPress, Node y bases de datos funcionan en ARM una vez reconstruidas sus dependencias. El inventario muestra pronto si algo solo existe para x86, como una imagen Docker antigua o un binario de código cerrado, y en ese caso mantenemos esa parte en x86.

¿Necesitan acceso a nuestro registrador de dominios?

Para planificar basta con acceso de lectura al DNS. Para el cambio necesitamos editar registros o cambiar los servidores de nombres, algo que puede hacer usted mismo siguiendo nuestras instrucciones o darnos acceso para ese día.

¿Y si algo falla después del cambio?

El servidor antiguo sigue ahí, así que la solución más rápida es volver a apuntar el DNS hacia él mientras buscamos la causa. Vigilamos los registros, las colas de correo y la monitorización durante los primeros días tras cada cambio, cuando suelen aparecer los problemas que no se vieron en las pruebas.

¿Podemos dejar atrás nuestro panel de control?

Sí. Podemos trasladar sitios de un panel a otro, o a un servidor sin panel, gestionado mediante archivos de configuración y scripts. Recomendamos lo que mejor encaje con las personas que se ocuparán del servidor después.

¿Se ocupan del servidor después de la migración?

Si usted quiere. La mayoría de los clientes de migración continúan con el soporte mensual de servidores, en el que el mismo equipo se encarga de las actualizaciones, las copias de seguridad, la monitorización y los siguientes cambios. Si no, recibe documentación y acceso completo, y el servidor queda en sus manos.