Metodología tradicional de migración a O365

En el proceso de migración tradicional, el proyecto de migración a Office 365 se plantea como un proyecto tradicional, con varias fases secuenciales:

• Predespliegue
• Planificación
• Preparación
• Migración
• Postmigración

Para no extendernos demasiado, resumiremos diciendo que en las tres primeras fases se verifica la compatibilidad e idoneidad del producto, se planifica el proceso de migración incluyendo la comunicación a usuarios y, por último, se ponen en marcha los medios técnicos que permitan la coexistencia de ambos sistemas de correo. Esto incluye la sincronización de directorios, estructura de Sharepoint, Single Sign On, etc. También se hacen pruebas piloto para validar el proceso y el impacto en el usuario.

Según esta metodología, no es hasta la cuarta fase cuando se empieza a migrar regularmente los buzones de usuario y los datos, normalmente entre 4 y 8 semanas después de comenzar el proyecto.

En esta metodología, todos los componentes de O365 se preparan y configuran antes de la migración de los usuarios, de manera que cuando éstos llegan a O365 ya está toda la funcionalidad desplegada.

Según Microsoft, aunque esta es una metodología muy segura que produce proyectos con poco riesgo, su lentitud hace que en ocasiones el cliente no llegue a usar todas las características ni ponga en marcha el servicio. Al parecer, hay un gran porcentaje de ventas de O365 que luego no son implementadas. Siempre según Microsoft, la madurez actual de la plataforma hace que no sea un riesgo acelerar los procesos.

Por último, como desventaja adicional menciona que es habitual que los pilotos que se hacen en la metodología tradicional no pasen a producción y sean descartados, siendo por tanto un esfuerzo no recuperable.

METODOLOGÍA FASTTRACK

Metodología FastTrack para migraciones O365

A diferencia de la anterior, la metodología FastTrack simplifica y acelera todo el proceso, dividiéndolo tan solo en tres fases:

• Piloto
• Despliegue
• Mejora

La idea es comenzar con un piloto funcional, sin todas las características, e ir añadiendo las funcionalidades en fases posteriores.

Bajo este modelo, el servicio se usa desde el primer momento, aunque no estén todas las características.

Veámos ahora en detalle cada una de las fases.

FASE DE PILOTO

El objetivo de la fase piloto de FastTrack es tener a un grupo de usuarios trabajando con Office 365 lo antes posible, en horas.

Para conseguir esto, se dejan de lado muchas configuraciones y no se hace traslado de datos alguno.

Básicamente se trata de:

• Crear el «tenant» de O365 que será luego el definitivo
• Seleccionar los usuarios a formar parte del piloto
• Crearles manualmente cuentas en ese «tenant» de O365, pero sin dar de alta los dominios corporativos. Los usuarios utilizarán direcciones de correo del tipo @tenant.onmicrosoft.com
• Darle instrucciones a los usuarios para que utilicen la funcionalidad de «Cuentas Conectadas» para que en su buzón de Office 365 se pueda usar su cuenta de correo corporativa.
• Dirigirles a páginas de Microsoft donde pueden encontrar documentación y vídeos de ayuda para empezar a usar las funcionalidades de O365.

Tras esto, habrá un grupo de usuarios que estarán usando el servicio y que por tanto podrán dar feedback sobre la idoneidad del mismo o cambios a hacer en el despliegue general.

 FASE DE DESPLIEGUE

En esta fase, el objetivo es poner en marcha los componentes que se dejaron atrás en la fase de Piloto.

Esencialmente, las tareas a realizar son:

• Dar de alta los dominios de correo de la empresa en el «tenant» de O365
• Configurar la sincronización de directorios y de contraseñas
• Migrar el contenido de los buzones y los usuarios restantes, con cualquiera de las metodologías existentes
• Crear una estructura de sitios Sharepoint y configurar Lync Online

Es muy posible que para muchos clientes la migración acabe en este punto, pues ya estarán en producción todos los componentes habituales de O365.

FASE DE MEJORA

