Migración Jira de Server a Cloud

El problema del cliente

• End of Life del Producto. Atlassian en Febrero del 2024 deja de proporcionar soporte a Jira Server.

• Exceso de configuraciones a medida y en consecuencia administración cada vez más compleja. 

• Tendencia a la perdida de conocimiento funcional debido a la complejidad de la solución.

• Posible afectación a otras áreas al implementar nuevas funcionalidades. Probabilidad de issues en aumento y en consecuencia una difícil gestión del cambio. 

• Intención de reducción de costes: 

  • En licencias: Tanto de usuarios como de mantenimiento de instancia y plugins. 

  • En infraestructura: Mantenimiento (IaaS)

Los objetivos del cliente

El Departamento de IT de Planeta, planteaba varios objetivos: 

• Cambiar a una configuración distinta para tener la capacidad de escalar a varios proyectos resolutores desde el mismo Portal Cliente.
• Todos los tickets debían migrarse para poder mantener un histórico, estuvieran abiertas o cerradas.  
• Implementar una CMDB para mantener una gestión centralizada de todos los cambios relacionados con sus servicios y aplicaciones. Integrándolo en los tickets y sus procesos para un mayor control y seguimiento. 
• Para agilizar el trabajo de los agentes de primer nivel en los portales Service Management, se requería también de la automatización de tareas y notificaciones sobre todos los tickets enlazados. 

Reto principal a resolver

Para entender el reto principal, se partía de una configuración basada en la replicación de acciones entre proyectos tipo Service Management y Software. 

El cambio al nuevo modelo suponía transformar todo el flujo de trabajo definido en los proyectos, reestructurar el sistema de permisos y los grupos de usuarios involucrados. 

Así pues, no solamente se debían migrar más de 140000 tickets, sino que también se tenían que transformar al nuevo sistema Cloud aquellos que estaban sin resolver, para de esta manera, poder seguir tramitándolos. 

Además, la estructura de la CMDB (Configuration Management Database para el control de activos) la tenían en otro medio, por lo que se debía incorporar al nuevo sistema e integrarlo con los campos que ya usaban sus tickets. 

En cuanto a los usuarios, los que ya estaban dados de alta en el entorno Cloud, debían recoger todos los datos que tenían en los entornos Server. Tenían dominios diversos y correos repetidos que dificulta la migración porque en Cloud los correos deber ser únicos y solo los dominios reclamados por la empresa pueden ser gestionados por los administradores. 

La solución

Para poder satisfacer las necesidades del cliente en cuanto a la administración y escalado de funcionalidades, se implementaron reglas; usando una funcionalidad que ofrece Jira por defecto llamada "Automations". Ésta permite configurar acciones automatizadas transparentes para los usuarios, que se activan según la configuración que determinen los administradores. 

Durante la migración, se crearon reglas que detectaban cuando un ticket migrado aún estaba sin resolver y lo replicaba con las nuevas configuraciones vinculándose al original para mantener el historial. 

Para minimizar el tiempo en los escalados, se automatizó el proceso de creación y de gestión. En la creación, se replican todos los campos con valores importantes y se le pide al usuario que especifique la mínima información necesaria, así el nuevo ticket se crea con los valores previamente configurados.

Adicionalmente, durante la gestión del ticket escalado, se crearon acciones automáticas que modifican la petición para que así el usuario solo deba preocuparse cuando el ticket está en ciertos estados. 

Otras acciones llevadas a cabo

En cuanto al uso de workflows genéricos y gestión de múltiples proyectos, se han refactorizado teniendo en cuenta y actualizando a los nuevos requisitos. 

El resultado de dicha refacturación se refleja en proyectos estancos con su configuración específica de cada área. También se tuvo en cuenta en esta fase el replanteamiento de grupos, roles y permisos, estandarizando el modelo y así poder escalar de un modo uniforme en el futuro.   

Relativo a los usuarios, para poder aprovisionarlos a la aplicación y gestionar sus credenciales, se implementó una nueva conexión con el Directorio Activo del cliente con la herramienta Atlassian Access. Para hacerlo tuvimos que definir un dominio único para la empresa y así pudimos reclamar todos los usuarios registrados en Atlassian Cloud que tuvieran el correo corporativo. 

Finalmente, mediante la planificación del proyecto establecida al inicio y las reuniones de seguimiento periódicas marcadas, se puso en producción la nueva instancia en la fecha deseada.