In our first blog, we provided an overview of the HANA Enterprise Cloud (HEC) and introduced the services that are available for customers that ensure a smooth transition to the HEC. The second blog detailed the technical assessment available to customers to help them develop a technical landscape and put together a plan for migration to HEC. In the third installment of this series, we will dive into the Onboarding and Migration Services provided by SAP for customers looking to move their existing applications to the HEC.
The Onboarding & Migration service is really where the “rubber meets the road” for a customer’s migration to HEC because this is when the customer systems are migrated to the HEC. Careful planning in terms of downtime, upgrade execution and OS/DB migration is required to ensure a smooth transition and minimal impacts to the end user community. The service involves tight collaboration among multiple teams, including customer, SAP Services, the operations teams from the HEC, and the HEC Center of Excellence (CoE) in order to be successful.
One point of note—the Onboarding and Migration service is needed to migrate existing systems. If the targeted applications for HEC are “greenfield” or new installations then no Onboarding & Migration services are required. The installation of these systems are included in the HEC monthly fees.
Instead of an FAQ style approach like last blog, we’ll take customer example to give you an idea of what a typical migration will look like in this one.
The customer is going to migrate an existing BW system and consists of the following technical landscape:
- 3 tiered landscape (DEV, QA, PROD) – single instance of each, no high availability for ASCS or database
- SAP BW Version 7.01 with Dual stack (ABAP+Java add-in)
- OS/DB is AIX/Oracle with 2 TB uncompressed production database with HANA sizing report output of 500 GB compressed and (1) 1024 GB node required
- Unicode implemented
- Users primarily use BEx web for reporting (750 named, 50 concurrent)
- Customer does not require special downtime minimization considerations using Post Copy Automation and delta queue cloning. A 3-5 day outage is ok over a weekend.
- Customer has existing sandbox hardware that can be used as testing environments for upgrades and exports.
- Solution Manager is fully configured in existing data center and they would like to continue to use the existing SolMan to monitor the new BW on HANA in HEC.
Therefore, the project approach will need to account for a stack split to separate out the Java stack from ABAP stack before upgrading to 7.31. The SAP Services team and project have agreed to a traditional 5 cycle approach for OS/DB migration as shown in the following graphic:
The customer and SAP Services work closely together to create a detailed migration plan and once this is agreed up the project starts.
The phase of the project can be termed landscape preparation. The following items are addressed here:
- Setting up the connection between HEC and existing data center. Currently IPSEC VPN and MPLS connections are used, but customers typically use IPSEC VPN to start since it is much easier to put in place. If required, an MPLS connection can be worked in parallel while the migration project occurs.
- From the customer side, the sandbox landscape was configured from server, OS and disk perspective to receive a copy of production system. In addition, user accounts and necessary access to the infrastructure is verified
- From the HEC side, the new infrastructure is provisioned and allocated to the customer. User accounts, access via Jump Box, VPN connections, and other infrastructure tasks should be validated before beginning the project.
In the execution phase of the project, 5 cycles are conducted. The timing of this phase varies depending on the customers testing and validation requirements.
- In the first 2 cycles, copies are taken of the production and development systems and placed into the sandbox environment. The production cycle is important to get a fairly accurate assessment of how long the downtime will take to perform the upgrade and OS/DB migration based on database size.
- For each cycle, a stack split occurs, the system gets updated to 7.31 and then OS/DB Migration export is generated. The export dump is VPN’d or shipped via FedEx (depending on size) to the HEC. From here, SAP Services works with the HEC to run the OS/DB migration import and install the new system on HANA.
Finally, the productive system is validated and turned back to the end user community.