Esta última fase es opcional, y es dónde se habilitan servicios avanzados que el cliente puede demandar.

En esta fase se implementaría:

• Single Sign On para las cuentas de O365, normalmente federando el Directorio Activo o con algún sistema de terceros soportado
• Entornos híbridos de Exchange, Lync y/o Sharepoint, en los que se conectan los sistemas locales con los de la nube para una coexistencia completa.
• Sistemas de IRM (Protección de derechos), directivas de retención, etc.

La mayoría de los clientes no llegarán a esta fase, por no necesitar ninguna de estas funcionalidades. Dependiendo de la complejidad de lo solicitado, el proceso puede durar semanas y requerir personal muy especializado.

TRADICIONAL VS FASTTRACK

Llegados a este punto, ¿qué metodología es mejor?

Partiendo de la base de que la mejor metodología es la que mejor se adapta a cada cliente y cada proyecto, en nuestra opinión la metodología FastTrack presenta unos problemas que pueden superar a las ventajas:

1. Dependencia excesiva del usuario: En la fase de piloto, dependemos de que el usuario se configure su cuenta, inicie sesión en O365 en lugar de en su sistema habitual, reconfigure sus dispositivos, recuerde una contraseña distinta, lea una documentación, vea unos vídeos para formarse… En nuestra experiencia de decenas de proyectos de migración, todo lo que dependa del usuario final introduce unas probabilidades importantes de fracaso en el proyecto. No se trata de saboteen el proyecto sino más bien que el usuario normal tiene muchas cosas que hacer en su trabajo y no suele tener tiempo para leer nada. Es cierto que es muy importante escoger bien a los que van a participar en el piloto (para hacernos una idea, uno de los requisitos que menciona el curso oficial MOC sobre este tema es que el usuario tenga «espíritu aventurero»…), pero el riesgo persiste.
2. Conclusiones Equivocadas: Relacionado con el punto anterior, si uno de los objetivos de la fase piloto es ver si O365 cumple los requisitos de la empresa, un mal piloto puede hacer que la empresa se replantee la adopción generalizada. Los usuarios del piloto podrían decir, por ejemplo, que es compleja la gestión de las identidades, o la configuración de los buzones nuevos, o que el Sharepoint no sirve prácticamente para nada, ya que aún no tiene contenido. Cuando uno de esos usuarios, que hemos escogido por ser líderes de opinión, llega a una conclusión sobre las bondades o defectos de una plataforma es muy difícil que luego la cambie. Y esas presuntas «deficiencias» serán comentadas por todos los usuarios, añadiéndose a la habitual resistencia a los cambios.
3. Idioma: Aunque tuviéramos la suerte de contar con unos usuarios entusiastas dispuestos a leer todo, nos encontramos con el obstáculo de que, a día de hoy, la documentación está en inglés solamente, que sepamos
4. Alcance limitado: En realidad no hemos probado mucho en el piloto, prácticamente el OWA puesto que el resto no se ha implementado. Por tanto, queda por probar, testear y validar todo el resto de configuraciones complejas, desde DirSync hasta Single Sign On, Integración con sistemas híbridos, etc. Y el problema es que, como no hemos probado eso cuando sólo teníamos unos usuarios de prueba, ahora toca hacer las configuraciones contra un entorno de producción
5. Orden, contraorden=desorden: Siguiendo esa vieja máxima militar, nos podemos encontrar con problemas relacionados con la forma en la que hemos hecho el piloto. Tenemos a un grupo de gente a los que hemos dado unas instrucciones (URLs, cuenta con la que iniciar sesión, contraseña, forma de conectar con su correo), que son generalmente distintas de las que tendrán que seguir los demás usuarios. Puede ocurrir que los usuarios recurran a los usuarios del piloto para resolver sus dudas, y que esto al final sea contraproducente por ofrecer una información incorrecta. En nuestra opinión, al usuario debe informársele sobre el proceso de migración de una forma clara y concisa, que no se preste a confusión.

