Moving SAP systems to AWS

Customer profile.

Utility company in Czech republic, which is the part of Europe-wide organization that offers a comprehensive portfolio of products and services spanning all stages of the energy value chain.


As part of datacenter decommision project, also most business critical SAP applications SAP ECC and SAP CRM, had to be migrated to cloud Amazon Web Services. These systems are closely coupled and most business processes require both systems to be together on low latency network so user experience is as smooth as possible. So systems had to be migrated in parallel. As operations are running in 24×7 mode downtime for these system migrations had to be minimized. Size of systems was at the time of migration about 15TB with Oracle Advanced Compression in total. Due to these constrains clasical SAP approach to export/import databases was not feasible. To achieve reasonable downtime and parallel migration combination of Oracle Dataguard and AWS Snowball service was used see in picture below.

Decision process

In preparation step for the migration whole infrastructure in AWS was preinstalled. Primary and secondary DB servers and six application servers per each SAP system. In this setup target solution is available across two availability zones and so high SLA for systems was preserved as source systems were clustered with HA software in two data center locations as well. Source and target databases were matched in terms of operation system and database software version. Source server sizing was adapted to match 90% of designed EC2 instances CPU and RAM so even before migration we could estimate future system behaviour and performance characteristics and also compare performance characteristics after migration. ECC and CRM systems are connected to 60+ external systems so all these interfaces were described and measured to mitigate timely reconfiguration activities after migration and network bottlenecks. All interfaces were also tested in AWS to prepare needed firewall rules on internal and external firewalls as direct connection to external parties from AWS infrastructure had to be adopted to prevent communication loopbacking through on-premise infrastructure.

Implementation and migration

At the beginning of the migration two copies of each database were performed to Snowball device (30TB in total) and shipped to AWS location. Simultaneously compressed database redo logs were transferred to target database servers over network. After delivery of Snowball data to S3 standby DB was created in AWS (future primary DB in AWS). Second standby in AWS can be configured as well. At this time source DB had primary DB role in Dataguard configuration and was operational without any service disruption. Although prepared earlier offline phase of migration was started two weeks after copying DB to Snowball to meet specific maintenance window. Offline phase consisted of four simple steps. At first source SAP application servers were stopped to prevent further database changes and to have database data in consistent state from application point of view. Second was to perform switchover to AWS DB standby where network throughput assured almost real time replication to standby DB. Third was to start SAP application in AWS environment and last was to reconfigure interfaces which were not possible to be done in advance. As Dataguard is still operational at this point even after productive use migration fallback can be performed without any data loss and in timely manner.


The migration approach has enabled the following:

  • Dramatically reducing downtime of overall migration – from days to hours
  • Specifying exactly maintenance windows for business services