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..

Connections Cloud – Limites al Envio de Mensajes Masivos

Actualmente,  Connections Cloud , a diferencia de otros servicios,  no tiene ninguna limitación en cuanto a número de mensajes enviados,  replicación de datos, o  descarga de mensajes realizados por IMAP.

Esto no quiere decir que se pudiera hacer un uso abusivo de estos servicios,  aunque las APIs no tienen de por si un mecanismo que limite el número de llamadas que pueden hacerse a determinado servicio,  si hay mecanismos de monitorización para evitar los abusos, de forma que cuando se detecta un uso no adecuado de un servicio, o utilizar el mismo para algo que no ha sido diseñado, la cuenta/usuario que esta haciendo uso de dicho servicio puede ser suspendida (tal y como reflejan los acuerdos de servicio).     Un claro ejemplo es el uso del IMAP,  que como hemos visto anteriormente no es un mecanismo pensado para un extración masiva de datos, ya que un uso indiscriminado del mismo puede afectar en el servicio.  Obviamente, si IBM detecta que se esta haciendo dicho uso no adecuado,  podría detener el servicio para evitar que afecte a otros clientes.

A fin de estandarizar el servicio,  se están introduciendo poco a poco los denominados mecanismos de “rate limits” o “api throttling”, que restringen directamente en el API el número de llamadas que se puede hacer a la misma.   Hasta ahora, solo las APIs de Social (connections) tenian esos mecanismos de proteccion (limitando las llamadas a las API que se podia hacer al minuto),  pero no las de correo.

El primer servicio afectado será el envío masivo de correos,  de forma que un usuario no podrá enviar mas 5000 mensajes por día,  o no más de  500 mensajes en un tiempo de 15 minutos.   Son unas cifras que considero son muy razonables, y díficiles de alcanzar, ya que Connections Cloud no es una plataforma de mail para envios masivos o transaccionales  (existen excelentes herramientas para ello, tipo Sengrid, Awever o MailChimp,  o el más especifico para mail con un fuerte componente en marketing profesional, el WCA – Watson Campaign Automation).

Esta previsto que a lo largo del año se vayan introduciendo, siempre dentro de una lógica, y con el fin de garantizar la buena “salud”  del servicio de Connections Cloud, mecanismos adicionales, a modo similar a los que otros proveedores como Google o Microsoft tiene en su servicio .

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.

Sigue leyendo

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.

Sigue leyendo

Microsoft distribuye fix para evitar crash de Notes en Windows 10

En las últimas semanas me han llegado quejas de varios clientes,  en las cuales mencionaban que tras la última actualización automática realizada en Windows 10  (el denominado Windows 10 Creators Update  lanzado el pasado 11 de abril de 2017),  sufrían problemas de caídas y crashes de Notes  (que hasta entonces había funcionado con normalidad)

Hace apenas un par de días me llegan noticias de que Microsoft ha distribuido un fix que soluciona el tema del pantallazo azul.   Este problema estaba ocasionado por unas llamadas determinadas a las Windows UI API,  que no funcionaban correctamente,  porque lo que en determinadas operaciones, se originaba un crash.

El problema ha quedado resuelto con la última actualización de Microsoft.

Adjunto el link del update:
https://support.microsoft.com/en-in/help/4022716/windows-10-update-kb4022716

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

Como empleado de IBM,  una de las ocasiones más frustantes con las que  me suelo encontrar es cuando uno de mis clientes quiere migrar desde Domino o SmartCloud a uno de nuestros competidores directos,  Microsoft o Google.

¡¡¡ Cuidado con los Costes y Riesgos Ocultos !!!

Las razones suelen ser diversas.  Dentro de ellas, nos encontramos además con 2 casos distintos que es importante diferenciar. Por un lado, están los clientes que no están aún en la nube (y buscan modernizar su infraestructura hacia la mejor opción) y por otra, aquellos que ya conocen SmartCloud (pero en muchos casos, no todas las nuevas funcionalidades o posibilidades que se van incorporando, ni la diversidad de opciones de conexión y integración).

