Migración de IBM Domino-Connections Cloud (SmartCloud) a MS O365 (Parte IV)

Una vez visto en  los anteriores post  la problemática de la migración de aplicaciones y entorno social,  podemos centrarnos en la migración del correo.

Vamos a centrarnos exclusivamente en la migración de correo desde la nube (desde SmartCloud), ya que desde on-premise, ya hay demasiada literatura escrita, y ya en este mismo blog hemos referenciado a como usar herramientas como Fastrack para dicha migración.  Básicamente, en este post el foco será el procedimiento de extracción de la nube, para después ya realizar una migración on-premise estándar con la herramienta que prefiramos.

A diferencia de los casos on-premise, la literatura de como bajar información de la nube, es más bien escasa, y ello es en parte debido a la dificultad del tema (y lo poco habitual del mismo).  Entre lo poco válido que se puede encontrar, es de destacar un artículo de John Vanderhof.    Realmente en este post no se relevará nada que no se haya mencionado previamente en dicho articulo, pero si creo que es  recomendable matizar los puntos ahi expuestos,  ya que aunque John acierta en el análisis de las opciones disponibles, en la práctica es bastante más complicado de aplicar de lo que parece.  Además, las únicas opciones en las que el citado articulo da detalles, están orientadas a clientes pequeños y con poco volumen de datos, implicando mucho trabajo manual.

Maticemos pues dichos puntos:

  1. IMAP:   Ya hemos hablado con anterioridad de esta alternativa y sus limitaciones.  Es una posibilidad, pero yo solo la recomendaría en entornos pequeños, para unas pocas cuentas.   Además, es un mecanismo que reservaría a usuarios avanzados que estuvieran capacitados para hacer su propia migración.  En teoría,y como mejora a la implementación manual por cada uno de los usuarios,  podríamos hacerlo de forma centralizada, y automatizarlo con herramientas como IMAPSYNC  o utilizando un script en PowerShell, pero este aspecto nos obligaría a  conocer la contraseña de todos los usuarios,  y por supuesto,  ir poco a poco para que no se nos apliquen los límites de servicio habituales en todo proveedor.
  2. Cliente Notes usando Replica Local: Es el mecanismo recomendado, ya que a diferencia del IMAP, permite que nos llevemos información del calendario y los contactos,  y una mayor integridad de datos.   A diferencia del articulo anterior, donde se utilizan replicas normales,  mi sugerencia sería utilizar las denominadas“managed replicas” o replicas gestionadas.  Este el mecanismo que  IBM ha definido específicamente diseñado para trabajar en Smartcloud, evitando problemas de “salud” y impactar en el servicio.  El mecanismo es mucho más eficaz que el de la replica normal,   además ser fácilmente configurables de forma centralizada, utilizando las políticas de servicios.  Con este método podemos configurarse de forma automática las managed replicas en los usuarios que utilicen cliente notes, de forma totalmente transparente, de forma que en la siguiente conexión, empezarán a bajarse, de forma ordenada, toda su información. Solo tendremos que preocuparnos de que el usuario tenga suficiente espacio en su disco duro, que tengan el cliente notes levantado para poder realizar la replica, y por supuesto tener suficiente ancho de banda para no eternizarnos en la descarga…
  3. Pool de Clientes Notes replicando a un Servidor Central:  Es una variante del sistema anterior.  En este caso, utilizaremos un pool de varios clientes notes en máquinas virtuales.  Hay que tener en cuenta que en este caso no podremos usar managed replicas (ya que por concepto, una ubicación/cliente notes solo puede gestionar una única managed replica), pero si una replica normal. Un mismo cliente replicaría de esta forma, de forma secuencial, el correo de varios usuarios (anteriormente se le debe haber dado al usuario genérico que correrá el agente de replica/extracción permisos en cada una de las bases de datos a procesar).   El cliente primero replicará esos buzones a su file system, y después, arrancará un nuevo proceso para replicarlos al servidor central, donde podremos archivarlos como  histórico,  o utilizar el servidor como fuente para la posterior migración a O365. A fin de evitar crear y gestionar las replicas manualmente, lo recomendable es ayudarnos de un pequeña aplicación de control, y realizar un pequeño agente que nos ayude en la realizacion/gestión de dichas replicas de forma automatizada.
  4. Servidor Hibrido:  En vez de utilizar varios clientes Notes,  podemos conectar un servidor (o varios) directamente a la nube, y lanzar de forma paralela los procesos de replicación usando varias tareas de replicación,  Este proceso es el más adecuado para migrar grandes volumenes de usuarios y de datos,  pero no es fácil de configurar, ya que además de una cross-certificación de servidores, hace falta un tunning adecuado para sacar el máximo provecho sin impactar a la “salud” de smartcloud ni al resto de usuarios (si no corremos el riesgo de que se nos suspenda la cuenta).  La gestión de las replicas, y la creación de las mismas, deberia hacerse, al igual que en el caso anterior, con un desarrollo que automatizase las tareas.  Lo recomendado es reservar esta opción para entornos grandes, y apoyarse en los servicios de IBM Consulting para realizarlos.

En definitiva, IBM no impone limitaciones para acceder a tus correos,  son tuyos, y la postura oficial es que con un cliente estándar puedes acceder y descargarlos, usando el mecanismo habitual de notes, la réplica.  En el caso de no usar clientes notes,  el mismo usuario puede usar IMAP, incluso para importar directamente sus antiguos correos en la nueva cuenta O365, pero perdería el resto de información (no existe actualmente soporte ical o idav).

Si el volumen de datos no es grande, en un plazo razonable de tiempo se puede abordar la migración.  El problema reside cuando estamos hablando de miles de buzones o de un gran volumen de información.  En ese caso, el tiempo de descarga usando mecanismos tradicionales puede prolongarse en demasia  (y recordemos que tenemos que tener el usuario activo y con su correspondiente subscripción en el servicio para bajarnos datos de el).

Mi recomendación,  es usar usar las 2 primeras opciones en clientes pequeños, de no pocas decenas de usuarios, utilizando la replica gestionada (siempre que sea posible usar un cliente Notes), y dejando el IMAP solo para unos pocos casos en los que no sea posible instalar el cliente.

La opción 3 es la recomendable para entornos medios, con un mayor volumen de datos, donde tengamos que ir a un mayor ritmo de migración, y no queramos depender del usuario. Por último, la opción 4, la más compleja,  está orientada a entornos más grandes, donde necesitemos conseguir los más altos ratios de migración, pudiendo incluso si queremos especializar servidores para la replicación inicial y otros para la realización de los incrementales.

Con todo esto, ya hemos pegado un paso de gigante, analizando las formas de migración y las consecuencias… ya solo nos queda un último articulo para las conclusiones..

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *