We helped a customer lift their existing SAP system to the cloud while at the same time upgrade to the latest version of SAP S/4HANA.
Amazon Web Services provided cloud infrastructure for the transformation before the upgraded SAP system was migrated to SAP’s HANA Enterprise Cloud.
To date,smartShift has completed more than a dozen conversions of ECC 6 systems to S/4HANA. One recent conversion involved a rather unique requirement around infrastructure, and we thought it would make for a good story.
The Challenge: Custom Code within SAP S/4HANA When Converting from On-Premise
As background, the customer was running ECC 6 on premise but elected to adopt SAP’s HANA Enterprise Cloud (“HEC”) as its S/4HANA hosting solution. A challenge immediately arose around the restrictions SAP applies in HEC to operating system and database level access. These restrictions imply that if SUM/DMO (see below) was pointed from the customer’s on-premise ECC 6 system to SAP HANA Enterprise Cloud during our technical conversion, it was unlikely to succeed because necessary adjustments could not be made at the operating system and database levels. What to do?
In short, we got creative. Why not work with a cloud provider where we can have control over the operating system and database layers to architect an exact replica of the target S/4HANA system that would be hosted in SAP HANA Enterprise Cloud. If we could do this, we could create the customer’s S/4HANA system outside of SAP HANA Enterprise Cloud and migrate it into SAP HEC at the end of our technical conversion process. It all looked possible on paper, but would it work in reality?
The first step was constructing our technical approach, supporting rationale, and a detailed plan. We also did a substantial amount of requirement gathering to ensure the interim cloud and final SAP HANA Enterprise Cloud environments matched identically down to the component version numbers and support package stacks. This was presented to and discussed with the customer’s various SAP subject matter experts, who collectively agreed with us that – on paper – this was indeed a viable approach. The customer ultimately agreed to proceed, and our journey on this uncharted path to S/4HANA in the Cloud was officially underway.
Amazon Web Services as Cloud Provider
The next step was for the customer to decide on a cloud provider to host the system that would be converted from ECC 6 to S/4HANA and subsequently migrated to SAP HANA Enterprise Cloud. The customer selected Amazon Web Services (“AWS”) and directly procured their infrastructure due to data privacy sensitivities that were better handled via a direct contractual relationship between AWS and the customer.
Once procured, the customer’s AWS environment was setup bysmartShift in-house technical experts. Did you know we have configured cloud environments for many SAP customers and even operate a cloud managed services business as part of our global services portfolio? Once SAP on AWS was fully configured and verified, our transformation activities got underway.
Transformation Using smartShift and SAP Tools
SAP HANA to transform business processes. We first created a copy of the customer’s existing ECC 6 productive environment in their on-premise infrastructure to have a project environment for our technical conversion activities. We then executed SAP’s Software Upgrade Manager / Data Migration Option (“SUM/DMO”) on this project environment and pointed it at the SAP environment on AWS that our in-house cloud team had setup. This allowed us to upgrade the customer’s on-premise ECC 6 system to S/4HANA 1709, which at the time was the most current S/4HANA release version available.
With the S/4HANA 1709 system sitting in AWS, we applied smartShift’s intelligent automation platform to remediate the customer’s custom coding for S/4HANA. HANA performance, HANA compliance and S/4 compliance adjustments were applied to ensure custom coding would run and perform optimally in a cloud-based S/4HANA environment.
Because the customer wanted to limit how much transactional data was migrated to its S/4HANA system, we next undertook a special step in their technical conversion. We created a secondary instance of the S/4HANA 1709 AWS system and executed a client copy to create a second client within this secondary instance. But importantly, we selected an option during this client copy process to not bring any data into the second client – only configuration. This resulted in a second client fully configured for S/4HANA but without any legacy data. The first client was then purged, leaving just the second “empty” client in the secondary instance. A data migration exercise would be performed by the customer at a later date to populate their S/4HANA database with the limited legacy transactional data they desired.
Project Results and Lessons Learned
Voila! At this point, we had completed a successful conversion of the customer’s ECC 6 on-premise system to SAP S/4HANA 1709 hosted on AWS without any legacy transactional data. But one final and crucial step remained: moving the system from AWS into SAP HANA Enterprise Cloud. To do so, we created a HANA database backup of the “empty” S/4 system in AWS and provided SAP with a 100GB+ backup file to import into the customer’s SAP HANA Enterprise Cloud environment. Because SAP needed to certify the customer’s system running in HEC, it was a requirement that SAP perform the restore step of this system migration.
And wouldn’t you know it, to the customer’s delight it actually worked beautifully. The technical plan that everyone agreed looked possible on paper worked in reality! A couple key learnings from this project:
For customers who wish to use SAP HANA Enterprise Cloud as their S/4HANA hosting solution, a proven approach exists that allows specialists like smartShift to lead your technical conversion activity without violating SAP HEC operating system and database level access restrictions. If, as was true for this customer, on-premise infrastructure cannot be allocated for your interim environment requirements to complete SUM/DMO, cloud solutions such as AWS and others present viable alternatives.
Ensure the versioning details of every piece of hardware and software is known. Early in the project, we discovered that the customer’s SAP HANA Enterprise Cloud environment was running an obsolete operating system version that could not be installed in AWS. While we cannot be certain this would have created issues later in the project, we felt it was essential to minimize such risks by ensuring all hardware and software versions matched identically between AWS and SAP HANA Enterprise Cloud. We suspect this attention to detail was a contributing factor to our success with this technical conversion.
We hope you have enjoyed this article and welcome your questions, comments, and of course your interest in working withsmartShift Technologiesto accelerate your adoption of the latest digital innovations.
