Ya hace un tiempo que salió HANA al mercado y que los clientes de SAP Business One pueden usarlo en sus nuevas implementaciones. Los que tienen SQL Server como base de datos ya han empezado a migrar sus sistemas hacia la nueva plataforma estrella de SAP.
Esta guía rápida puede ayudar a tomar en cuenta esa gran cantidad de consideraciones a resolver para lograr un proyecto exitoso.
El proyecto de migración
Realizar exitosamente un proyecto de migración de SAP Business One SQL Server a SAP Business One HANA es una tarea que parece trivial de arranque pero que tiene una gran cantidad de actividades a contemplar y que a veces se sobreestiman ni se toman todas en cuenta.
Puede ser falta de experiencia o falta de un marco claro de pasos a seguir, siempre sustentandose en un buena definición del alcance del proyecto y un respaldo de conocimiento técnico que nos permita realizar dichas tareas .
Cuando un cliente desea migrar su sistema SQL Server a HANA está por lo general soportado por una arquitectura así:
Para hacernos una idea de la solución la siguiente imagen representa lo que deberíamos configurar para poder migrar ese sistema a HANA según la arquitectura oficial del producto:
Sin entrar en muchas explicaciones técnicas, ya que no es el objeto de este post, acá lo importante son los 2 servidores representados en la figura tanto abajo como a la derecha.
El servidor de abajo representa el servidor Linux SUSE donde operará HANA y el de la derecha es el servidor Windows de los servicios y el Integration Framework + Otros.
Acá lo importante es que el cliente esté claro de que ambos ambientes de SAP Business One SQL Server y SAP Business One HANA deberán coexistir en su misma red empresarial (por un periodo de tiempo determinado), hasta que finalice el proyecto de migración de forma exitosa y las pruebas técnicas y funcionales que corresponden aplicar.
Para conocer cómo realizar la instalación de SAP Business One en HANA y algunos trucos útiles pueden ver este post en donde describo el proceso de una forma rápida y sistematizada.
El sizing
Antes de entrar directamente a lo que vendría a ser el plan de proyecto general de un proyecto de migración de esta naturaleza, es importante que el cliente arranque con el Partner que lo acompaña la realización de las estimaciones necesarias de recursos que éste necesitará para aprovisionar los recursos y así poder instalar HANA.
Una muestra de este sizing podría ser algo así (tómese como ejemplo únicamente, cada cliente es totalmente distinto):
En este caso lo que nos sugiere la herramienta es el recuadro señalado en rojo, es a la cantidad de memoria que utilizará HANA para desplegar la solución de SAP Business One en función a todos esos parámetros que podemos visualizar más arriba y que deben ser llenados por el usuario ya que el es el único que conoce sus procesos más la experiencia del partner que lo acompaña en el proyecto.
Una vez obtenido un resultado estimado lo recomendable es hacer un redondeo hacia arriba en términos de “core de memoria” ya que HANA funciona y se vende al cliente en core de 64GB.
Por lo tanto acá lo recomendable sería que el cliente adquiera 2 core de memoria para un total de 128GB y así hacer frente a los recursos necesarios que se estiman para instalar la solución.
Esto es meramente referencial y cada caso debe ser analizado técnica y funcionalmente de forma detallada.
El sizing sirve para que el lector se haga una idea como se hace este proceso por lo general.
Entonces siguiendo con el tema tenemos podríamos definir este proyecto en 2 fases:
- Una fase en donde se realizaría el plan de pre-migración.
- La migración total del producto.
Los equipos del proyecto
Antes de seguir es bueno poner nombres y apellidos a las macro-tareas y de esta manera definir los 5 actores fundamentales que por general hacen escena en proyectos de este tipo:
- El Cliente, que podríamos llamar el Product Owner (PO)
- El equipo técnico que liderará el proyecto (TT).
- El equipo funcional (FT).
- Ventas (SALES) (por lo general están solamente al inicio del proyecto y no se ven más).
- Desarrolladores de addons (DEV)
Pre-proyecto
En base a esto definiremos este pre-plan de migración con sus actores asociados al final:
- Determinar los recursos actuales con los cual funciona el sistema actualmente. Una revisión técnica detallada en la cual se determinen sistema operativo, versión de SQL Server y versión del producto. (PO)
- Revisar la Matriz del producto de SAP Business One HANA para ver si la versión que tiene el cliente es migrable directamente o si necesita de un mini-proyecto de Upgrade antes para que quede operativa y así si pueda ser migrada a HANA. (TT)
- Revisar los addons con los cual trabaja el cliente actualmente. Esto es fundamental, ya que determinan a veces si es factible la migración o no y retraso que esta pudiera tener en caso de que el desarrollador de o los addons no tenga una versión operativa en HANA o se necesite realizar el desarrollo del nuevo add-on correspondiente. (FT) & (PO)
- Hacer un inventario de la cantidad de reportes en Crystal Reports, búsquedas formateadas, consultas generadas en el Query Manager, etc y como todas estas afectan a los procesos definidos en la herramienta. Acá en este paso teniendo ya un inventario definido y con la experticia del equipo funcional se deberían de calcular las horas necesarias que consumirá tales actividades dentro del proyecto. También es prudente tomar en cuenta y hablarlo con el cliente si algunos de estos reportes serán migrados a los nuevos reportes de Modeling que hace uso HANA y que son la propia evolución del producto (FT)
- El punto 3 es fundamental y no puede ser pasado por alto. Muchos proyectos de migración se han parado por no haber considerado este relevamiento de forma oportuna causando muchos inconvenientes a todas las partes involucradas. (FT) & (PO)
- A nivel del equipo funcional y el cliente deberán determinar las nuevas necesidades a ser implementadas en HANA haciendo un proceso de Sizing . Esto no es más que lo explicado previamente para determinar la cantidad de memoria a usar por HANA(FT & TT & SALES)
- Un punto a considerar es el licenciamiento en función a la cantidad y tipos de usuarios (profesionales y otros) que serán requeridos en la nueva solución del cliente (SALES).
- El cliente deberá tener claro en donde va a funcionar la nueva solución, si funcionará en su Datacenter actual (si tiene sus instalaciones On-Premise) o en su misma nube en caso de tenerla contratada. Esto es fundamental por que a veces los clientes no tienen claro que ambas soluciones (SQL y HANA) deberán coexistir en la misma red al menos por el tiempo que dura el proyecto de migración (para evitar temas de latencias y otras particularidades técnicas a considerar en el proceso de migración). Para esto deberá aprovisionar exactamente los recursos necesarios estimados por el proceso de Sizing sumado a eso la experticia del equipo técnico para que la instalación del nuevo producto sea lo más expedita posible dentro del proyecto. Dependiendo de la solución de conectividad por la que se opte ir (On-Premise o Cloud) el cliente deberá adquirir servidores certificados que cumplan con las características señaladas por SAP y que a su vez cumplan las especificaciones estimadas. (PO)
El proyecto de migración
Ya teniendo esos puntos bien claros y resueltos en un plan de acción, se podría decir que entramos en lo que serían los puntos esenciales para armar un plan de proyecto con macro-tareas:
- Identificar la ruta de migración y la arquitectura horizontal dada la versión actual en la cual está el cliente (¿Cuál es específicamente 9x PLxx? Ver punto 2 de la pre-fase) y la versión de destino del sistema SAP Business One del cliente (HANA 10 PL03? siempre es necesario validar si se va a ir a la última versión disponible) (FT & PO)
- Configuración de hardware e instalación de SuSE Linux Enterprise para la instalación de HANA y SAP Business One. (PO & TT)
- Validar la conectividad (con mínima latencia) entre el ambiente actual de SAP Business One SQL con el futuro SAP Business One HANA que se va a instalar (que estén en la misma red/VPN/VPC). Nota: no se puede hacer migración si ambos ambiente si no se ven uno con el otro. En caso de que no se vean el cliente deberá resolver técnicamente el asunto. (PO & TT)
- Validar ambiente entregado por el cliente para la instalación de SB1 HANA 10 a nivel de procesadores, memorias, file systems, etc.En caso de no pasar la validación del equipo técnico el cliente deberá ajustar los requerimientos hasta lograr los valores y configuraciones deseadas. (PO & TT)
- Solicitar al cliente S-User de SAP para que el equipo técnico pueda bajar el software requerido para luego Instalar SAP HANA y SAP Business One, versión para SAP HANA. (PO & TT)
- Solicitar e instalar las claves de licencia para SAP HANA y SAP BUSINESS One, versión para SAP HANA. (PO & TT)
- Revisar las notas SAP para ver si es compatible la versión de B1-SQL a migrar con la versión destino HANA B1 (Se identificaron la ruta de migración y la arquitectura del landscape del sistema dada la versión actual y la versión de destino del sistema SAP Business One del cliente
-
- [Si corresponde] Tocará realizar la actualización de la base de datos de B1 en la versión de SQL Server para la migración quede operativa. (TT)
- Realizar la migración de la base de datos de SQL Server a SAP HANA.
-
- Test de migración
- Hacer un backup de la base de datos productiva actual (TT)
- Test de conectividad SQL Server – HANA (TT)
- Programar test de migración fuera de horario laboral sobre la copia (TT)
- Ver si el proceso resultó exitoso, sino aplicar notas que salieron en el test de migración con el equipo funcional para corregir las problemáticas que pudieran existir y no permiten que la base de datos sea migrable. (TT & FT)
- Repetir test de migración. Volver a 4 si hubo errores. (TT)
- Si todo OK entonces aplicar correctivos en la base de datos productiva del cliente. **Acá se mide el tiempo de Downtime** (TT)
- Hacer un backup de la base de datos del cliente en SQL Server (TT)
- Realizar migración a HANA (coordinada fuera de horario laboral). (TT)
- Test de migración
9. Realizar la actualización de la base de datos de B1 en la migración posterior a SAP HANA. (TT)
10. Inicializar el esquema de la compañía para las funciones analíticas con la Consola de administración de SAP Business One Analytics en HANA. (TT)
11. Migrar la personalización relacionada con la consulta SQL en:
-
- SBO_SP_TransactionNotification (Facturación Electrónica y revisar si es implementable y ver si aplica para destinar recursos de desarrolladores/funcionales para la migración) (FT)
- Las consultas definidas por el usuario, búsqueda con formato, alertas e informes, etc. (FT)
12. [Opcional] Crear modelos reutilizables o extender la capa semántica para escenarios analíticos (FT & TT)
13. Migrar Analytics
-
- Reportes de cristal. (DEV & FT)
- Configuración de los Dashboards, etc. (FT)
14. Migración de addons y pruebas de funcionalidad de los mismos en el nuevo ambiente (DEV & FT)
15. Instalación de los nuevos clientes de SAP Business One HANA por parte del personal TI en las estaciones cliente o en su defecto en el Servidor Terminal. (PO o TT)
16. Pruebas funcionales con los usuarios y Tests del nuevo ambiente. (FT)
17. GO – LIVE (PO con apoyo FT & TT)
Para cerrar…
Los proyectos de migración si se hacen de una forma bien planificada y tomando algunas de estas premisas acá señaladas (las cuales fueron tomadas de la guía de SAP para tal fin y las buenas prácticas en este tipo de proyectos) resultan exitosas en su mayoría.
Creo que todos los puntos señalados son válidos a tomar en cuenta y hasta imprescindibles en muchos casos si queremos lograr un éxito seguro.
Hay muchas consideraciones técnicas, pero más hay a nivel funcional que son muy importantes a tomar en cuenta y estas consideraciones funcionales se ven más reflejadas en el proceso del test de migración.
Por lo general si en la instalación de SAP Business One SQL Server del cliente (siempre tiene años de uso intensivo) se hicieron malas prácticas a nivel de campos de usuarios, tablas de usuarios y desarrollos propios que comprometan las buenas prácticas señaladas por SAP, indefectiblemente están van a salir a flote en el proceso del test de migración a manera de alerta para su corrección, inclusive sin dejarnos seguir en el proceso. No podremos realizar la migración sino corregimos lo que nos señala el asistente.
Justamente este test es para validar todo lo malo que pudiera existir a ese nivel y que el cliente con el apoyo del equipo funcional, deberán corregir para solventar esa situación mediante la aplicación de notas SAP que el mismo asistente dictamina en función de los errores encontrados en el camino.
Una vez solventados esos errores el proceso de migración se ejecuta nuevamente (siempre y cuando validemos todos los aspectos técnicos referidos al proceso y que es necesario revisar en la guía de administración del producto) a fin de no tener inconvenientes y lograr el resultado esperado de migrar SQL a HANA.
Espero les sirva esta guía rápida de migración a HANA en SAP Business One y los invito a dejar sus comentarios a ver qué les parece y que le podemos agregar o quitar en base a sus experiencias.
Gracias por tu lectura.
Articulo original en https://blogs.sap.com/2021/01/25/migrando-sap-business-one-sql-server-a-hana/