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

En el anterior post, ya comentábamos que el principal problema que vamos a tener al migrar una infraestructura Domino o SmartCloud a Office365,  es que hacer con las aplicaciones o con el contenido social.

Mi experiencia es que los clientes, al focalizarse en el correo, infravaloran ese contenido, y al final es causa de muchos problemas.   He conocido algún cliente que ha migrado de Domino a Office365,  y al final, ha acabado mantenido un conjunto de aplicaciones Domino,  que no acaba de conseguir migrar al nuevo entorno, y que incluso años después, siguen utilizando (con licencias en vigor).   Incluso me he encontrado un caso muy curioso, donde existe un “mercado negro” de aplicaciones Domino,  ya que aunque se supone que la plataforma no es operativa,  siguen pidiendo el desarrollo de nuevas aplicaciones para dicho entorno.

El tema no es trivial, no es fácil encontrar la rapidez de desarrollo, y versatilidad, que se tiene en Domino.  A nada que la aplicación sea un poco compleja,  el coste y el esfuerzo es considerable, y requiere reconstruir la aplicación desde el principio.  La mayoría de los veces, son proyectos que se abandonan a medio camino.  El problema se agudiza cuando en sucesivos años,  las licencias de MS, que inicialmente han podido ofrecerse a un coste muy reducido (o diluyendo el coste de las licencias de correo entre el resto de licencias del puesto), no necesitan seguir la misma política de precios. Al final, te puedes llegar a encontrar pagando y gestionando 2 entornos, lo que no deja de ser una paradoja,  cuando muchas de las decisiones se toman argumentando un ahorro de coste.

Si no tiene aplicaciones Domino,  la migración será mucho más fácil,  pero no cante victoria todavía.  También tendrá que tener en cuenta  si tiene Connections on-premise, o si usa el entorno social de SmartCloud.   Aquí vuelve a ser corriente el que se infravalore el uso de dicho entorno, y la gente olvide toda la complejidad y relación entre sí del entorno.  No solo están las comunidades y las wikis, donde puede haber mucho conocimiento de la empresa,  sino también los ficheros que el usuario haya podido subir a su unidad en Connections / Social.

Centremonos, a modo de ejemplo, en este último caso, el más “fácil” de todos.  En teoría no parece complicado, ya que podremos bajar los archivos que tengamos en nuestra unidad en cloud, a través de los conectores locales que nos permiten sincronizar los ficheros de SmartCloud con el PC del usuario.   Aquí empezaremos a percibir ya varios problemas, como la  necesidad de involucrar al usuario,  y por supuesto, que debemos tener siempre en cuenta la cantidad  del volumen de datos a migrar (por motivos tanto de tiempo como de espacio),   problemas que como veremos en el siguiente post, nos acompañaran también con la migración del correo.

En el caso mencionado de “ficheros”, cada usuario deberá, primero, asegurarse de que todo su contenido está marcado para ser sincronizado localmente…. y que su unidad de disco duro tenga espacio suficiente para almacenarlo…..   Si el usuario esta acostumbrado a sincronizar todo su contenido, esto no será un problema, pero hay que tener en cuenta que puede haber gente que, para no consumir espacio en su PC, solo sincronice  un contenido limitado (y ahí pueden llegar sorpresas).

Una vez tengamos todo el contenido sincronizado en local, quitamos el conector de Smartcloud, y ponemos en su lugar (apuntando al mismo directorio local de sincronización) el de OneDrive.   No conseguiremos respetar las comparticiones entre usuarios,  y por supuesto, perderemos el historial de comentarios y revisiones,  además de el histórico de fechas, pero al menos, si mantendremos una copia de los datos.  También hay que tener en cuenta que los ficheros subidos directamente a comunidades, tienen otro dueño (la comunidad), y por tanto, tampoco se podrán bajar con este método  (en este caso, deberán migrarse cuando se se migre la comunidad, de forma manual, o con un desarrollo que use las APIs).

El método no es ideal,  y implica “perseguir” al usuario,  pero no existen herramientas que nos permitan bajar todos los ficheros de todos los usuarios, de una forma centralizada, así que a no ser que queramos construirnos una a medida con las APIs, es la única viable.

Nota:  Existe la posibilidad de que los usuarios estén usando “Box” integrado con Connections en vez del producto estándar, files (Archivos).  En dicho caso, al estar Box totalmente integrable con Microsoft,  no tendría porque migrarse este contenido, ya que existiría la opción de seguir usando Box con la nube de Microsoft.

En el resto del contenido social, es más complicado.  Deberemos crear manualmente el contenido en otras aplicaciones o usar las APIs para llevarlas a otra aplicación.  Aquí es importante que partamos con unas bajas expectativas para no experimentar una frustación. Debemos asumir que gran parte de ese contenido se perderá, y incluso, que en en las herramientas de O365,  no podremos crear nuevos contenidos de forma similar, ya que el concepto de Sharepoint es distinto al de las comunidades (requiriendo además unos skills más técnicos y más complejos de abordar para usuarios normales).

Una vez tengamos todos estos puntos claros, y hayamos valorado como va a impactar en nuestra migración,  podemos seguir ya con el siguiente post,  específico a la migración del correo….

 

 

Deja un comentario

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