Migrating SAP to Public Cloud? – Options, Approach and Key Success Factors ?

Migrating SAP applications to cloud is always a strategic decision for any organization because of its business criticality. The discussions around SAP on public cloud has significantly matured over the years. Its no longer about “when” but “how”. The key drivers which make the organizations look for SAP on public cloud are

1.      Getting rid of unproductive but time-consuming activities like capacity planning and technology refresh through on-demand elasticity and infinite scalability.

2.      Improved operational efficiency through out of box automation

3.      Improved system reliability, backup and archival, availability and disaster recovery without much incremental cost using the right architecture.

However, the key driver is having the business to focus on core business initiatives and accelerate innovation by focusing on improved user experiences and mobility for improved productivity.

Difference between SAP R/3, ECC and S/4 HANA.

Before we get started, let us first try and understand the difference between SAP R/3, ECC and S/4 HANA.

SAP R/3 is the first-generation version Enterprise Resource Planning software and its name is derived from the three-level architecture of the software (Presentation, Application and Database layers). It is based on client-server architecture and includes modules like financials and human resources, Production Planning, Materials Management etc.

The successor version SAP ECC (ERP Central Component) launched in 2004 is the core ERP product within SAP Business Suite of products. SAP Business Suite goes beyond the foundational ERP modules and includes specialized functions like supply chain management (SCM) and customer relationship management (CRM). While the R/3 uses the client-server model, SAP ECC runs on a web-based application server.

S/4 HANA is the 4th generation ERP system from SAP designed to run only on HANA database which is an in-memory database compared traditional database like Oracle, SQL and DB2 of ECC which runs on disks. HANA database is based on columns instead of rows in a traditional database and is generally better suited for analysis-oriented work because aggregations and other arithmetic operations can be performed faster.

SAP expects its customers to move from SAP R/3 or SAP ECC to SAP S/4 HANA by 2027 as it will stop the mainstream maintenance followed by optional extended maintenance till 2030.

Approach for SAP migration to cloud

Having understood the difference between the 3 versions of SAP ERP software, we need to consider the migration options available for the clients to move to cloud. A good strategy should consider both short -term goals like decreasing hosting costs as well as long-term goals like improved business process and performance. It is very important to plan your migration well or else you will end up with more costs, increased timelines and lower ROI.

The starting point always is choosing the right and a reliable cloud service provider. SAP has certified combinations of SAP applications, OS and DB versions that they'll support on Public cloud. Determining if your existing systems fall into what is supported will influence the methods used for migration. The two main SAP migration approaches are

a)     SAP Lift and Shift Migration – This includes homogeneous and heterogeneous migration approach.

 ·      Rehost Migration or Homogeneous Migration - Rehost migration is a lift-and-shift migration by lifting an existing SAP application out of its current hosting environment and rehosting it on public cloud without any change in application, database and OS layer. Since this does not require making extensive changes, it enables a faster and cost-effective migration with minimal disruption and quicker ROI. This is achieved using methods such as Classic system copy and OS-DB migrations.

·      Heterogeneous Migration or Replatforming – In this approach, while the application is maintained as on-premise environment, one or more of the layers (database or operating system or both) undergoes a platform change for e.g. IBM AIX to Windows or Linux and Oracle/DB2 database to SQL. This approach is slightly more time consuming that the homogenous migration approach but leads to be a better ROI.

While lift and shift migration may appear simple, the complexity lies in the fact that public cloud may not support all the technologies or architecture of on-premise environment or may function differently in the target environment. A common example is the migration of high availability (HA) database architecture of Oracle RAC on-premise to Oracle data-guard or Azure SQL server always-on based HA architecture on Public cloud.

b)     SAP Transformation to Cloud

In this approach application layer is transformed to SAP S/4 HANA along with the OS and DB through either a greenfield or brownfield implementation. Compared to lift and shift migrations, this migration brings the benefits of cloud native features, reinvented processes and new UX. The benefits of transformation often outweigh the effort and costs of adapting to a new system.

There are two options for migrating to S/4 HANA

a.      Greenfield Implementation – As the name suggest, this requires setting up the application from scratch, though the data is preserved and migrated to the new system after cleaning/archiving and reformatting to work with the new systems. This is the most time consuming and complex migration approach where the existing functionality and the business process needs to be migrated to the new system.

b.      Brownfield Migration – This uses the system conversion technique to migrate your existing ECC system to S/4 HANA including all its customization and data in a brownfield approach.

