Skip to Content
Author's profile photo Marty McCormick

HANA Enterprise Cloud – Onboarding & Migration Services

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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Andy Silvey
      Andy Silvey

      Hi Marty,

      this is an excellent blog and the tip of the iceberg in terms of the kind of nuts and bolts information SAP Customers need in the subject of migrating to the cloud.

      This blog is the first I have seen which actually lays out the process and steps of migrating to the cloud.

      This blog I hope is just the beginning and I hope we will see on the SCN many many more such blogs where people who've done it, made the migration to the cloud, blog how they did it, lessons learned, what was great, what they could do better next time etc.

      The migration to the cloud question is going to land on SAP Architects and Basis Leads desks more and more, and material like this will only help to make the task of SAP Architects and Basis Leads planning migrations to the cloud easier.

      Thanks and best regards,


      Author's profile photo AMIT Lal
      AMIT Lal

      Problem with HEC is only SAP or its HW partners can do it...correct?

      Author's profile photo Former Member
      Former Member


      Hi Amit,

      Did you get confirmation on above said point?

      If migrations are involved is it mandatory to buy "Onboarding & Migration Service" from HEC/SAP?

      Can't customer or it's vendor do it on their own? or It's going to be joint responsibility between customer and HEC. Let's say customer/vendor will start export (in source in own data center) and with help of DMO System move option we provide dump to SAP/HEC to continue with build/import.


      Any comments?





      Author's profile photo AMIT Lal
      AMIT Lal

      Its fully owned by SAP consulting team and depends on your contractual obligations.




      Author's profile photo Abhimanyu Singh Rathore
      Abhimanyu Singh Rathore

      Hi Marty,


      Excellent blog..!! I have just one query, if customer is moving out of HEC and going on Azure cloud. Whether HEC provide same IPSec VPN tunnel or MPLS connection between HEC DC to Azure DC? Also, is it possible to setup HANA system replication from HEC to Azure if they provide network connectivity for production migration?



      Author's profile photo Wei-Shang Ku
      Wei-Shang Ku


      I really also want to know any HEC customer have had move out to other cloud provider successfully and how they did it. Is it worth ? Hope they did it at VM level , not at system copy level. How can HEC help customer during such migration ?

      Recently I heard a case, still in evaluation phase, trying to move S4 & BWoH from HEC to AWS and what customer can get is a backup of HANA database and some file backup at OS level.

      Since customer has no way to do anything at OS level on HEC, so the AWS guys (local partner) is looking for help from BASIS. The guy think it can be done by BASIS with System Copy.

      He draw out a list of "application" or "systems" need to be migrated..... long....  S4(3 env), BWoH (3 env), NLS, PI, Data Service, Opentext, and the size of database is in terms of Terabyte.

      I'll keep eye on this case see what happen next.

      If you do not have exit plan , don't put core systems on cloud at SaaS or PaaS level.

      Author's profile photo Karan Singh
      Karan Singh

      Hi Wei-Shang Ku,

      Any updates on this case? Did HEC provide a HANA backup over the network or ship out a hard drive?