NUESTRA PROPUESTA: UN PUNTO INTERMEDIO

Ambas metodologías tienen puntos positivos, pero creemos que lo mejor es no atarse a ninguna de ellas y desarrollar un término medio que recoja lo mejor de ambas, y así lo hemos hecho en nuestros proyectos.

De la metodología tradicional nos interesa la solidez de cada paso y la seguridad con la que se da. Todo está perfectamente previsto antes de poner en marcha nada, y el usuario, desde el principio, llega a su entorno definitivo.

Cualquier prueba, además, se hace en un entorno limpio con usuarios de prueba.

De la metodología FastTrack nos parece interesante la reutilización del piloto, aunque no nos parece tan urgente que haya usuarios funcionando en O365 en «horas».

Así pues, un esbozo de plan de migración podría ser el siguiente:

• Breve fase de análisis (2-3 días), donde se verifican los requisitos, la funcionalidad deseada y el estado de la infraestructura actual.
• Creación del tenant y sincronización con el DA local (unos 3 días), incluyendo contraseñas. Esto no afecta en nada crítico al entorno actual, por lo que no hay riesgo y se puede hacer rápidamente. Permite que desde el principio los usuarios utilicen su usuario y contraseña habitual.
• Puesta en marcha de mecanismo de migración y coexistencia (pocas horas).

Si fuese necesario poner en marcha servicios como Single Sign On, pensamos que es mejor tenerlos desde el principio, de forma que pueda probarse antes de que los usuarios estén migrados.

En paralelo a esto, se definirían los usuarios que van a ser migrados en primer lugar (piloto), y se crearía una estructura básica de Sharepoint, además de alguna guía de inicio rápido para ayudar a los usuarios.

Continuaríamos con:

• Migraciones piloto (2-3 días), para verificar el funcionamiento y calcular los tiempos necesarios para el traspaso de información.

A partir de esa migración piloto, habría que analizar los resultados y cómo fue el proceso, lo que nos lleva a:

• Actualización de documentación para usuarios y helpdesk (1-2 semanas). Durante los pilotos hemos podido confirmar si la documentación que dimos a los usuarios es útil o no, si cubre todos los supuestos y si son capaces de interpretarla correctamente. Toda la documentación corregida debe ubicarse en un repositorio y ser conocida por el Helpdesk, para poder dar soporte.
• Definición de las tandas de migración y el calendario: Como ya sabemos lo que tarda la migración en cada caso y el nivel de soporte posterior que se va a necesitar, podemos disponer el calendario de migración, seleccionando los usuarios que van a ser migrados cada día hasta terminar.
• Comunicación a usuarios: El piloto nos ha permitido ver si la información que proporcionamos es suficiente. Con los datos que el usuario necesitará (URLs, primeros pasos, FAQ, etc.) y con un calendario ya establecido, podemos proceder a comunicar a los usuarios con tiempo los detalles de su migración, para que estén preparados.

A partir de aquí, sólo quedaría continuar con la migración de usuarios a un ritmo que nos permita dar un soporte adecuado a los usuarios. Es importante señalar que, además de las lógicas restricciones de ancho de banda, el factor más importante para determinar la tasa de migración y la duración de la misma será nuestra capacidad de soporte. Muy raramente las migraciones pueden llevarse a cabo sin ninguna intervención en el PC o el dispositivo móvil del usuario, por lo que debemos tener claro cómo vamos a ayudarles a realizar el cambio.

Por último, una reflexión que creemos muy importante. De nada sirve que técnicamente un proyecto se haya realizado con éxito si desde el punto de vista del usuario ha sido un desastre. La percepción del usuario es clave, y lo más habitual es que haya una gran resistencia a cualquier tipo de cambio en la forma de trabajar habitual a la que están acostumbrados. El éxito o fracaso de un proyecto debe medirse también según hayamos sido capaces de hacer lo que técnicamente había que hacer con las menores molestias para el usuario.

¿Qué pensáis vosotros? ¿Estáis de acuerdo con esta visión?