The Easiest Migration to SAP on AWS

In 16 years we've been leading SAP OS/DB Migrations globally, whether heterogeneous or homogeneous migrations, they are normally time-consuming and risky.  Today, we'll mention one type of migration that is relatively simple and that is VMWare migration to SAP on AWS.  Check out our recent post for reasons customers would run SAP on AWS.

UPDATE Dec 2017: We tested an even easier and more universal migration solution

SAP VMWare Migration to AWS

There are several use cases for the migration of SAP on VMWare virtual machines to AWS:

• Moving SAP infrastructure costs from CapEx to OpEx
• Running out of capacity with your VMWare SAP systems on-premise
• Need to upgrade the performance of existing SAP systems
• Technology refresh needed to support SAP functional and/or basis upgrades
• Disaster Recovery strategy for warm or hot standby systems
• Divestiture and splitting off SAP systems to new businesses

Figure 1: SAP on AWS Roadmap

Migration Scenario

AWS supports the 'lift and shift' of VMWare ESX or vCenter virtual machines to the cloud via a process known as VM Import/Export.  Per AWS, "You can import Windows and Linux VMs that use VMware ESX or Workstation, Microsoft Hyper-V, and Citrix Xen virtualization formats".  

• SAP on Windows: AWS runs Windows servers (license included) from 2003 to the latest, so if you have SAP on Windows with any supported DB platform, and do not wish or have the ability to re-install SAP software, this is a perfect case to use the VM Import/Export migration.
• SAP on Linux: Similar to Windows, any SAP-supported Linux platform running on a VM can be exported and imported with some flexibility in reconfiguring the resources such as CPU, Memory, Storage, and Network on AWS.

Migration Process

Refer to the SAP on AWS FAQ, OSS Note 1656099 - SAP on AWS Supported Platforms, and SAP on AWS Implementation Guide for general best practices recommendations for Planning, Implementation, and Operations.  Even though the SAP migration process using VM Import/Export is relatively simple compared to other SAP migrations, we recommend resources with AWS Certifications to guide through the process to avoid potential issues, some of which we deal with in this article.

The overview below was developed after successfully migrating 2 SAP systems to AWS demonstrating support for a really old system and fairly current system: (1) ERP 4.7 on Windows 2003 / Oracle 9i.  (2) Solution Manager 7.1 on Windows 2008 R2 / SQL Server 2012.  Linux-based systems should be even easier to migrate.

Plan

• Review SAP on AWS Supported Platforms as mentioned above.
• Review the prerequisites, see VM Import/Export Prerequisites.
• Plan the downtime of the source SAP system, which depends on the VMWare infrastructure and storage export speed.  If this is just a copy, the source can be available after the export completes, otherwise, for migration, the transfer, import and post-migration check time needs to be factored in.
• Provision export space accessible from the VMWare vSphere Client or vCenter.
• AWS VPC (Virtual Private Cloud) preparation, security, and AWS CLI (Command-Line Interface) instance for executing the import
• Create a VM Import Service Role to allow a logged-in account on AWS CLI EC2 instance to perform VM import, see the prerequisites link above.
• AWS Storage and connectivity: VM Import requires the use of AWS S3 (Simple Storage).  Transfer of file to S3 can be directly or via S3 copy from a regular filesystem on AWS EC2 instance.  We prefer the latter and will discuss more below.

Prepare

• Disable any antivirus or intrusion detection software on your VM. These services can be re-enabled after the import process is complete.
• Uninstall the VMware Tools from your VMware VM.  You may have to restart your VM to completely uninstall.
• Disconnect any CD-ROM drives (virtual or physical).
• Change <sid>adm to local user SAP Local and Global Admin group if it’s currently a Domain User unless the same domain is available and set up for authentication at AWS.  Make sure you check by logging in.  Add it to the local Administrators group too for convenience, you can remove it from the target at AWS later once you can verify the system runs OK.
• Set your network to DHCP instead of a static IP address. If you want to assign a static private IP address, be sure to use a non-reserved private IP address in your VPC subnet. Amazon Virtual Private Cloud (Amazon VPC) reserves the first four private IP addresses in a VPC subnet.
• Activate Firewall and check exclusion to allow RDP and other required SAP ports.
• Update .NET Framework to at least 3.5.
• Edit and remove entries or the whole host file to avoid obsolete host/IP references.
• Shut down your VM before exporting it from your VMWare environment.