To choose the right approach, there are many factors to be kept in mind – Data Quality (cleaning and maintaining data), Unicode, Data archival and retention policy, configuration and feature availability, number of interfaces/integrations etc.

If you could manage your system in terms of code, data and integration without much pain, a brownfield migration to S/4 HANA would be the recommended option. However, if you have a lot of technical debt in your system, a greenfield migration would be a better option that would reward you with a clean and simplified result.

There are generally two different SAP tools used for heterogeneous migrations based on the conversion and downtime requirements. For homogeneous migrations, you could use your database's native system replication methods to get your data into the public cloud and minimize your cut-over downtime requirement.

Classical Migration using SWPM DISMON and MIGMON: SAP’s Software Provisioning Manager (SWPM) is exclusively for database migrations along with Distribution Monitor and Migration Monitor tools. Classical Migration uses a heterogeneous system copy approach and is sometimes referred to as two-step migration as first step being that of a migration followed by a second step facilitating an SAP upgrade.

SAP Database Migration Option (DMO): DMO facilitates both an SAP upgrade and a database migration to the SAP HANA database using one tool. DMO process is often referred to as a one-step migration as both the steps are handled together.

Critical Success Factors for a smooth and non-disruptive SAP migration to Cloud

Taking care of all the technical aspects do not necessarily guarantee a smooth cloud migration journey. In-fact there are many non-technical aspects which may jeopardize your cloud journey. Below are a few which I have summarized.

Integrated Governance and Project Delivery – This is by far the most important and critical aspect of a successful SAP migration program. It is important to establish a good governance process at the start of the project including defining responsibility between various stakeholder – Client Organization (technology and business), SAP, Cloud Service Provider and third-party providers. This also includes governance between the operations team (infrastructure and applications) and the project team to avoid multiple transitions and hands-of. It is generally a good practice to have all the stakeholders agree and signoff on critical aspects viz. Design, Migration approach and tools, extent of testing required etc.

Communication – It is important to keep the technical and business Communications separate. Business should only know what is required including what’s going on well and what is not to avoid any surprises. The major part of the communication should be limited to the technical teams.

High level and detailed project trackers – Its important to have both the views of project plan as the audience and objective for the two is different. While the high-level tracker is for management reporting as well as to track delays even before it gets into detailed execution, detailed trackers are important to avoid any surprise across the program.

Testing – The three migration approaches viz. Homogeneous, Heterogeneous and S/4 HANA require different levels of testing. While the homogeneous migration requires the least testing because of minimum changes to the environment, S/4 HANA migration requires most elaborate testing. It is good to engage the global business process owners early to agree on the scope of testing (Integration, Regression, Performance etc.)

Change Management – SAP cloud migration programs have multiple stakeholders and owners each having their own priorities. Sometimes because of unplanned delays, things are in a continued state of flux. Hence a robust change management process across technical and non-technical areas goes a long way in reducing the risk of unknown and unplanned work. The ground rule is that once the system is tested and approved for migration, there should be a complete change freeze and only the critical changes should be allowed after accessing its impact through a change management process.

Automation – The focus should be to automate end to end project delivery from cloud foundation and SAP application build to data migration and quality checks across the project phases. This will require a detailed build and migration run books to be created for all the System IDs which could further be automated. This not only avoids defects but also helps in reducing the downtime window for migration which is critical to the business.

Clean the data before migration - Many organizations have accrued huge amount of business data, which is not used often resulting in huge database size. This can impact the SAP migration in different ways – downtime requirement for the migration, System availability in the cloud during HA or disaster recovery failover, backup SLAs, system performance etc. A better approach is to proactively cleanse, archive and purge the data anomalies to minimize the time and efforts required for migration as well as maintain and support data that does not add value.

Get back to basics and your hands dirty when required – When things are not going as per the plan, you may struggle get the right answers from the team because they are under stress and perhaps not properly rested. Sometimes, you may be thrown with many technical jargon which is difficult to understand. This is the time when you will have to go back to the basics of being logical and simple in your review, understand the reason behind the delay or an issue/defect and an action plan to get back to green. Its important for the team to see you being involved and invested in the project to have a mutual respect.

To summarize, considering the business criticality, no-one likes to see surprises or missing deadlines in SAP migration programs. It is important we do not underestimate the complexity of the project and plan it well and keep on re-calibrating the plan during the program.