AWS Partner Network (APN) Blog

Simplifying SAP Heterogeneous Migrations with Wipro and AWS

By Venkat Tatavarthy, Sr. Partner Solutions Architect – AWS
By Sourabh Chordiya, Cloud SAP Architect – Wipro

Connect with Wipro-1

Many SAP customers are keen to utilize the benefits of cloud computing and move to a future-ready platform that enables them to innovate rapidly.

Wipro has helped multiple SAP customers seeking to move their SAP applications to Amazon Web Services (AWS) to achieve agility, innovation at high speed, and improved resilience.

These customers wanted to eliminate the management overhead of on-premises hardware refreshes and warranty support complexities, and to minimize business downtime windows as much as possible during the migration.

For such migrations, Wipro FullStride Cloud Services is leveraged and incorporates the company’s SAP Safe Passage Framework and helps customers assess, migrate, and seamlessly transition to operations on the cloud. Wipro has extensive experience of delivering cloud transformation projects across the globe.

Wipro is an AWS Premier Tier Services Partner with nine AWS Competencies, including SAP Consulting, Industrial Software Consulting, and Data and Analytics Consulting. Wipro is also a member of the AWS Managed Services Provider (MSP) and Well-Architected Partner Programs.

Solution Overview

Few customers run their SAP ECC 6.0 system on premises, within Oracle database and with underlying Big-Endian platforms such as HP-UX. As part of migrating their SAP systems to AWS on the x86 Little-Endian platform, customers include the Oracle database version upgrade. They also need to change the operating system (OS) to Oracle Enterprise Linux because of support requirements.

Customers’ database size is often larger than 15TB and have stringent downtime requirements for migrations such as this. As a result, customers plan to minimize the technical downtime and usually plan to complete it within eight hours.

Let’s look at a migration solution that executes complex SAP migrations with short downtime requirements. Technical downtime for SAP migrations can include a database’s final incremental backup execution, transfer, restore and recovery, and also database metadata backup and restore.

In one such migration, Wipro utilized Oracle’s xTTS method, which provides a mechanism to transport the tablespace between platforms of different endianness. This also reduces downtime by avoiding the need for R3load based export/import process. A traditional R3load approach could have exceeded 24 hours as all the data is transferred during downtime.

On AWS, the Amazon Elastic Compute Cloud (Amazon EC2) c6a.16xlarge instance type with an 91633 SAPS rating is used for Oracle DB to meet the sizing requirements of the source system. Two such EC2 instances are deployed to provide Oracle high availability.

For SAP application servers, the r5b.4xlarge EC2 instance type with a 23128 SAPS rating is used to meet the application server sizing on premises. Eight application servers were deployed, and an additional Network Load Balancer (NLB) was deployed to provide a single point of entry for remote calls.

The following table shows a comparison of approaches with pros and cons for customers to evaluate.

Migration Approach – Options Pros Cons
Option 1: DB dependent method
Using Oracle xTTS method (Oracle RMAN xTTS migration method will be used for migration to Oracle 19c on Oracle Linux)
  • Minimal downtime
  • Minimal impact to source during cutover
  • Since DB dependent method, SAP support will be limited
  • No visibility around the progress of incremental restores using xTTS until completion
  • Leverage Oracle commands to monitor the progress
Option 2: DB independent method
Using SAP R3load method (with SWPM R3load, complete DB export/import will be performed)
  • SAP recommended method
  • No manual intervention
  • Perform parallel export/import
  • More downtime
  • SAP migration expertise for downtime optimization required for table and package splitting

Below are the high-level steps involved in the Oracle xTTS migration approach:

  • Perform pre-migration uptime activities, including basis tables clean-up, interface reconfiguration-related pre-tasks, downtime planning, and server readiness.
  • Perform a full backup (L0) on source database a couple of weeks prior to cutover; this happens as an uptime activity.
  • Transfer the full backup to target EC2 instance using AWS Snowball, and ensure all incremental backups are preserved post this full backup.
  • Perform an incremental backup close to the downtime but before the start of downtime; transfer this incremental backup to target EC2 instance to minimize downtime.
  • Perform activities to prepare system for downtime, including processing of message queues, processing of pending updates, and customer-specific configuration backups; transfer of customer filesystem contents.
  • During the downtime, SAP application servers are stopped; after Oracle listener is stopped, perform final incremental backup.
  • Perform export of Oracle metadata.
  • Perform final recovery and import of metadata on EC2 instance where Oracle database is installed.
  • Start SAP application servers on AWS; the application servers shall be installed in advance to minimize downtime.
  • Copy custom configuration and custom filesystems from on premises to AWS.
  • Perform post-migration activities including reconfiguration of interfaces, logon groups, SAP Logon Pad changes, and URL changes.

