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

Con la migración, la mayoría de las empresas lo que quieren es mantener una copia de su información, a efectos históricos y legales.  Mantener acceso a esa información se convierte en un lastre, que dificulta el cambio de sistema, y que se sufre con todos los proveedores de correo.    Si la información esta en local, y no en la nube, la complejidad es menor.  Incluso en muchos casos, no es requerido ni migrarla, basta con mantener un acceso a la información antigua o un backup de la misma.   En cualquier caso, si la información está ya en local, no hace falta extendernos en muchas explicaciones más de como realizar la migración,  ya que podemos utilizar el sistema de FastTrack  expuesto en el primer post.  El asunto, sin embargo, se complica considerablemente cuando la información esta en la nube, por lo que este punto debe analizarse con otra perspectiva mucho mas cuidadosa, y teniendo en cuenta el que hacer para no encontrarnos en una situación parecida dentro de unos años.

Si ya tiene claro que aún y todo va a migrar, puede saltarse este post y ir al siguiente.  Si se le ha despertado alguna duda o inquietud, espere aún unos minutos, este post le puede ayudar a valorar el concepto de coexistencia, y plantear una alternativa win-win, en el que use lo mejor de cada sistema, de forma que pueda aprovechar todas las inversiones.    En ese post, antes de entrar en materia sobre las herramientas de migración,   analizaremos que es ir a la nube, que es lo que implica, y sobre todo, que debemos hacer para asegurarnos de que no vamos a estar en la misma situación cuando nos cambiemos a otra nube distinta, y así no cerrarnos puertas a una posible vuelta el día de mañana.

A estas alturas, ya debería tener claro que la problemática aquí resumida no es solo cuando se trata de la nube de IBM,  es un problema común.  De hecho, todos los grandes proveedores intentan atraer a sus clientes a su nube, ya que saben, que una vez en ella, es muy díficil que los clientes cambien de tecnología.

En el caso de Microsoft se da el hecho de que su infraestructura on-premise, como hemos visto anteriormente, está muy limitada, por lo que de forma muy agresiva intenta atraerla su infraestructura on-cloud, consciente además de que si lo consigue, tendrá un potente caballo de troya que le permitirá además ir desplegando sus “dependencias” progresivamente.  Estas dependencias  van poco, desplazando poco a poco el resto de tecnologías  ( portal,  sso,  gestión de identidades, etc…) y forzando el cambio de posibles tecnologias abiertas por propietarias, desplegando el resto de la arquitectura, y unificando servicios en cuanto a una pieza clave de la comunicación: el correo. Para ello, Microsoft no duda en ofrecer su paquete de correo integrado con el resto de soluciones ofimáticas.  No está tan claro que el correo tenga mayor funcionalidad que el de IBM, pero al venir conjunto a la ofimática, se percibe como algo “gratis” o de muy bajo coste, (aunque luego veamos no lo es)

El propósito de IBM obviamente no es muy distinto, pero la estrategia para introducir el correo, en vez de apoyarse en el software ofimatico, es su software colaborativo. Un punto significativo es que al poder ofrecer su plataforma colaborativa on-premise,  y al tener una filosofía con menos dependencias de software, no ha mostrado tanto interés en movilizar a sus clientes hacia la nube, descuidando esa área durante un tiempo y centrándose únicamente en infraestructuras locales.  Esto ha propiciado que su desembarco en la nube ha sido más lento y problemático,  sin tanta fuerza ni rapidez como la de Microsoft.  Hoy por hoy, sin embargo, las cosas han cambiado.  El avance es rápido. Se han modernizado y añadido nuevos CPD, consiguiendo un sistema mucho más estable y robusto. Además, con las nuevas tecnologías y funcionalidades que a lo largo de este año están siendo desplegadas, podemos considerar que está logrando la madurez necesaria para competir con seriedad en este campo, donde además de las ventajas propias de la nube, IBM muestra una de las mejores opciones para el desarrollo y integración a través de  las capacidades cognitivas que posee con Watson.

Podemos por tanto deducir que Microsoft es fuerte en el escritorio de trabajo (incluido el cliente de mensajeria, Outlook),  y más débil en la parte colaborativa.  IBM por otra parte tiene una estrategia mucho mas basada en la colaboración (incluyendo en las mismas una estrategia mas evolutiva del correo) y en la parte cognitiva, pero es más débil en la parte cliente.  ¿Y si pudieramos usar lo mejor de cada uno?

Por otra parte, esta estrategia hacia la nube de todos los proveedores, traslada un problema a los clientes.  ¿Qué pasa si luego quieren cambiarse “de nube”?   Los mecanismos de entrada en cada nube son fáciles, pero ¿Qué pasa con los de salida? ¿quien nos asegura que los usuarios aceptarán el cambio y que no caeremos en el mismo error?

En todos los casos nos encontraremos con una problemática similar, que desgraciadamente, muchas veces no percibiremos hasta que no nos propongamos migrar, independientemente del proveedor que sea, por lo que es muy importante desde un principio ir a la infraestructura más abierta y que menos ataduras nos imponga cara a un futuro.

