IT-Conductor Blog

The Easiest Migration to SAP on AWS

Posted by Linh Nguyen on Jul 27, 2016 12:36:29 PM

 SAP on AWS Roadmap Services by OZSOFT & IT-Conductor

SAP Migrations are Rarely this Easy

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 which 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

Start an SAP on Cloud Proof of Concept

SAP VMWare Migration to AWS

There are several use cases for 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 performance of existing SAP systems
  • Technology refresh needed to support SAP functional and/or basis upgrades
  • Disaster Recovery strategy for warm or hot stand-by systems
  • Divestiture and splitting off SAP systems to new businesses

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 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.  Eventhough 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 of 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 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 VM Import Service Role to allow 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 regular filesystem on AWS EC2 instance.  We prefer the later 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 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 hosts file to avoid obsolete host/IP references.
  • Shut down your VM before exporting it from your VMWare environment.

Perform

  • Export 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
SAP on AWS VMWare Image Export
  • Transfer:
    • Method 1: Upload image to S3 directly using 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>
SAP on AWS Image Transfer to AWS S3 Bucket
  • Import: Using AWS CLI instance
    • In the working directory, maintain the meta file containers.json which describes the image and it's 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 needs larger storage on AWS
      • Select Network, subnet, whether to assign public IP address
      • Assign IAM (Identity Access Management) role, and Security Group (AWS equivalent of 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: 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 recent announcement of S3 transfer acceleration, which costs extra.  We preferred to use sftp to an EC2 CLI instance with mounted filesystem, then copy to S3 within AWS.  With this method we were able to load 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 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 test and baselines before and after migration are useful to compare and configure the target AWS environment optimally and economically
  • Domain and DNS integration are useful if the same hostnames are planned to be retained, otherwise plan for a hostname change on the target including adaptation of SAP profiles and scripts
  • SAP Monitoring of the target environment needs to be planned beforehand so the 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 wet your appetites, many more migration opportunities exist and solutions which can bring all types and sizes of SAP systems to AWS, and we'll cover those in the future as well.  These include:

For further details, please visit SAP Hosting on AWS 

Linh Nguyen

Written by Linh Nguyen

Linh was born in democratic Vietnam, escaped from the communist after the war as a boat-people refugee to Malaysia, subsequently immigrated to Australia where he attended high-school and completed dual-degrees in Computer Science & Computer Engineering in just 5 years. He started SAP career in Melbourne, then came to the US in the mid-1990s as a SAP technical consultant. He built a software and consulting company in Silicon Valley in 1996 named OZSoft and has been an entrepreneur with a passion to automate IT processes. In 2014, he started IT-Conductor, Inc. as CEO and co-founder along with David Stavisski, with the goal to help IT organizations to Stop Guessing and Start Managing by automating IT operations using a cloud-based platform IT-Conductor.

Topics: SAP on AWS

FREE IT-Conductor Trial to Monitor SAP

Posts by Topic

see all

Recent Posts

Subscribe to Email Updates