Perform

• Export a Single File (OVA) of Your VM.  This assumes your VM uses multiple virtual hard-disk, possibly including mapped iSCSI or other network storage, which will be included in the OVA export.  Using vSphere:
  • Name your OVA
  • Pick Export Directory
  • Export - This will take hours depending on how many, what size each of the virtual HD drives are, and the storage throughput.

• Transfer
  • Method 1: Upload an image to S3 directly using the AWS S3 web interface.  Multi-part upload is also possible but you need to split the image first and then use AWS S3 multi-part upload CLI
  • Method 2: SFTP to EC2 instance (such as CLI) with filesystem large enough, then from AWS CLI instance copy to S3 bucket (e.g. AWS s3 cp ./<.ova file> s3://<bucket>/<.ova file>

• Import using AWS CLI instance
  • In the working directory, maintain the meta file containers.json which describes the image and its location
  • Run the import from S3 to create an EC2 image: e.g. AWS ec2 import-image --description "Name of the image" --disk-containers file://containers.json
  • Monitor the progress: AWS ec2 describe-import-image-tasks
    • Until the importimageTask section contains "Status": "completed"
• Launch
  
  • Using EC2 Dashboard, the new image should be available under IMAGES where you can select, launch:
    • Select EC2 instance type (sized by vCPU, RAM, Network, etc.)
    • Configure storage size for the virtual disks that were imported: they can be sized up if you want larger-sized disks to be available to the OS, this is extremely useful for systems that were storage strapped on the source and need larger storage on AWS
    • Select Network, subnet, whether to assign a public IP address
    • Assign IAM (Identity Access Management) role, and Security Group (AWS equivalent of the host-based firewall) to allow appropriate OS, DB, and SAP ports inbound
  • Create or choose existing security key pair to allow OS-level access to the SAP host via RDP or SSH
  • Start SAP: Logon to the host and start SAP using sapcontrol, sapstart, or startsap.  If you want to configure autostart, you will need to maintain either the SAP profile 'autostart' parameter

Perfect IT: Migration Lessons Learned

• Direct S3 transfers of large image files (> 20GB) were often unreliable and failed several times and had to be restarted from the beginning.  AWS does have a more complex method using S3 multi-part upload, as well as the recent announcement of S3 transfer acceleration, which costs extra.  We preferred to use SFTP to an EC2 CLI instance with the mounted filesystem, then copy to S3 within AWS.  With this method, we were able to load a 110 GB export file in 4 hours from an EC2 t2.micro instance with general-purpose GP2 EBS storage to S3, following the SFTP that just depended on your upload speed.
• The VM import does not produce very useful error logs when preparing the import, converting the virtual disk, and creating the target image, so this process has to be monitored closely with scripts.
• Cleanup of the source system's storage such as filesystems, Recycle bin, etc. will help the image export time and size.
• VPN or AWS DirectConnect configuration from co-location to AWS will help with the process as well as post-migration access.
• Performance tests and baselines before and after migration are useful to compare and configure the target AWS environment optimally and economically.
• Domain and DNS integration is useful if the same hostnames are planned to be retained, otherwise, plan for a hostname change on the target including an adaptation of SAP profiles and scripts.
• SAP Monitoring of the target environment needs to be planned beforehand so that normal operations can be resumed soon after migration.  Don't necessarily count on your existing on-premise solutions to work seamlessly or suitability for your new cloud-based SAP system.

Advanced Migrations

This is just for starters to whet your appetites, many more migration opportunities exist and solutions that can bring all types and sizes of SAP systems to AWS, and we'll cover those in the future as well.  These include:

• Full storage replication for SAP migration to AWS with technologies such as CloudEndure
• AWS Import/Export Snowball for large SAP VM export (typically recommended for > 1 TB export)
• VMWare vCenter: AWS Management Portal and the AWS Connector for vCenter
• SAP SPWM or SUM upgrade/migrations

For further details, please visit SAP Hosting on AWS.