If you move an SAP system to the cloud without understanding how to shift its operating system and applications, you risk breaking the connection between the database and the application servers — effectively shutting down your company’s entire business operations. This chapter explains how to safely move an SAP application and its underlying operating system from one server to another on AWS, using processes like system copy and export/import. For the PAS-C01 exam, you need to know exactly which tools and steps are used to do this without corrupting data or causing downtime.
Jump to a section
A simple way to picture OS and Application Migration for SAP
Standing in the middle of your old flat, surrounded by boxes labelled ‘kitchen’ and ‘bedroom’. You are moving to a new house across town. The plan is to get everything from the old place, with all its furniture, appliances, and the exact smell of your grandmother’s recipe books, into the new house so it feels exactly the same.
First, you decide to move the big furniture. The sofa, the bed, the dining table — these are your ‘application servers’. They hold the main activity: you sit on the sofa to watch TV, you eat at the table. But before you can move the sofa, you realise the new house has a different door width. The operating system (OS) — like the floor plan of the old house — doesn’t fit the new house’s structure perfectly. You cannot just drag the sofa across town; you must take it apart, label the pieces, and reassemble it in the new house with possibly a different layout. That is the ‘OS migration’ bit — you are changing the floor plan underneath the furniture.
Next, you need to move all the smaller stuff: the books, the cutlery, the photo albums. These are your ‘application files’ and database. You pack them into boxes (export), ship them (data transfer), and unpack them in the new rooms (import). Some items, like that fragile vase, need special handling: you back them up separately. The entire process — packing, moving, unpacking — is a ‘system copy’. You are not buying new furniture; you are recreating the old house’s feel in a new structure. If you skip labelling the boxes, you end up with pots in the bedroom. In IT, that means broken connections between servers and data. The whole move takes planning, a checklist, and a test run — otherwise you arrive at the new house with no way to cook dinner.
When you run SAP software on a physical computer in an office, that computer has an operating system — usually Windows or a version of Linux like SUSE or Red Hat. The operating system (OS) is the layer that manages hardware resources such as memory (RAM), processing power (CPU), and storage (hard drives). The SAP application — for example, SAP ERP or SAP S/4HANA — sits on top of the OS. It uses the OS to talk to the hardware and to the database (the structured collection of data, like all customer invoices).
Now imagine you want to move this entire setup to AWS, which is a cloud provider. AWS lets you create virtual servers called EC2 instances. An EC2 instance is a virtual computer that runs inside Amazon’s data centre. You can choose which OS runs on it. The challenge is moving the SAP application and its data from your old server to a new EC2 instance without losing anything or causing errors.
This move is called ‘migration’. There are two main parts: OS migration and application migration.
OS migration means changing the underlying operating system — for example, moving from a Windows physical server to a Linux EC2 instance. Or staying on the same OS but on a different version (for example, Windows Server 2016 to Windows Server 2022). Why would you do this? Because AWS might offer better performance or lower cost for a specific OS, or because the old OS is no longer supported (out of date and vulnerable to security issues).
Application migration means moving the SAP software itself — the programs, the configurations, the connections to the database. A key method is ‘system copy’. A system copy is exactly what it sounds like: you create an exact duplicate of your SAP system (application code, user data, settings) on a different server. You might use a tool called SAP Software Provisioning Manager (SWPM) or a database-specific tool like SAP HANA Studio. During a system copy, you first export the data from the source system (the old server) into a set of files. Then you import those files into the target system (the new EC2 instance). This is called export/import.
Why not just copy the files directly? Because SAP systems are complex — they have hundreds of linked components. If you just copy the hard drive of the old server to the new one, the SAP software may not recognise the new hardware or the new OS. The system copy process includes steps to adjust configurations, update server names, and fix network settings so the application works correctly in its new environment.
There are several tools AWS provides to help with this:
AWS Application Migration Service (AWS MGN): This tool automates the process of replicating your on-premises servers (including the OS, applications, and data) to AWS. It continually syncs changes until you are ready to switch over.
AWS Server Migration Service (SMS): An older tool that works for virtual machines. It can migrate entire servers, including the OS and apps, to EC2.
AWS Database Migration Service (AWS DMS): If you are only moving the database component (for example, SAP HANA), this tool can handle the export/import of database schemas.
For the OS and application migration, the critical steps are:
Assess your current environment. Document the OS version, SAP version, database type, and all customisations.
Choose a target EC2 instance type (for example, m5.large or r5.xlarge) that has enough CPU and memory for your SAP workload.
Prepare the target EC2 instance. Install the OS (usually a supported SAP version of Linux or Windows).
Install the SAP application software on the target, leaving it unconfigured (like an empty house).
Perform a system copy using export/import. You run a tool on the source system that exports the SAP configuration and data into transport files. Then you run the import on the target system.
Test everything. Verify that users can log in, transactions work, and reports run correctly.
Why does this matter for the PAS-C01 exam? Because the exam tests your knowledge of which tool to use for each scenario, the order of operations, and how to handle errors like export failures or incompatible OS versions. You will get exam questions that describe a company moving SAP to AWS and ask you to choose the correct sequence of actions or the right tool.
Assess the Current Environment
Document the source server’s operating system version, SAP release, database type and version, list of custom programs, and network configuration. This tells you whether the migration will be homogeneous or heterogeneous, and which tools to use.
Select the Target EC2 Instance and OS
Choose an Amazon EC2 instance type that meets the workload requirements (CPU, memory, storage). Launch the instance with the target OS (e.g., SUSE Linux for SAP). Install all required SAP kernel patches and libraries.
Prepare the Target System with SAP Software
Install the SAP application software on the target EC2 instance using SWPM, but do not configure it yet. This is like setting up the empty building before moving the furniture in.
Export Data from the Source System
Use R3load (for database export) and SWPM to extract the SAP system configuration and data into transport files. Store these files in a location accessible from both servers, such as Amazon S3 via AWS DataSync.
Import Data into the Target System
Run the import process on the target EC2 instance using R3load and SWPM. This loads the exported data into the new database and SAP application. Adjust hostnames, IP addresses, and system IDs (SIDs) as needed.
Perform Post-Migration Validation
Test all critical business transactions, check user access, verify background jobs run correctly, and confirm that external connections (e.g., to banks or tax authorities) work. Fix any errors before proceeding to cutover.
Cutover to the New System
Stop the old server, point DNS to the new EC2 instance, and monitor for issues. During cutover, the system experiences downtime — it is the moment when users can no longer use the old system and must use the new one.
A mid-sized manufacturing company, EuroParts Ltd, runs SAP ECC 6.0 on a physical server in their Frankfurt office. The OS is Windows Server 2012 R2, which is about to go out of support. The company wants to move to AWS to save on hardware costs and improve reliability. They decide to migrate to a Linux-based EC2 instance running SUSE Linux Enterprise Server for SAP Applications.
Here is what the IT team actually does:
First, they take an inventory. They list every SAP component: the central instance (manages logins and background jobs), the database instance (holds all business data on an IBM Db2 database), and the dialog instances (handle user requests). They also note any custom ABAP programs (custom code written in SAP’s programming language).
Second, they choose the migration strategy. They decide on a ‘heterogeneous system copy’ because the OS is changing from Windows to Linux. This means the entire SAP system — including the database — must be exported and reimported because the database format works differently across operating systems. They use SAP’s Software Provisioning Manager (SWPM) and the database-specific export tool called R3load.
Third, they set up the target environment on AWS. They launch an EC2 instance with SUSE Linux from the AWS Marketplace (a pre-built image with the right OS version). They attach Amazon Elastic Block Store (EBS) volumes for storage. They install SAP kernel files and the required libraries.
Fourth, they run the export. On the old Windows server, they run R3load to extract the database tables into compressed files. This process takes 10 hours because the database is 500 GB. They transfer these files to an Amazon S3 bucket (cloud storage) using AWS DataSync, which accelerates the transfer by compressing data and using multiple network connections.
Fifth, they run the import. On the new Linux EC2 instance, they run R3load again, this time loading the exported files into the new IBM Db2 database. This step also takes hours.
Sixth, they perform post-migration tasks. They run SAP’s ‘SAP System Copy and Provisioning’ checklist, which includes checking that all user IDs, authorisation roles, and customisation settings match. They test a sample transaction — creating a new purchase order — to confirm it works end to end.
Finally, they cut over. They stop the old server, redirect network traffic to the new EC2 instance using DNS (Domain Name System, which translates a website name to an IP address), and monitor for errors. The entire migration took two months of planning and three days of actual data transfer.
The key lesson from this real-world case: the export/import step is the most error-prone. If the team forgets to set the correct characterset (encoding for special characters like ä, ö, ü), the data will appear corrupted. The exam loves to test these details — for instance, asking which tool to use for a heterogeneous migration, or what to do if the export fails due to space issues.
The PAS-C01 exam tests Domain 1.4 heavily. Expect 8–12 questions on OS and application migration across the entire exam. Here is exactly what they test and how they trap you.
Key concepts they love:
System copy types: Homogeneous (same OS, same database type) versus heterogeneous (different OS or different database). You must know which tools are used for each.
Export/import tools: SAP’s Software Provisioning Manager (SWPM) is the central tool. R3load is used for database export/import. AWS Application Migration Service (MGN) is used for “lift and shift” (moving the entire server as-is without changing the OS).
AWS services: EC2 instance types suitable for SAP (e.g., m5, r5, x1e). AWS DMS is only for database migration, not full system copy.
Common trap patterns:
Trap: The question describes a company that wants to change OS (e.g., from Windows to Linux) but also keep the same database type. Many candidates incorrectly pick AWS MGN because it is simpler. Correct answer: Use a heterogeneous system copy with SWPM and R3load, because MGN does not change the OS — it replicates the source server exactly.
Trap: The scenario involves a very large database (>1 TB). Candidates choose to export to a local drive. Correct answer: Use direct export to network storage (e.g., Amazon S3 with AWS DataSync) to avoid disk space issues.
Trap: The question asks for the “fastest” method to migrate. Options include system copy with downtime and a zero-downtime tool like SAP Landscape Transformation (SLT). The correct answer often depends on whether the system can be offline. The exam wants you to recognise that system copy typically requires downtime.
Exam question types:
Multiple choice: “Which AWS service is best suited for migrating an SAP application server to AWS without changing the OS?” Answer: AWS Application Migration Service (MGN).
Multiple response: “Which of the following are required for a heterogeneous system copy? (Choose two.)” Options: SWPM, R3load, AWS CloudFormation, AWS DMS. Correct: SWPM and R3load.
Scenario-based: “A company wants to migrate SAP ERP to AWS but must reduce the size of the database by archiving old data. Which two processes should be combined?” Answer: Data archiving in the source system, then a system copy of the reduced dataset.
Key definitions to memorise:
Transport directory: A shared file system that stores SAP system copy export files. It must be accessible from both source and target servers.
ABAP Central Services (ASCS): The instance that manages locks and queues for an ABAP SAP system. During migration, its settings must be preserved.
Primary Application Server (PAS): The main SAP application instance. It is often migrated last after the database and central services.
The exam also tests the concept of “cutover” — the moment when you switch from the old system to the new. You must know that a successful cutover requires a full test of all interfaces (e.g., connections to external banks, suppliers, or government systems).
A system copy creates an exact duplicate of an SAP system on a new server, including all settings, users, and custom code.
Heterogeneous system copy is required when the target server has a different operating system or a different database type than the source.
AWS Application Migration Service (MGN) is only suitable for lift-and-shift migrations that preserve the exact same operating system.
The export/import process for SAP systems is performed using tools like SAP Software Provisioning Manager (SWPM) and R3load.
SAP systems require the hostname and IP address to be updated after a system copy, which is not handled by simply copying the hard drive.
A successful SAP migration must include testing of all interfaces (EDI, RFC connections) before cutting over users.
The transport directory must be shared between source and target servers during a system copy to store export files.
Database export files can be stored in Amazon S3 and transferred using AWS DataSync for large-scale migrations.
Cutover is the final step where all users switch from the old system to the new one, requiring thorough planning to minimise downtime.
Exam questions often test the difference between homogeneous and heterogeneous migrations, especially regarding tool selection.
These come up on the exam all the time. Here's how to tell them apart.
Homogeneous System Copy
Target has the same OS and database type as source.
Can often be completed with a simpler tool like SWPM without R3load.
Faster because binary database files may be directly transferable.
Heterogeneous System Copy
Target has a different OS or different database type.
Requires full export/import using R3load to convert data formats.
Takes longer and has higher risk of data incompatibility issues.
AWS Application Migration Service (MGN)
AWS-native tool that replicates the entire source server disk.
Best for lift-and-shift with the same OS.
Does not handle SAP-specific configuration like SID changes.
SAP Software Provisioning Manager (SWPM)
SAP’s own tool for installing and copying SAP systems.
Handles both homogeneous and heterogeneous migrations.
Requires manual steps for configuration updates after migration.
System Copy
Designed to move an SAP system to different hardware or OS.
Includes steps to adjust hostnames, SIDs, and network settings.
May include a data transformation step (e.g., R3load export).
Backup and Restore
Designed to recover the same system on the same hardware after failure.
Does not adjust hostnames or network settings.
Restoring onto different hardware often fails without reconfiguration.
Mistake
I can just copy the entire hard drive of the old server to a new EC2 instance and the SAP system will work.
Correct
SAP systems have hardcoded server names, hostnames, and hardware-specific configurations. A direct disk copy will likely break these settings, causing the SAP system to fail to start.
People assume servers are like USB drives — plug and play. But enterprise applications like SAP are tightly coupled to their environment.
Mistake
AWS Application Migration Service (MGN) works perfectly for any SAP migration because it automates the whole process.
Correct
MGN creates an exact replica including the OS. If you are changing the OS (e.g., Windows to Linux), MGN cannot help because it replicates the source OS. You need a heterogeneous system copy instead.
Cloud providers market their tools as ‘simple one-click solutions’, leading beginners to believe they cover all scenarios.
Mistake
A system copy and a backup are the same thing — I can restore a backup on a new server and it functions as a migration.
Correct
A backup is a point-in-time snapshot for disaster recovery. A system copy includes additional steps to adjust to new hardware, update hostnames, and reconfigure connections. Restoring a backup onto a different server often fails without these adjustments.
The terminology ‘copy’ and ‘backup’ are used interchangeably in everyday speech, but in SAP they have distinct technical meanings.
Mistake
Heterogeneous system copy and homogeneous system copy use exactly the same tools.
Correct
A homogeneous copy can often be done with simpler tools like SAP SWPM using a ‘system copy’ option, while a heterogeneous copy requires R3load to export/import database tables because the database binary files are incompatible between OS platforms.
Beginners think ‘SAP’ is a single monolith, not recognising that database engines (like Db2, Oracle, HANA) behave differently across operating systems.
Mistake
I can migrate the SAP application without touching the database — just move the application servers first.
Correct
The application servers depend on the database for all data. If the database stays on the old server, the new application servers cannot connect to it after migration unless the network routes are updated. Migration projects typically move the database first or simultaneously.
People visualise IT systems as independent boxes, but SAP has a tightly coupled three-tier architecture (database, central services, application).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A homogeneous system copy moves an SAP system to a target with the same operating system and database type (e.g., Windows to Windows). A heterogeneous copy involves a change in OS or database (e.g., Windows to Linux), requiring full export and import of data using R3load.
Yes, but only if you want to keep the exact same operating system (lift-and-shift). If you plan to switch OS, you must use a heterogeneous system copy with SAP’s own tools instead of MGN.
Yes, typically you must stop the SAP system and the database to export the data consistently. This downtime is required to ensure no new transactions are written during the export. The duration depends on database size.
The main tool is R3load for the database layer, combined with SAP Software Provisioning Manager (SWPM) for the overall system copy process.
AWS DMS is used for database migrations only, not for migrating the full SAP application (code, user settings, customisations). For a full system copy, you need SAP-specific tools like SWPM.
Custom ABAP programs are included in the export if they are in the source system’s transport repository. During import, they are transferred to the target system. You must verify they compile correctly after the migration.
You've finished OS and Application Migration for SAP. Continue through the PAS-C01 study guide to build a complete picture of the exam.
Done with this chapter?