Hay una frase que se oye en casi todas las conversaciones sobre cambiar de proveedor de correo electrónico: “sí, sabemos que deberíamos cambiar, pero es demasiado complicado”.
Detrás de esa frase hay un miedo concreto y perfectamente racional. El correo electrónico es el sistema nervioso de una organización. Si falla medio día, se paran las facturas, se paran las propuestas, se paran las respuestas a los clientes. Nadie quiere ser la persona que decidió tocarlo.
Este artículo no va a decir que la migración es sencilla. Va a decir exactamente qué puede salir mal, por qué sale mal y cómo evitar cada caso. Quien hace esto a diario sabe que la confianza no se gana quitando importancia a los riesgos, se gana nombrándolos.
Los siete problemas reales
1. Perder los mensajes antiguos. Es el miedo número uno, y es legítimo. Una migración mal ejecutada puede copiar el historial solo parcialmente y dejar fuera carpetas enteras, normalmente las más antiguas o las más grandes.
2. No recibir correo durante el cambio. Hay un momento, cuando se cambian los registros de enrutamiento del dominio, en que una parte del mundo ya conoce el nuevo servidor y otra parte sigue apuntando al antiguo. Mal gestionada, esa ventana produce mensajes perdidos o rebotados.
3. Descubrir demasiado tarde que faltaba un buzón. Cuentas de departamento, direcciones usadas por sistemas automáticos, buzones de un empleado que ya se ha ido pero que sigue recibiendo comunicaciones de clientes. Siempre aparecen, y rara vez están en la lista inicial.
4. Dejar fuera los reenvíos y las reglas. Muchas organizaciones tienen años de reglas acumuladas: facturas que van a contabilidad, formularios de la web que llegan a un buzón compartido, alertas enviadas a quien esté de turno. Si estas reglas no se inventarían de antemano, se descubren por su ausencia, y siempre en el peor momento.
5. Correos que empiezan a ir a spam tras el cambio. Cambiar de servidor significa cambiar el origen técnico de los mensajes. Si las autorizaciones de envío del dominio no se actualizan al mismo tiempo, el correo legítimo de la empresa empieza a ser tratado como sospechoso por los sistemas receptores.
6. Calendarios y contactos que se quedan atrás. Mucha gente entiende la migración como algo que afecta solo a los mensajes. Después descubre que las citas de los próximos seis meses y la lista de contactos del equipo no han llegado.
7. Los dispositivos de cada persona dejan de funcionar. El servidor ha cambiado, pero el teléfono de cada empleado sigue configurado para el antiguo. Sin un plan para esta parte, el resultado es una semana de llamadas a soporte.
Cómo hacerlo sin sorpresas desagradables
Una migración bien hecha se apoya en un principio que resuelve la mitad de los problemas anteriores: el origen nunca se borra.
Los datos se copian, no se mueven. Mientras la copia está en curso, el servicio antiguo sigue funcionando exactamente como siempre. Si algo falla, no hay nada que recuperar, porque nada se ha destruido. Es la primera pregunta que hay que hacer a cualquier proveedor, y la respuesta debería ser inmediata y sin rodeos.
A partir de ahí, el trabajo se organiza en tres fases.
Fase uno: inventario. Antes de copiar un solo correo, se lista todo. Todos los buzones, incluidos los que nadie recuerda. Todos los alias y reenvíos. Todas las reglas de filtrado relevantes. Todos los sistemas externos que envían en nombre del dominio, desde el programa de facturación hasta el formulario de la web. Es la fase más tediosa y la que determina el éxito de todo lo demás.
Fase dos: copia en paralelo. Los mensajes, las carpetas, los calendarios y los contactos se copian a la nueva infraestructura mientras el servicio antiguo sigue activo. El equipo no nota nada. Al final de esta fase hay dos copias completas, y la nueva puede validarse con calma.
Fase tres: cambio de enrutamiento. Solo cuando la validación ha terminado se cambia el enrutamiento del dominio al nuevo servidor. El cambio se propaga por internet durante unas horas, y en ese periodo ambas infraestructuras reciben correo. Por eso el servicio antiguo se mantiene activo unos días más: para recoger lo que todavía llegue allí.
Una nota sobre el momento de esta fase. Conviene hacerla fuera de las horas punta, y nunca en la víspera de un cierre contable, de un plazo judicial o de una campaña. No por riesgo técnico, sino porque cualquier sorpresa se gestiona mejor un martes por la mañana que un viernes por la tarde.
La parte del cliente
Hay tres cosas que ningún proveedor puede hacer solo, y conviene saberlo desde el principio.
Decidir qué se migra. No todo el historial tiene que pasar. Algunas organizaciones se lo llevan todo, otras se llevan los últimos tres años y archivan el resto. Es una decisión de negocio, no técnica.
Dar acceso al dominio. El cambio de enrutamiento se hace donde está registrado el dominio. Si nadie en la empresa sabe dónde es, o quién tiene las credenciales, ese es el primer problema que resolver. Ocurre más a menudo de lo que cabría pensar.
Avisar al equipo. Un mensaje interno, dos días antes, explicando qué va a pasar y qué tendrá que hacer cada persona en su teléfono, ahorra decenas de interrupciones.
Las preguntas que hacer antes de firmar
- ¿Se borran los datos de origen en algún momento del proceso? La respuesta correcta es no.
- ¿El servicio actual sigue funcionando durante la migración? ¿Y durante cuánto tiempo después?
- ¿Qué se incluye: solo los mensajes, o también calendarios, contactos, alias y reglas?
- ¿Quién actualiza las autorizaciones de envío del dominio, y cuándo?
- ¿Quién ayuda al equipo a reconfigurar sus dispositivos?
- ¿Cuál es el plan si algo sale mal a mitad de camino?
Un proveedor que responde con claridad a estas seis preguntas ya ha demostrado más que cualquier discurso comercial.
Y cuándo no merece la pena migrar
Con toda honestidad, conviene señalar lo contrario. Si la organización está en plena fusión, en un cambio de dominio o en una reestructuración profunda de sus equipos, tiene sentido esperar. Migrar dos veces es peor que migrar tarde.
En los demás casos, aplazarlo suele tener un coste silencioso: más años de un servicio que ya no encaja, más dependencia de una configuración que nadie entiende del todo, y un historial cada vez mayor que mover cuando por fin llegue la decisión.
La migración no es el momento de riesgo. El momento de riesgo es el día en que el sistema actual falla y no había ningún plan.