Migration to SAP HANA – How to Avoid Surprises | SUSE Communities

Migration to SAP HANA – How to Avoid Surprises


Guest blog by Tomas Kovac, Custom Solutions Architect at Datavard, co-exhibiting partner at SUSE booth #859 at SAP SAPPHIRE NOW and ASUG Annual Conference

What are the key benefits of migrating to SAP HANA for both organizations and regular SAP users?

In short: speed, access to the latest SAP technologies and simplification. Customers also like the option to get rid of the on-premise IT infrastructure – and move with SAP HANA to cloud (e.g. HANA Enterprise Cloud) as it’s simpler and more seamless than ever. Currently, SUSE and Microsoft are collaborating to provide best-in-class cloud infrastructure built specifically for SAP HANA. Cloud computing guarantees fast ROI, while its agility is just perfect for the changing business environment and future needs of organizations.

What does it look like from the technical side? What is the perfect roadmap for migrations?

There are several approaches to migration to SAP HANA, whether the target is SAP on HANA as a database or even BW/4HANA and S/4HANA.

We recommend a smart combo of all of them – a unique approach that incorporates various options for minimizing the business impact and that can be dynamically introduced based on the particular scenario. Apart from DMO, which is considered the SAP standard for BW on HANA upgrade, we often go for the SLO approach which significantly shortens system’s outage and gives more flexibility by migrating relevant data only and/or transforming the staging objects to BW/4 HANA compatible objects. For the move to S/4 HANA, we recommend a phased approach per legal entity or group of legal entities to minimize any impact on all business. A process vice transition is technically feasible, but only under very limited circumstances recommended.

After clarifying the HANA benefits to customer, we proceed with the more technical part of the migration by analyzing current production systems with tool based (S/4 or BW/4) HANA readiness checks. Having detailed analysis results, we can safely plan the migration project. For those who have no HANA experience, we would recommend to start with an upgrade of the BW system first.

What are the issues that might occur? What do you need to watch out for?

There is a good old rule – never touch a running system. The DB migration to HANA seems to be as straightforward as any other OS/DB migration. However, we still recommend running a proper AS-IS assessment to avoid surprises during the actual project. For example, with older releases we often see big challenges with ABAP compatibility. Moreover, S/4 or BW/4 upgrade brings further challenges as the SW architecture changes.

Diligent process impact analysis is key to assure smooth project execution on the ERP side, while with BW the focus needs to be shifted on the proper reporting analysis.

This is also the reason why we put emphasis on the Readiness check assessment.

One last piece of advice for anyone planning to migrate?

It’s ok not to know everything and a good pre-assessment can help you to set-up for success. System migration is not something you do on a daily basis during your nine-to-five. It is a complex project that requires specialized tools, expertise and experience, so don’t be afraid to reach out to others, ask questions or express your doubts. Now you have a chance to meet our experts in person – find us at SAPPHIRE NOW

About the author

Tomas Kovac, Custom Solutions Architect at Datavard

Tomas is a solution architect with technical background and experience in SAP ABAP, SAP Basis & Technology, SAP Customers and Projects. In the past, he worked on the SLO Projects on both Basis and Application levels and participated in the design and development of the Datavard migration software.


(Visited 1 times, 1 visits today)


  • Mike Nelson says:

    This is quite informative and I’ll look forward to learning more – directly – while at SAPPHIRE in a couple weeks. Thank you, Tomas.

  • Leave a Reply

    Your email address will not be published.