AWS for SAP

Migrating SAP Workloads to the AWS Cloud with AWS SMS

Harpreet Singh and Devendra Singh are Solutions Architects at Amazon Web Services (AWS).

AWS Server Migration Service (AWS SMS) is an agentless service that migrates your on-premises VMware vSphere or Microsoft Hyper-V virtual machines to the AWS Cloud. In this blog post, I’ll discuss some of the main benefits of AWS SMS and explain how you can use this service to migrate your virtualized, on-premises (or private cloud) SAP workloads to Amazon Elastic Compute Cloud (Amazon EC2) instances on the AWS Cloud.

Here are some of the keys benefits of using AWS SMS:

  • Simplified migration: After you configure the source environment, you can migrate your virtual machines easily by scheduling replication jobs in the AWS Management Console. Replication to Amazon Machine Image (AMI) creation is a four-stage process that’s handled automatically when the replication job is executed.
  • Incremental migration: AWS SMS can replicate a live environment incrementally, which can speed up the migration process significantly. You can continue to run your production environment while it’s being replicated to the AWS Cloud.
  • Minimized downtime: There is no impact on production operations during incremental replication. However, final replication (cutover) does require downtime.
  • Parallel migration: With AWS SMS, you can migrate multiple virtual machines in parallel. With this capability, you can migrate your complete landscape (for example, migrate all your development systems at one time, and then quality assurance systems, and so on).

AWS SMS is free to use. However, during replication, it creates Amazon Elastic Block Store (Amazon EBS) snapshots and uses Amazon Simple Storage Service (Amazon S3) to store those snapshots, and there’s a cost associated with those resources. For pricing information, see the AWS website.

In this blog post, we’ll describe the general replication process with AWS SMS, and then we’ll discuss how you can use AWS SMS to migrate your SAP workloads.

Replication process

To set up your on-premises virtualized environment and AWS account for AWS SMS, see the detailed instructions for VMware and Hyper-V on the AWS website, or read the blog post AWS Server Migration Service – Server Migration to the Cloud Made Easy on the AWS Partner Network (APN) blog. As part of the setup, you deploy the AWS Server Migration Connector in your virtualized environment. When the setup is complete, you configure the replication job by setting its schedule and frequency. After you set up the job, the replication of your virtual machine with AWS SMS starts automatically and follows a four-step process. These four steps—scheduled, uploading, converting, and AMI creation—are executed sequentially for each replication job run.

Stages in the AWS SMS replication process

Figure 1: Stages in the AWS SMS replication process

Scheduled

In this step, the migration job(s) you configured are scheduled to run either at a specific time or immediately.

Figure 2: Replication job in Scheduled status

Figure 2: Replication job in Scheduled status

Uploading

This is a multi-step process:

  1. The VMware or Hyper-V snapshot of the virtual machine is triggered. The snapshot creates a VMDK file (for VMware) or an AVHD file (for Hyper-V).
  2. The Open Virtualization Format (OVF) file is created for the virtual machine. This is an XML file that contains metadata about the virtual machine.
  3. The VMDK or AVHD file created by the snapshot are uploaded to an S3 bucket. The S3 bucket is created automatically in the AWS Region where you’ve set up the AWS Server Migration Connector.
  4. After the snapshot files are uploaded to S3, they are deleted from the source environment.
Figure 3: S3 bucket with uploaded VMDK file

Figure 3: S3 bucket with uploaded VMDK file

Converting

This step handles two tasks:

  1. AWS SMS creates an EBS snapshot from the uploaded VMDK or AVHD file.
  2. AWS SMS deletes the VMDK or AVHD file from the S3 bucket.

Creating AMI

This step creates an Amazon Machine Image (AMI) from the EBS snapshot produced during the Converting step. After this step is complete, you can launch an Amazon EC2 instance from the created AMI.

The replication job continues to run at the scheduled frequency, with each execution repeating these steps. Each execution of the replication job brings only incremental changes to the AWS Cloud. When the replication is complete and the servers are ready to go live, you stop the production servers (on premises) to prevent further changes and execute the job one last time to bring in the delta from the last execution. After the final changes have been replicated to the AWS Cloud, you can create an EC2 instance from the AMI.

SAP workload migration with AWS SMS

Now that we’ve discussed the replication process, let’s talk about how you can use AWS SMS to migrate your virtualized SAP environment to the AWS Cloud.

There are two migration options: lift-and-shift, or migration to SAP HANA.

Notes

  • While we recommend considering AWS SMS as an option for migrating virtualized SAP workloads to the AWS Cloud, AWS SMS is not supported by SAP.
  • When you plan your migration, be sure to consider the operating system/database combinations that are supported for SAP applications on the AWS Cloud (details are in SAP Note 1656099).

Lift-and-shift migration

In this scenario, you can migrate your virtualized SAP environment running on Windows, Red Hat Linux, SUSE Linux, or Oracle Linux to the AWS Cloud as is, without any changes in the operating system or database. The process consists of these steps:

  1. Schedule the replication job at regular intervals for the virtual machines containing the database and non-database applications (ASCS/SCS, PAS, and AAS), or non-SAP NetWeaver-based applications (like BusinessObjects BI). We recommend intervals of 12 hours for the database and 24 to 48 hours for non-database virtual machines.
  2. Complete the first execution of the replication job. You should schedule this job in advance because it’s an initial and full replication, and will take some time to complete. The execution time will depend on the size of your virtual machines.
  3. Monitor the replication job for successful completion of incremental runs (we recommend at least two runs) and take note of the time it takes to complete each successive replication job. This will give you an estimate of the downtime required for final cutover.We recommend completing at least two incremental runs because it takes much less time to complete subsequent jobs after the initial, full replication, since subsequent runs involve only delta changes. For example, in the replication shown in the following illustration, full replication took around 8 hours, and then delta runs completed in around 1.5 hours.

    Figure 4: Reduced execution time after initial replication

    Figure 4: Reduced execution time after initial replication

  4. Plan for the final cutover. For the cutover, you’ll stop production operations on premises (for example, you’ll stop your SAP applications) and you’ll execute the replication job one last time to migrate delta changes to the AWS Cloud. We also recommend staging a mock cutover before the final cutover.
  5. Build an EC2 instance from the AMI created by the last replication job.
  6. Complete post-migration steps such as updating the DNS (or hosts file), validation, and integration.
  7. Go live.

Figure 5 illustrates the replication process.

Figure 5: Steps to replicate SAP workloads (as is) to the AWS Cloud

Figure 5: Steps to replicate SAP workloads (as is) to the AWS Cloud

Migration to SAP HANA

If you aren’t running SAP HANA on premises and would like to migrate to the AWS Cloud with SAP HANA, you can reduce your downtime significantly with AWS SMS by following this two-step approach:

  1. Migrate your virtual machines running on Windows, Red Hat Linux, SUSE Linux, or Oracle Linux to AWS as is, by following the process outlined for lift-and-shift migration.
  2. Migrate to SAP HANA on AWS. If you are already running your SAP applications on AWS, your migration to SAP HANA will be significantly faster, even for large databases, because both your source and target SAP systems will be on AWS.
    • You are no longer constrained by the availability of resources to optimize the export and import process.
    • You can use the SAP database migration option (DMO) to perform Unicode conversion, upgrade, and migration in a single step. For details, see the DMO article published previously on this blog.

In this blog post, I’ve discussed how you can use AWS SMS to migrate your SAP workloads to the AWS Cloud easily, and reduce the downtime required for migration.

You can use AWS promotional credits to migrate your SAP systems to AWS. Contact us to find out how and to apply for credits.