Como buen conocedor del producto, la mayoría de las veces compruebas que las decisiones no han tomado en cuanta muchas veces todos los elementos,  y no es raro que de fondo, haya “cantos de sirena” de Microsoft, o que se haya transmitido una falsa sensación de sencillez y modernidad en dicha alternativa.  Por lo general, un alto porcentaje de estas migraciones se suelen revertir,  ya que si tienes la oportunidad de explicar a tu cliente el roadmap del producto,  su posicionamiento, y compararlo técnicamente contra la competencia, el cliente lo ve ya con otra perspectiva.  Es habitual además que el cliente desconozca las tareas que tendrá que asumir durante la migración, y que implicaciones tiene. Por eso,  le presentas la problemática de la migración a otros entornos, los costes, riesgos y que el valor que puede aportar dicho cambio es muy discutible, el planteamiento suele cambiar totalmente.

La presentación adjunta resume en gran parte los puntos principales de esta problemática, y introduce de por si material suficiente para escribir un post dedicado a esta temática.   No vamos a tratar de defender, técnicamente, en este post, las ventajas técnicas de un entorno frente al otro (ya habrá tiempo en otros post mas adelante),  sino que nos vamos a situar en aquellas otras ocasiones, más complicadas de gestionar, en las que el componente evolutivo, funcional, técnico o incluso coste no es lo importante.

En definitiva, ¿ que pasa si la decisión ya esta tomada y no hay otra opción más que la migración?.  Estamos en un mundo cada vez mas cambiante, en el que se producen constante fusiones de empresas, adquisiciones, o cambios estratégicos, que pueden influir de forma decisiva en forzar una migración, por lo que es algo inevitable y hasta lógico, el que podamos encontrarnos en estas situaciones.   En esos casos, sin olvidar que se trata de la decisión del cliente, la postura responsable es lograr que quede satisfecho con nuestra colaboración y no cerrarse puertas cara a un futuro. No es razonable poner palos en la rueda, pero tampoco debemos disfrazar la realidad. Será por tanto una situación complicada, ya que es díficil contar en estos casos con la confianza del cliente.

A lo largo de este post, intentaremos ver como podemos abordar esa migración, y con que nos podremos encontrar en cada caso.

Sigue leyendo

Hola Mundo !!

Bienvenidos a mi blog, y a este primer post en el mismo.

Abordo este blog con ilusión,  y con la intención de poder ofrecer un nuevo punto de vista sobre las herramientas colaborativas de IBM.   Sin embargo, quiero hacer hincapié en algo que ya he intentado reflejar en el “About me”…  las opiniones de este blog son siempre desde el punto de vista personal,  y no tienen porque, coincidir, con la postura oficial de la empresa en la que trabajo.

Dejando esto claro,  espero que este blog aporte a la comunidad,  y para ello, todos vosotros sois necesarios, con vuestros comentarios,  apoyo, sugerencias de artículos, o dándolo a conocer entre vuestros compañeros.   El blog tendrá un fuerte foco en los productos colaborativos “típicos” de IBM, provenientes de Lotus,  como el Verse, Connections, Sametime, tanto en su versión on-premise como en la nube (SmartCloud).  Tendrá también su cabida otros productos más recientes, fruto de alianzas, colaboraciones o nuevos desarrollos  (Alianza con  Cisco,  Box,  Watson WorkSpace,  ) y como no, nuevas adquisiciones,  como la reciente compra de XCC  que, añade al portfolio de soluciones colaborativas una herramienta específica para el concepto del nuevo empleado digital,  donde los denominados “Digital Worplace”  marcarán el avance de las redes colaborativas y sociales de la próxima década.

No es de extrañar que el concepto de “Digital Experience”  y más específicamente, del Digital Workplace Hub,  haya inspirado  el nombre del blog.   Tecnologías como Watson, Orient-me,  Pink  nos acercan cada vez más al concepto de plataforma, y nos diferencian de la competencia al ofrecer  no sólo un simple producto, sino una completa solución colaborativa integrada, un lugar donde IBM siempre ha destacado (sumando ya varios años consecutivos como líder del mercado), y donde todavía nos queda mucho por ver.

Ojala, con vuestra ayuda, consiga que este blog se convierta en un lugar de referencia para dichos temas…y sobre todo, en un lugar de apoyo para que podamos seguir aportando nuestro granito de arena a un “#NewWaytoWork“.