This migration approach requires a stable connectivity between source and target, which is set up using AWS Direct Connect. The transfer of initial full backup (L0) using AWS SnowBall device helps to reduce the overall migration downtime because the bulk of data is transferred in advance during normal production operations.

The full backup needs to be transferred from Snowball to Amazon Simple Storage Service (Amazon S3), which takes about 24 hours for a backup of 18TB database. As this is an uptime activity, however, there is no impact on downtime.


Below is the architecture implemented on AWS for the SAP systems after migration. This architecture follows SAP and AWS best practices and provides high availability for SAP. Several AWS services were leveraged to set up the target architecture.


Figure 1 – Usage of AWS services to set up the target environment.

The architecture leverages two AWS Availability Zones (AZs) in an AWS region to provision primary and secondary Oracle database instances. Oracle Data Guard is used to set up synchronous data replication between the two database instances. An SAP central services instance and SAP enqueue replication server are also set up across two AZs to replicate the enqueue lock table.

In addition, other AWS services such as Amazon Elastic Block Store (Amazon EBS), Amazon Elastic File System (Amazon EFS), Network Load Balancer, and Amazon Route 53 are leveraged to protect the single points of failure and provide resilience at every level of the SAP environment. An overlay IP address is used to route the network traffic to the SAP ASCS instance at all times, with the help of a routing table.

Common Challenges and Mitigation Strategies

One of the key challenges with the Oracle xTTS method is that there is no visibility to the migration status, unlike a backup/restore or R3load based migration. Hence, it’s necessary to perform multiple mock runs and identify the precise downtime duration.

Wipro recommends performing at least three mock runs and to identify the optimal duration for downtime in your migration plan. This reduces any impact on system availability due to unforeseen issues with xTTS during production cutover.

Here are other common challenges and ways to mitigate them during SAP migrations:

  • It’s not uncommon to see that automated application discovery tools can’t be used at a customer’s on-premises environment due to limitations with operating system (OS) or infrastructure setup. In the absence of an automated tool, Wipro’s Safe Passage Framework helps perform discovery and remediate interfaces with no business disruption.
  • For large customers, there could be several interfaces for which integration with SAP systems needs to be adjusted after migration to AWS. These can span multiple technologies and geographical regions, and the migration activities need precise planning and execution. Wipro has experience executing such complex migrations with hundreds of integrations and has ensured migrations and coordination go smoothly.
  • Non-SAP applications hosted on premises such as radio frequency (RF) consoles and third-party applications which are tightly integrated with SAP systems need to be migrated to AWS along with SAP. Wipro leverages AWS Application Migration Service (CloudEndure) to migrate non-SAP applications, and this integrated approach provides end users a seamless experience.
  • Issues with Oracle xTTS script could be encountered for a given OS platform. In a past migration, Wipro encountered problems with Oracle xTTS script for HP-UX to Linux conversion. Due to a large number of data files, the restore of multiple incremental backups were failing. Such issues require strong database management skills and close coordination with Oracle support. Wipro resolved these technical issues by utilizing the latest version of conversion script as part of xTTS process.
  • Issues with metadata import at target database are not uncommon. These issues need to be resolved with Oracle support and by creating an Oracle case as needed. Oracle scripts for this import are DB version-specific. For example, script v0.4 is only supported from Oracle 12 onwards, and version v0.3 needs to be used for prior DB versions.
  • Evaluate the source database version. If a DB version upgrade is needed, this needs to be executed on premises before migrating the database. This two-step approach requires understanding of the dependencies and needs meticulous planning.

For another SAP migration to AWS, Wipro’s post go-live statistics indicated an improvement in the overall performance in spite of higher load on the system after go-live due to the processing of various documents. The response time showed 2x improvement when compared with the same activity for previous months.

This migration solution stabilized the landscape, brought the OS and database up to date, and provided the flexibility offered by AWS to eliminate the need for hardware refresh cycles every few years for the customer.


Figure 2 – Response time comparison before and after migration to AWS.


Wipro leverages its proven SAP Safe Passage Framework to seamlessly migrate customers’ SAP systems to AWS without any business interruptions.

SAP migrations that have complex technical requirements and challenges such as changes in operating system platform, huge database size, and hundreds of interfaces are efficiently handled by Wipro’s expert SAP team. By migrating customers’ SAP systems to AWS, Wipro delivers better performing systems.

Learn more about Wipro’s FullStride Cloud Services and leading cloud capabilities and services. Contact Wipro to learn how it can fast-track your business transformation journey on AWS.


Wipro – AWS Partner Spotlight

Wipro is an AWS Premier Tier Services Partner and MSP that harnesses the power of cognitive computing, hyper-automation, robotics, cloud, analytics, and emerging technologies to help clients adapt to the digital world.

Contact Wipro | Partner Overview