Barrapunto

1) Replicar toda la estructura de cuentas de correo antes del cambio para que cuando llegue el transfer empiecen a funcionar inmediatamente.2) Crear las cuentas de nuevo una vez vea que el dominio esta funcionando contra el nuevo Hosting.

Para mí en su día estuvo bastante claro que la primera era la buena. No soy profesional de estos temas, así que me explicaré a mi manera:

Tenemos un dominio DOMINIO.COM, con cuentas CUENTA@DOMINIO.COM, que está alojado en un servidor con IP 1.2.3.4, y queremos trasladar el dominio a otro servidor con IP 5.6.7.8. Sabemos que al trasladar el dominio, hasta que se propaguen correctamente los nuevos DNS, habrá correos que al ser enviados a CUENTA@DOMINIO.COM, se remitirán a la IP 1.2.3.4, y otros que se remitirán a 5.6.7.8.. En este momento, ¿qué es mejor, que la cuenta CUENTA@DOMINIO.COM sólo exista en 1.2.3.4, o que exista también en 5.6.7.8? Para mí es obvio: que exista en ambos a la vez. Así, habrá correos que lleguen al viejo servidor, y correos que lleguen al nuevo, pero en ningún momento habrá correos que se entreguen en un servidor en el que no exista la cuenta.

Eso sí, asegúrate de poder acceder a las cuentas del servidor 1.2.3.4 desde la IP para poder consultar el correo que te llegue durante el tiempo de transición, porque cuando los DNS se hayan propagado por completo, no será posible acceder a través de WEBMAIL.DOMINIO.COM (salvo que trampeemos el /etc/resolv.conf del equipo desde el que consultemos el correo).

En cuanto al momento para hacer el cambio de dominio, elige uno en el que el tráfico sea mínimo, y vaya a serlo durante al menos los dos días siguientes. Por ejemplo, Viernes Santo. Así, si hay algún problema, los e-mails perdidos serán muy pocos.

No se si te servirá de mucho, pero a principios de año (~3 meses) di de alta un nuevo dominio; y las DNS tardaron menos de 24 en funcionar en mi ubicación. Puede que no difundieran globalmente, pero al menos a mi en poco menos de 24 horas ya me funcionaba.

Si optas por hacer la migración un viernes por la noche, o incluso el sábado a mediodía; seguramente para el lunes todo este como debe.

Te cuento como le he hecho yo en los servidores de la universidad donde trabajo. 1.-Replicar las cuentas en el nuevo server 2.-Sincronizar los mails (con rsync por ejemplo) 3.-Cambiar los registros MX en el DNS 4.-Apagar el servidor de mails viejo (en gral si los servidores que te envian estan bien configurados, al no poder enviar reintentan durante 2 o 3 dias). 5.- Cuando se terminen de propagar los registros del DNS ya te deberian llegar todos los mails al server nuevo. De esta forma lo peor que puede pasar es que te lleguen un poco tarde algunos mails. Otra forma seria dejar los dos andando y cuando se haya propagado la info de los DNS apagar ambos servidores, sincronizar las cuentas y luego levantar el nuevo. Espero te sirva mi experiencia, Saludos.

1.- Creas el nuevo servidor y configuras el correo..
2.- Configuras el antiguo para que reenvié el correo al nuevo.
3.- Cambias los mx en el antiguo registrador.
4.- Contratas el nuevo dominio, y dejas los antiguos dns.
5.- configuras los registros en el nuevo dns.
6.- cambias los dns a los nuevos.

Este procedimiento te asegura un 0 downtime, y si tienes un entorno de preproducción, podras probar los archivos de configuración sin miedo.

Si hay que hacer, migración de los Correos antiguos, te recomiendo que automatices el proceso. Si puedes dejar a los usuarios sin Correos el tiempo que dura la migración, te quitarás mucha presión.

Dependiendo de la importancia, y de las necesidades podrás omitir o hacer varios pasos a la vez.

Veamos, si la memoria no me falla es posible indicar al servidor de correo que no acepte correo con un aviso de fallo temporal; de hecho, es uno de los métodos disponibles para hacer grey-listing: cuando un nuevo ordenador se conecta para intentar enviar un correo, le indicas que espere unos minutos porque el servidor está ocupado. La mayoría de los spammers directamente ignorarán ese servidor y buscarán una presa más accesible.

Así que opino que deberías replicar la estructura completa en el nuevo servidor, configurar el antiguo para indicar continuamente error temporal, y proceder al cambio de DNS. En un día (normalmente) se habrá actualizado todo y todos estarán enviando su correo al nuevo servidor.

Si haces esto en un momento de poco tráfico, quizá la noche del sábado al domingo para tener éste disponible para propagar tus DNS nuevas no deberías tener ningún problema.

Si tu tráfico de correo es tan crítico como para no poder hacer esto, entonces quizá te conviene "sustituir" el servidor de correo antiguo por una redirección al nuevo: cuando se abre una conexión al viejo, éste la tunela al nuevo. Supone algo más de carga de conexión, pero garantiza que todos los correos van llegando ya al nuevo hasta que se propaguen las DNS y puedas deshacerte del antiguo definitivamente.

Bueno, yo no soy experto pero para esos menesteres siempre he utilizado Google Apps, en caso de que hubiera algún problema (por ejemplo que me exijan cuenta premiere o algo por el estilo, ya que tengo demasiados e-mails) mi plan de contingencia es Windows Live, simplemente es cuestión de tener las mismas cuentas de e-mail ya creadas en Windows Live, y en caso de contingencia simplemente cambio los MX Records. Esa es la manera en que me he manejado hasta ahora..........

La más sencillo es replicar todas las cuentas de correo antes de hacer el cambio de DNS. Luego cambias los DNS, a poder ser a una hora que no vaya a haber tráfico importante de correo como las 00:00. Si algún correo importante quedase alojado en las cuentas antiguas, puedes editar tu archivo host y entrar por webmail, desde allí puedes 'reenviar' los correos importantes. Luego a cambiar los gestores de correo que useis con los datos nuevos, como es una tarea fácil puedes hacer un pequeño manual y repartirlo entre los empleados más aventajados para que lo hagan ellos mismos y cambiarselo tu a la gente torpe para evitar males mayores.