Hoy día no es raro encontrar sistemas SAP ERP que ya están actualizados a EHP7, sin estar en HANA. A los clientes SAP en esta situación, que desean migrar su sistema SAP ERP a HANA, podría sorprenderles saber que esta es una migración más simple que aquella que requiere una actualización dentro del mismo proyecto.
Esto no significa que siempre sea una mejor opción actualizar SAP ERP a EHP7 en un proyecto separado, y dejar la migración a HANA para un proyecto posterior. Existe la idea equivocada de considerar la actualización a EHP7 como una «preparación» antes de ir a HANA.
Siempre va a ser más económico y menos estresante para los usuarios y para el negocio hacer un único proyecto, sobretodo ahora que SAP provee una herramienta especial para ejecutar ambos cambios en forma simultánea con un downtime más corto: la herramienta DMO (Database Migration Option) del utilitario SUM (Software Upgrade Manager).
Pero, cualquiera sea la razón por la cual un sistema SAP ERP ya se encuentre actualizado a EHP7, la migración a HANA se puede simplificar en el sentido de que es solo una migración heterogénea o migración clásica. O sea: una migración del sistema SAP en la cual cambia la base de datos y, eventualmente, también el sistema operativo. Como sabemos, SAP HANA para SAP ERP hoy día puede ser instalado sobre Linux Suse o Redhat en plataforma x86_64 (Intel o AMD), o en Linux Suse sobre la plataforma Power de IBM.
En esta situación, entonces, aplica la misma metodología clásica de migración heterogénea y las mismas herramientas. Pero hay una salvedad: es necesario hacer correcciones a los programas ABAP custom (programas Z) para adaptarlos a esta nueva base de datos, que no es igual a cualquier otra base de datos relacional. Estas correcciones no suponen en la mayoría de los casos un gran esfuerzo, pero es necesario saber qué es lo que se debe corregir y qué es lo que se debe probar.
Un error sería no saber corregir lo necesario y ante esto, obligar a los usuarios a hacer pruebas integrales, igual que en el caso de una actualización. Esto aumentaría innecesariamente el costo del proyecto y el impacto sobre el negocio y sobre los usuarios.
Otro error sería definir un alcance de correcciones demasiado amplio, incluyendo no solo las correcciones estrictamente necesarias, sino que tratar de abarcar optimizaciones de performance u otros cambios que no obedecen a la migración a HANA. En cualquier proyecto de migración, el concepto es hacer el mínimo de cambios que aseguren la continuidad operacional del sistema. Si se considera necesario hacer optimizaciones, u otros cambios de cualquier tipo, la recomendación es siempre hacerlos después de que la migración ha sido exitosa. En caso contrario estaremos haciendo muchas modificaciones en forma simultánea, lo cual aumenta la complejidad y los riesgos del proyecto, y nos obligarán a un set de pruebas de mucho mayor costo e impacto.
Desgraciadamente, hay herramientas de terceros (no SAP), que tienen un costo importante y que recomiendan estas megacorrecciones después de un análisis del sistema en cuestión. No hay que olvidar que SAP provee las herramientas necesarias para estos análisis, y en forma gratuita, para todos sus clientes, y que ellas permiten establecer en forma exacta los cambios necesarios.
En resumen: lo importante es usar las herramientas adecuadas, de modo de definir un proyecto lo más simple posible, con el menor costo y con el menor impacto para los usuarios y para el negocio. En Novis ya hemos hecho esto para varios clientes, contamos además con una amplia expertise en HANA y con la experiencia de muchos años haciendo migraciones heterogéneas. Por lo mismo, en nuestro equipo existen consultores técnicos SAP certificados en migraciones heterogéneas, lo cual es un requisito necesario para disponer del soporte de SAP durante el proyecto.
Para más información de nuestros servicios le invitamos a contactarnos, a través de informacion@novis.cl
Feedback/discusión con el autor: Glen Canessa, Director de Preventa de Novis
