SAP Database Migration to AWS. This is the process of moving the data that powers your entire business — your sales, your inventory, your financial reports — from an old database system into a new one running on Amazon Web Services. If you are studying for PAS-C01, you need to know how to plan this move, what tools AWS gives you to do it safely, and the exact steps to avoid breaking your business while you do it.
Jump to a section
A simple way to picture SAP Database Migration to AWS
Your company is moving its entire chemistry lab from an old warehouse to a brand new, high-tech facility on the other side of town. The lab has 5000 delicate chemical compounds, each stored in its own specific container with a precise label. Some compounds are highly volatile and must be kept at a constant temperature. Others are inert but extremely heavy.
You cannot just pack everything into cardboard boxes and drive it across town. Many compounds would react, explode, or degrade. Instead, you hire a specialist moving team. They first take a complete inventory, mapping exactly where every compound sits on the old shelves. Then, they set up a temporary transfer station in the loading bay. For the most dangerous compounds, they use a special sealed transport system that keeps them moving continuously between identical containers, never stopping the chemical reaction. For the safer compounds, they use a tool that copies the molecular structure perfectly, then checks the copy against the original before destroying the original.
Meanwhile, the new lab must be ready and configured to receive each compound. The scientists on the other end must know exactly which shelf each compound belongs on, and the storage systems must be pre-tested to ensure they won't accidentally contaminate anything. The move cannot be rushed; if a compound spills, the entire lab could be compromised. The goal is to have the new lab fully operational, with every chemical in its correct place and no loss of data — I mean, no loss of chemical properties — within a specific deadline.
Every large company runs on data. That data lives inside databases — structured collections of information managed by software called a Database Management System (DBMS). For companies that use SAP software (the system that runs their accounting, supply chain, and HR), the database is the heart of the operation. A typical SAP database contains everything from customer orders to employee salaries. Migrating this database to the cloud — specifically to AWS — is like performing open-heart surgery while the patient (the business) is still awake.
Why would anyone do this? Companies move their SAP databases to AWS for several big reasons. First, they want to stop paying for expensive physical servers that sit in a dusty room under their office. Second, they want the ability to grow (or shrink) their database capacity instantly when needed — like during a holiday sales rush. Third, they want better disaster recovery: if their office floods, the database in the cloud is still safe.
The core challenge of database migration is maintaining data consistency. When you copy data from one database to another, you must ensure that every single piece of data arrives exactly as it was in the source, and that no data is lost or duplicated. During the move, the business often cannot just stop working — people are still entering orders, updating prices, and generating reports. The migration tool must capture those changes even while the copy is happening.
AWS provides several methods for migrating SAP databases. The most important for the PAS-C01 exam are:
AWS Database Migration Service (AWS DMS): This is a managed service that can migrate data between different database types. For example, you can move from an Oracle database to an SAP HANA database. DMS creates a 'replication instance' — a small computer in AWS that handles the copying. It reads the source database, transforms the data if needed, and writes it to the target database. DMS can also keep the target in sync with the source during the migration, allowing you to switch over with minimal downtime.
SAP HANA System Replication (HSR): This is a method specific to SAP HANA databases. HANA databases can be configured to automatically copy every change in real-time from one HANA system (the primary) to another (the secondary). You can use this to migrate by setting up a new HANA system on AWS, connecting it as a secondary replica, and then promoting it to primary when you are ready. HSR provides near-zero downtime because data is always flowing between the two systems.
SAP Software Provisioning Manager (SWPM) with SUM: This is SAP's own tool for migrating and upgrading systems. It handles the complex task of moving the entire SAP system — including the application layer — not just the database. This is often used for larger, more complicated migrations.
Homogeneous vs. Heterogeneous Migration: A homogeneous migration moves data between the same database engine (e.g., Oracle to Oracle). A heterogeneous migration moves data between different engines (e.g., Oracle to HANA). Different tools are suited for each. DMS can handle heterogeneous migrations. HSR only works between HANA systems.
The process always follows a similar pattern. First, you assess the existing database — how big is it, what type is it, what are its performance characteristics? Second, you plan the target environment on AWS, choosing the right instance type (the virtual server size) and storage. Third, you set up the network connectivity so the source and target can talk to each other. Fourth, you perform the data load — the actual copying of data. Fifth, you validate that the data is correct. Finally, you cutover — you stop the old system and start using the new one.
Key considerations during this process include: downtime (how long the system is unavailable), data integrity (making sure nothing gets corrupted), security (encrypting data in transit and at rest), and testing (simulating the migration to find problems before the real cutover). The PAS-C01 exam expects you to understand which tool fits which scenario, and the order of operations for a successful migration.
Assess the Source Database
Gather detailed information about the existing database: its type (Oracle, HANA, DB2), version, size (in terabytes), the number of tables, and any special configurations like partitioning or encryption. This determines which migration tools are compatible and how long the migration will take.
Design the Target Environment on AWS
Choose the right Amazon EC2 instance type and EBS storage for the new database. Consider performance requirements, high availability, and disaster recovery. For SAP HANA, you must use certified instance types listed in the SAP HANA Hardware Directory. This step also includes configuring the virtual network (VPC) and security groups.
Set Up Network Connectivity
Establish a secure, low-latency connection between the source data centre and the AWS target environment. This often involves setting up a VPN (Virtual Private Network) or AWS Direct Connect (a dedicated private line). Without this step, data cannot flow safely between the two systems.
Configure and Run the Migration Tool
Depending on the chosen method (e.g., AWS DMS, HSR), configure the source and target endpoints, set up replication tasks, and start the data load. For AWS DMS, this means creating a replication instance and defining the tables to migrate. For HSR, this means registering the target as a secondary replication site.
Perform Full Load and Ongoing Replication
Run the initial full load to copy all existing data. Once complete, enable ongoing replication (also called Change Data Capture or CDC) to keep the target synchronised with changes made on the source. This step can run for days or weeks, keeping the databases in sync until cutover.
Validate Data and Execute Cutover
Compare record counts and checksums (digital fingerprints of the data) between source and target to ensure completeness and accuracy. Then, stop all application activity on the source, let the replication catch up with final changes, stop the source, and redirect application connections to the target database. This is the moment of cutover.
Post-Migration Monitoring and Decommission
Monitor the new database for performance issues and data consistency. Keep the old system running for at least 30 days as a rollback option. After the monitoring period, decommission the old database and clean up any temporary resources like the DMS replication instance.
Imagine you are an SAP Basis consultant (the person who manages SAP infrastructure) working for a medium-sized retail company called 'NorthStar Goods'. NorthStar currently runs its SAP ERP system on an Oracle database that lives on physical servers in a rented data centre in Chicago. The company has decided to move everything to AWS to save costs and gain flexibility. Your job is to plan and execute the database migration.
You start by gathering facts. The current Oracle database is 2.5 TB in size. The company can only afford 4 hours of total downtime for the cutover — the moment they stop using the old system and start using the new one. The database type will stay the same: Oracle to Oracle. However, the company also wants to eventually move to SAP HANA in the future, but not yet.
Your first step is to set up the AWS target environment. You create a new Amazon EC2 instance (a virtual server in AWS) that will host the new Oracle database. You choose an instance type with enough CPU and memory to handle the expected workload. You configure the storage using Amazon EBS (Elastic Block Store) volumes — think of these as virtual hard drives. You ensure the new database is installed and configured with the same parameters as the old one.
Next, you handle connectivity. The old data centre in Chicago must be able to send data securely to your AWS Virtual Private Cloud (VPC) — your private network in the cloud. You set up a VPN (Virtual Private Network) connection that encrypts all traffic between the two locations. You also configure security groups (firewall rules) to allow only the necessary database traffic.
For the migration itself, you choose AWS DMS. You create a replication instance — a small EC2 instance that will do the copying. You then create a source endpoint (pointing to the old Oracle database) and a target endpoint (pointing to the new Oracle database). These endpoints tell DMS where to read from and where to write to. You then create a replication task: a set of instructions telling DMS which tables to copy and how.
You run the task in 'full load' mode first — this copies all existing data from the source to the target. This takes about 10 hours. During this time, the source database remains fully operational. After the full load completes, you set up 'ongoing replication' — DMS will now capture any new changes made to the source database (like new orders or updated prices) and apply them to the target. The databases are now nearly in sync.
On the day of the cutover, you stop all application activity on the source system — no one can enter new orders for about 10 minutes. You let DMS catch up with the final changes. You then stop the DMS task and point your SAP application servers to the new Oracle database on AWS. You run validation checks to ensure all data matches. Once validated, you open the system for business. The cutover is complete.
Throughout this process, you document everything: the size of the database, the time each step took, any errors encountered, and the final validation results. This documentation is crucial for auditing and for future migrations (like moving to HANA next year).
The PAS-C01 exam tests your understanding of SAP database migration methods, tools, and constraints in very specific ways. You will see scenario-based questions where you must choose the correct migration approach based on factors like database type, size, downtime budget, and network connectivity.
Here are the exact concepts the exam loves to test:
When to use AWS DMS vs. HANA System Replication: The exam gives you a scenario and asks which tool to use. The trap is that beginners assume DMS can handle HANA migrations seamlessly. DMS can technically move data to and from HANA, but for near-zero downtime HANA-to-HANA migrations, HSR is the recommended approach because it is native, real-time, and built specifically for HANA. DMS is better for cross-engine migrations (e.g., Oracle to HANA) or when you need data transformation.
Homogeneous vs. Heterogeneous migration definitions: The exam will test whether you understand that 'homogeneous' means same database engine and 'heterogeneous' means different. They may ask which method supports which type. HSR only supports homogeneous HANA migrations. DMS supports both, but with limitations on source/target combinations.
Migration phases and order: The exam expects you to know the correct sequence: Assessment, Plan, Set up target, Connect, Load data, Validate, Cutover. A common trap question asks what to do first after setting up the target — the wrong answer might be 'start the cutover' (too early) or 'run the full load' (before connectivity is verified).
Prerequisites for using HSR: The exam tests that you need low-latency, high-bandwidth network between source and target, that both systems must be the same HANA version and patch level, and that HSR requires a specific license configuration. They might set a trap where the target HANA system has a different version — HSR will not work.
Downtime considerations: The exam is obsessed with 'downtime' and 'recovery time objective (RTO)' and 'recovery point objective (RPO)'. RTO is how fast you need to be back up after a failure. RPO is how much data you can afford to lose. For migrations, the exam asks: 'Which method has the lowest downtime?' The answer is HSR (seconds to minutes) vs. DMS (minutes to hours). But HSR requires more prerequisites.
Security during migration: The exam tests that data in transit must be encrypted (using SSL/TLS), and that you should use AWS PrivateLink or VPN to keep traffic off the public internet. They may ask about using AWS DMS with an SSL connection — the correct answer is to enable SSL on both the source and target endpoints.
Traps about data validation: The exam might describe a scenario where a migration completes but some records are missing. They ask what went wrong. The correct answer is typically that ongoing replication was not configured or was stopped too early, or that the source database was still accepting writes after the cutover started.
Specific tool names: Know that 'SAP HANA System Replication' is different from 'AWS DMS' and from 'SAP SWPM'. The exam might ask which tool is best for a heterogeneous migration when you want to transform data types — that is AWS DMS. They might ask which tool can migrate the entire SAP stack (application + database) — that is SAP SWPM or SUM.
Key definitions to memorise: full load (bulk copy of existing data), ongoing replication (continuous sync of changes), CDC (Change Data Capture — reading the database log to capture changes), cutover (the final switch), validation (comparing source and target data).
AWS DMS is the primary tool for heterogeneous SAP database migrations (e.g., Oracle to HANA) and supports both full load and ongoing replication for minimal downtime.
SAP HANA System Replication (HSR) provides near-zero downtime for HANA-to-HANA migrations but requires identical HANA versions and low-latency network connectivity.
Every SAP database migration follows a strict sequence: assess, plan, set up target, connect, load data, validate, and cutover — never skip the validation step.
The recovery point objective (RPO) determines how much data you can afford to lose; for SAP, RPO is often zero, meaning no data loss is acceptable, which drives the choice of migration method.
Data integrity validation after migration is mandatory — you must compare record counts and checksums between source and target databases before declaring success.
Security during migration requires encrypting data in transit using SSL/TLS and keeping traffic within a private network (VPN or AWS PrivateLink) to avoid exposure on the public internet.
A rollback plan must exist before any migration begins; this typically means keeping the source database operational and intact for at least 30 days after cutover.
Homogeneous migrations (same database engine) are simpler and can use native replication tools, while heterogeneous migrations (different engines) require data transformation and careful schema mapping.
These come up on the exam all the time. Here's how to tell them apart.
AWS DMS
Supports heterogeneous migrations (e.g., Oracle to HANA).
Provides both full load and ongoing replication (CDC).
Can be used for non-SAP databases as well as SAP.
HANA System Replication (HSR)
Only supports HANA-to-HANA migrations (homogeneous).
Provides real-time, continuous replication with very low latency.
Is native to SAP HANA and requires identical HANA versions on both sides.
Homogeneous Migration
Source and target use the same database engine.
Simpler to execute and requires minimal data transformation.
Can use native replication tools like HSR or database-specific features.
Heterogeneous Migration
Source and target use different database engines.
Requires data type mapping and schema conversion.
Often uses AWS DMS or third-party ETL tools for transformation.
Full Load (Initial Load)
Copies all existing data from source to target in one bulk operation.
Can take hours or days depending on database size.
Is a one-time process that happens before cutover.
Ongoing Replication (CDC)
Continuously captures and applies changes made after the full load.
Keeps target synchronised with the source in near-real-time.
Requires source database logging features (e.g., supplemental logging for Oracle).
Cutover
The final step where you switch all application traffic to the new database.
Planned well in advance and typically scheduled during low-activity periods.
Should be completed as quickly as possible to minimise downtime.
Rollback
The process of reverting to the source database if the new system fails.
Requires the source database to remain intact and operational.
Should be tested in advance but ideally never executed.
Mistake
Migrating a database to AWS is just a matter of copying the files from one server to another using FTP.
Correct
Database migration requires specialised tools like AWS DMS or HSR that ensure data consistency, handle ongoing changes, and validate data integrity. Simply copying files can corrupt the database or miss active transactions.
File copy tools like FTP or SCP do not understand database internals. They cannot handle open transactions, index structures, or the need for point-in-time consistency. Beginners coming from a file-management background often assume databases are just files.
Mistake
You can use HANA System Replication to migrate from an Oracle database to a HANA database.
Correct
HANA System Replication only works between two HANA databases. It is a homogeneous replication technology. To migrate from Oracle to HANA, you need a heterogeneous tool like AWS DMS, SAP Landscape Transformation (SLT), or SAP Data Services.
The name 'System Replication' sounds general, so people assume it works across database types. They do not realise it is a HANA-specific protocol that requires identical database engine on both ends.
Mistake
AWS DMS can handle any database migration without any preparation on the source database.
Correct
AWS DMS often requires changes to the source database, such as enabling supplemental logging (for Oracle) or configuring a replication slot (for PostgreSQL). Without these changes, DMS cannot capture ongoing changes during the migration.
Beginners expect DMS to be 'set and forget', but database engines have their own requirements for allowing external tools to read their transaction logs. This necessary preparation step is frequently overlooked.
Mistake
You can migrate a live SAP database without any downtime at all.
Correct
Even with techniques like HSR, there is a brief period of downtime during the final cutover when you stop the primary system and start the secondary. Zero-downtime migration is a myth; the goal is always 'minimal downtime', not 'no downtime'.
Marketing materials often use phrases like 'near-zero downtime', which beginners interpret as 'no downtime'. The exam explicitly tests whether you understand that a cutover window exists, even if it's very short.
Mistake
After the migration, you can immediately delete the old database and the AWS DMS replication instance.
Correct
You should keep the old database and the DMS replication instance running for a period of time to allow for rollback if problems are discovered. Many organisations keep the old system for at least 30 days as a safety net.
In the rush to finish, people want to clean up. But the old system is the only fallback if the new system has undetected issues. The exam tests the concept of having a rollback plan.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, AWS DMS cannot achieve true zero downtime. It can perform a full load and then ongoing replication, but you will still need a brief cutover window (usually minutes to hours) to stop the source and start the target. For near-zero downtime with HANA, use SAP HANA System Replication instead.
Homogeneous migration means moving from one database engine to the same database engine, for example Oracle to Oracle. Heterogeneous migration means moving between different engines, such as Oracle to SAP HANA. The tools and complexity differ significantly: homogeneous can use native replication, while heterogeneous requires data transformation.
If you are doing a database-only migration and the database engine does not change, the SAP application typically needs only configuration changes (like updating database connection strings). However, if you change the database engine (e.g., from Oracle to HANA), the application may require additional adjustments to database-specific code and drivers.
Encrypt all data in transit using SSL/TLS between the source and target databases. Use a private network connection like a VPN or AWS Direct Connect instead of going over the public internet. Also ensure data at rest in the target database is encrypted using AWS KMS or the database's native encryption.
Because you keep the source database running and unchanged until cutover, you can simply restart the migration from scratch. AWS DMS supports resuming failed tasks from the last checkpoint. The key is never to modify or decommission the source database until you have fully validated the new system.
Yes, you can run multiple AWS DMS tasks or multiple HSR instances in parallel, provided you have enough network bandwidth and source database resources. However, the PAS-C01 exam typically focuses on single-database migration scenarios for simplicity.
HANA System Replication is a standard feature of SAP HANA, but you must ensure your SAP license supports it. Some license tiers restrict replication to specific scenarios like disaster recovery. Always check your SAP license agreement, as using HSR for migration may require additional licensing from SAP.
You've finished SAP Database Migration to AWS. Continue through the PAS-C01 study guide to build a complete picture of the exam.
Done with this chapter?