Esta problemática es importante, y hay que ser consciente de ella, pero no puede ser tampoco un freno para que vayamos a la nube, ya que también hay que valorar las ventajas que esta nos ofrece.   Lo que yo recomiendo para mitigar y limitar estas ataduras es una estrategia de coexistencia,  que nos permitiera, además, cambiar de un proveedor a otro de una forma más fácil, según los productos vayan evolucionando.   Como puntos claves de esta coexistencia, podemos usar los siguientes puntos:

  • Complementar nuestra solución en la nube con una solución externa de “Mail Compliance”:  Diferentes fabricantes venden soluciones de archivado, independientes de IBM, Microsoft o Google.  Estas soluciones se utilizan fundamentalmente por temas legales, ya que complementan los sistemas de “mail retention” del proveedor, y permiten realizar funcionalidades de “eDiscovery” corporativas.  Un ejemplo de estos proveedores seria Sonian, cuya solución, vale tanto para IBM (Connections Compliance for Mail) como para Microsoft (archiving for o365).   Con este producto,  además de poseer una solución mucho mas especializada y robusta para temas de compliance, podriamos cambiar de proveedor en cualquier momento, y mantener un archivado de los correos (usando el mismo repositorio en el nuevo proveedor), por lo que la necesidad de migrar los datos, pierde necesidad.

 

  • Utilizar una plataforma multi-cliente:   Es importante que tengamos libertad de opción. Un fabricante no puede imponernos a usar un único cliente, sino que tiene que darnos la posibilidad de usar todo tipo de conectores y plugins, de forma que tengamos libertad de opción.  IBM ha entendido bien ese punto, y además de sus propios clientes (Verse, Notes…)  posee conectores nativos para Outlook  (IMSMO) que permiten al usuario utilizar las herramientas de Microsoft como frontend de forma nativa, totalmente transparente, de forma que el usuario incluso tiene la percepción de que está trabajando en un entorno O365.

El IMSMO nos abre un interesante punto, ya que no solo posibilita la coexistencia, sino que podría ser usado para en un futuro acceder al correo de una a otra plataforma.  Dado que  IBM permite la posibilidad de usar un conector específico para Outlook,  que nos permite bajar la información a un cliente Microsoft sin las limitación del IMAP  (permitiendo incluso contactos, agendas, correo encriptado, etc)…..   podemos incluso utilizar este mecanismo para, si fracasa el periodo de coexistencia, hacer una migración definitiva, y con la tranquilidad de haberle dado una oportunidad previa al software colaborativo (también accesible con los conectores de Outlook), que hoy por sigue siendo considerado el mejor software colaborativo.

El sistema INSMO no puede usarse como herramienta de migración desde el inicio, ya que el problema está, una vez más, en las limitaciones que como medida de seguridad impone el servicio.   No podemos olvidar que estamos en un sistema multi-tenant, y que por tanto, los servidores han sido dimensionados para ser compartidos con varios clientes y para un uso normal del correo,  no para un extracción masiva que pueda impactar el servicio o a otros clientes. Es algo similar a las limitaciones que vimos con el IMAP en el primer post, limitaciones que ya comentamos son habituales en los proveedores para garantizar la “salud” de la nube.  Una cosa es bajarnos unas pocas decenas de buzones, pero si todos los usuarios de una empresa se pusieran de golpe a bajar miles de buzones de varios gigas, el caos estaría asegurado, por lo que hay mecanismos que imponen limitaciones en la descarga.    En el caso del conector del Outlook estas limitaciones son el número de días que te puedes descargar, no más de 30 días cuando estas conectado con la nube.  A modo de ejemplo, si instalamos el conector en Febrero para un usuario, ese usuario podrá descargarse el correo del mes anterior (Enero) y a partir de entonces, de todos los sucesivos meses.   Si cambia el equipo, y en Junio se instala el conector en ese nuevo equipo, el sistema “recordará” la fecha de la primera descarga y le permitirá volver a descargarse desde el pasado Enero.  Sin embargo, todo lo que sea anterior, deberá consultarlo en modo online,  por lo que la cuenta smartcloud deberá seguir estando activa.

En definitiva, IMSMO es una potente herramienta para que un usuario que desea una “apariencia” Microsoft, y sigue utilizando MS-Office totalmente integrado con SmartCloud,  pero a no ser que el usuario haya estado usando el IMSMO desde el principio, no puede utilizarse para migrar todo el contenido.  Sin embargo, tras 60 días de uso, ya podremos migrar 90 días, que es lo mismo que permitiría  el FastTrack de Microsoft (y sin limitaciones como la de los correos encriptados, etc) de tener los datos en local,  por lo que sin duda, es una opción interesante a considerar.  Obviamente podemos usarlo también en el otro sentido (migrar de Exchange/O365 a entornos IBM).

Si la solución de la coexistencia de correo y colaboración no le convence, no olvide que dispone también de la opción de coexistencia únicamente en la parte de colaboración, ya que IBM ofrece conectores para toda la suite ofimática de Microsoft.

En cualquier caso,  es muy recomendable, desde el inicio, instalar una herramienta de terceros de “Mail Compliance” como la mencionada en este post,  ya que le posibilitará el ahorrarse problemas si el día de mañana decide de nuevo cambiar de proveedor,  manteniendo el mismo históríco de datos.

Y ahora ya si, con todos los deberes hechos, y entendiendo la problemática, podemos pasar a ver  en el siguiente post los pasos a efectuar para la migración.

Deja un comentario

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