AWS Database Migration Service (DMS) lets you move your data from one database to another with minimal downtime. For the DBS-C01 exam, you must understand how DMS handles both homogeneous migrations (same database engine, like MySQL to MySQL) and heterogeneous migrations (different engines, like Oracle to Amazon Aurora). This chapter breaks down every step so you can confidently answer exam questions about replication instances, source and target endpoints, and the cutover process.
Jump to a section
A simple way to picture Executing Database Migrations to AWS
You decide to move to a new house across town because your current house is too small and the neighbourhood isn't great. First, you pack all your furniture and belongings into boxes (your source database), but you can't just dump everything into the new house at once because the new house has a different layout and some rooms are shaped differently (the target database). So you hire a professional moving company that uses a van (the replication instance) to carry your items. The movers can't just stop your life while they move; you still need to sleep and eat at the old house until the new one is ready. That means the movers have to keep track of any new items you buy or things you throw away while the move is happening, and they add those changes to the van for the next trip. This is exactly what continuous change data capture (CDC) does in a database migration. Once the van has delivered most of your things to the new house, there's a final moment when you lock the old house and close the door (cutover). Then you unlock the new house and start living there. The moving company's job is finished. Your new house might even have a different plumbing system (heterogeneous migration), so the movers had to convert your water pipes from copper to PVC using a special tool (the AWS Schema Conversion Tool or SCT) before they could even start packing.
In an IT database migration, the "house" is your database, the "furniture" is your data, and the "moving company" is AWS Database Migration Service (DMS). The moving van runs on a dedicated server (the replication instance) and uses log files from the source database (the transaction logs) to keep track of changes during the move. The final lock-the-door moment is the cutover, when all applications switch over to the new database. The key difference is that your moving van can handle different types of furniture — from MySQL (like a wooden bed) to Oracle (like a metal frame) — and the moving company can even change the shape of the furniture to fit the new house, which is what AWS DMS does in a heterogeneous migration using AWS SCT.
Database migration is the process of moving data from one database system to another. In the real world, companies often need to migrate because their current database is too slow, too expensive, or doesn't support modern features. AWS DMS is a service provided by Amazon Web Services that makes this migration easier. It handles the heavy lifting of copying data, applying changes, and minimising downtime.
Before you start, you need to understand the two main types of migration. A homogeneous migration means you are moving from one database to another of the same type. For example, you have a MySQL database on-premises (in your own data centre) and you want to move it to Amazon RDS for MySQL. Because both databases speak the same language (SQL dialect), DMS can directly copy the data without changing it. A heterogeneous migration means you are moving between different database engines. For example, you have an Oracle database and you want to move it to Amazon Aurora PostgreSQL. Oracle and PostgreSQL use different SQL syntax, different data types, and different storage structures. You cannot just copy the data; you must convert the schema (the structure of tables, indexes, and constraints) to work with the new engine. This is where the AWS Schema Conversion Tool (SCT) comes in. SCT analyses your source database schema and generates a compatible schema for the target database.
AWS DMS works by using three main components:
Source endpoint: This is the connection details for your original database (the one you are moving from). You must provide the database engine, hostname, port, username, password, and optionally an SSL certificate for encryption.
Target endpoint: This is the connection details for the destination database (the one you are moving to). It could be an Amazon RDS instance, an Amazon Aurora cluster, an Amazon S3 bucket, or even another on-premises database.
Replication instance: This is a dedicated Amazon EC2 instance that actually runs the data transfer. You choose the size (e.g., small, medium, large) based on how much data you need to move. The replication instance connects to both the source and target endpoints.
The migration process has three phases: 1. Full load: DMS copies all existing data from the source to the target. It does this by reading the source data and writing it to the target. For large databases, this can take hours or days. 2. Continuous replication (CDC): While the full load is happening, your source database is still being used by your applications. People insert, update, and delete data. DMS captures these changes from the source database's transaction logs (a record of every change made to the database) and applies them to the target. This keeps the target database in sync with the source. 3. Cutover: When the full load is complete and CDC has caught up (so the target database has the same data as the source), you stop all applications from writing to the source database, apply any final changes via CDC, and then redirect your applications to the new target database. This switchover moment is called the cutover.
AWS DMS supports many source and target database engines. Common source databases include Oracle, SQL Server, MySQL, PostgreSQL, MariaDB, and SAP ASE. Common target databases include Amazon RDS for MySQL, PostgreSQL, Oracle, SQL Server, Amazon Aurora (MySQL and PostgreSQL compatible), Amazon S3, Amazon Redshift, and even DynamoDB.
DMS also allows you to validate the migration. It can compare the data in the source and target to ensure nothing was lost or corrupted during the move. You can enable validation on the replication task. Validation adds overhead but guarantees data integrity.
Keep in mind that DMS does not migrate the schema itself for heterogeneous migrations. That is the job of AWS SCT. You run SCT before you even start the DMS task. SCT creates a target schema in your target database, and then DMS copies the data into that schema. For homogeneous migrations, DMS can automatically create the target schema if you set the task to "Create target tables".
Analyse Source Database
Identify the source database engine, version, size, schema complexity, and LOB usage. Use AWS SCT's assessment report to understand which objects need manual conversion for heterogeneous migrations. This step determines the migration strategy and tooling.
Convert Schema with AWS SCT
For heterogeneous migrations, run AWS SCT to convert the source schema to the target database format. SCT generates SQL scripts to create tables, indexes, and views in the target. For homogeneous migrations, this step is skipped because the schema is compatible.
Create Target Database
Launch the target database (e.g., Amazon RDS for MySQL, Amazon Aurora) using the AWS Console or CLI. Apply the converted schema from SCT to the target database. Ensure the target database has sufficient storage and compute capacity for the data volume.
Configure DMS Endpoints and Replication Instance
Create source and target endpoints in AWS DMS with the correct connection details, including hostname, port, database name, and credentials. Create a replication instance of appropriate size in a VPC that can reach both endpoints. Test endpoint connections from the replication instance.
Create and Start a Replication Task
Define a replication task with migration type (e.g., full load + CDC), table mappings, LOB settings, and validation options. Start the task. Monitor progress in the DMS console and CloudWatch. Address any errors in the task logs.
Perform Cutover
When the full load is complete and CDC is caught up (target is in sync), stop write operations on the source database. Allow CDC to flush remaining changes. Redirect application connections to the new target database. Stop the replication task and decommission the replication instance.
A retail company called ShopNow runs its entire ecommerce platform on an on-premises Oracle database. The database is 10 years old, maintenance costs are high, and they can't scale easily during peak shopping seasons like Black Friday. The IT manager decides to migrate to Amazon Aurora MySQL because it is more cost-effective and has better scalability.
First, the database administrator (DBA) uses AWS SCT to convert the Oracle schema to a MySQL-compatible schema. SCT generates a report showing any objects that cannot be automatically converted, such as Oracle-specific stored procedures that use PL/SQL syntax. The DBA manually rewrites those procedures into MySQL's SQL dialect. Then SCT creates the new schema in an Amazon Aurora MySQL cluster.
Next, the DBA sets up AWS DMS. They create a source endpoint pointing to the on-premises Oracle database, using the database's hostname, port 1521, and credentials. They also set up an AWS KMS key for encryption. They create a target endpoint pointing to the Aurora MySQL writer endpoint. They then create a replication instance of medium size, placed inside a VPC that can reach both the on-premises database (via a VPN or Direct Connect) and the Aurora cluster.
They create a replication task with the following settings:
Migration type: "Migrate existing data and replicate ongoing changes" (this is the full load plus CDC option).
Source endpoint: Oracle on-premises.
Target endpoint: Aurora MySQL.
Table mappings: They specify which tables to include. They exclude temporary tables and logs.
Validation: They enable it to ensure all rows match.
LOB mode: They set to "Limited LOB mode" because some product descriptions are large objects (LOBs).
The task starts. The full load takes 8 hours to copy 500 GB of data. Meanwhile, transactions continue on the Oracle database. DMS captures those changes from the Oracle redo logs. Once the full load completes, CDC catches up within 20 minutes. The DBA sees the task status change to "Apply complete" on the AWS Console.
On the day of cutover, they stop the ecommerce website's write operations. They allow CDC to apply any remaining writes. Then they switch the DNS CNAME record for the database endpoint from the old Oracle IP to the new Aurora writer endpoint. The website immediately starts using the new database. They disable the replication task and decommission the replication instance.
The whole process was done with only 5 minutes of downtime — just enough to stop writes and switch DNS. ShopNow now saves 60% on database costs and can scale automatically during Black Friday.
Key actions an IT professional takes during a real DMS migration:
Run AWS SCT first to convert the schema for heterogeneous migrations.
Validate source and target connectivity from the replication instance.
Choose the correct migration type: full load, full load with CDC, or CDC only.
Enable validation to catch data mismatches early.
Monitor task performance in CloudWatch (AWS monitoring service).
Plan the cutover window carefully, typically during low-traffic hours.
Have a rollback plan: if the cutover fails, they can redirect applications back to the source database.
The DBS-C01 exam tests your knowledge of AWS DMS with specific focus on migration types, endpoint configuration, replication instances, and the cutover process. You need to memorise the following:
Key concepts the exam loves:
The difference between homogeneous and heterogeneous migrations. For homogeneous, you do NOT need SCT; for heterogeneous, you MUST use SCT to convert the schema.
The three migration types: "Migrate existing data" (full load only), "Migrate existing data and replicate ongoing changes" (full load + CDC), and "Replicate ongoing changes only" (CDC only without a full load).
The replication instance must be in a VPC that can reach both the source and target databases.
Table mappings: You can include or exclude specific tables, schemas, or use transformation rules to rename columns or change data types.
LOB (Large Object) handling: You have three options: "Don't include LOBs", "Include LOB in limited mode" (you set a maximum LOB size, DMS truncates anything larger), or "Include LOB in full LOB mode" (DMS handles LOBs of any size but this is slower).
Validation: DMS can compare row counts and checksums between source and target. This adds performance overhead.
SCT tool: Available as a downloadable application or on AWS. It generates a migration assessment report and can create the target schema.
Common exam traps:
They might ask: "You are migrating from an on-premises Oracle database to Amazon Aurora MySQL. Which tool should you use first?" The answer is AWS SCT, not DMS. Many beginners pick DMS only, but DMS does not convert schemas for heterogeneous migrations.
They might present a scenario where the source database is in a different VPC and ask which additional configuration is needed. Answer: You need VPC peering or a VPN connection so the replication instance can reach the source.
They might ask about LOB settings when migrating a table containing images. The correct answer is "Full LOB mode" because images can be larger than the limited mode size limit (typically 32 KB).
They might test your understanding of CDC: If you want zero downtime during the cutover, you must use CDC. If you only need a one-time copy with downtime, you can use full load only.
They might ask about validation: Validation compares data in batches. If it fails, the task continues but logs the mismatches. You can then fix manually.
Question patterns to expect:
Scenario-based questions: "A company migrated from SQL Server to Aurora PostgreSQL using AWS DMS. Some rows are missing. What should they check first?" Answer: Check that validation was enabled and review the error logs for table mapping issues.
Configuration questions: "Which settings do you need to provide for a source endpoint?" Answer: Database engine, hostname, port, username, password, and optionally SSL certificate.
Cutover questions: "After the full load completes and CDC has caught up, what is the final step?" Answer: Stop writes to the source and switch applications to the target.
Definitions to memorise:
Replication instance: An EC2 instance running DMS engine.
Endpoint: Connection configuration to a source or target database.
Full load: Initial copy of all existing data.
CDC: Continuous replication of ongoing changes.
Cutover: The point when applications switch to the new database.
SCT: Schema Conversion Tool — converts schema for heterogeneous migrations.
LOB: Large Object — data types like BLOB, CLOB, TEXT.
Validation: Integrity check between source and target.
Table mapping: Rules that define which tables to include or how to transform them.
Task: A DMS job that defines what to migrate, how, and with what settings.
AWS DMS uses a replication instance, source endpoint, and target endpoint to copy data from a source database to a target database.
For a heterogeneous migration (different database engines), you must first run AWS Schema Conversion Tool to convert the schema before using DMS.
Continuous Change Data Capture (CDC) allows DMS to keep the target database synchronised with ongoing changes on the source database.
The cutover is the moment when you stop writes to the source database and redirect your applications to the new target database.
Validation in DMS compares rows between source and target but adds performance overhead and should be used carefully with large datasets.
Full LOB mode in DMS handles large objects of any size but is slower than Limited LOB mode, which truncates objects over a set size.
Table mappings in DMS control which tables, schemas, or columns are included, excluded, or transformed during the migration.
DMS supports common source databases like Oracle, SQL Server, MySQL, and PostgreSQL, and targets like Amazon RDS, Aurora, S3, and Redshift.
The replication instance must be in a VPC that can reach both the source and target endpoints via network routing and security groups.
SCT generates a migration assessment report that shows which database objects can be automatically converted and which require manual intervention.
A full-load-only migration requires downtime because applications must stop writing to the source during the copy.
Enable validation during the initial migration or for a subset of tables to reduce performance impact while still catching data mismatches.
These come up on the exam all the time. Here's how to tell them apart.
Homogeneous Migration
Source and target use the same database engine (e.g., MySQL to MySQL).
Schema conversion is not needed; data can be copied directly.
DMS can automatically create target tables if configured to do so.
Heterogeneous Migration
Source and target use different database engines (e.g., Oracle to PostgreSQL).
AWS SCT must be used first to convert the schema for the target engine.
Some objects (e.g., stored procedures) may need manual rewriting.
Full Load Only
Copies all existing data from source to target in one batch.
Applications must stop writing to the source during the copy.
Downtime is required; no ongoing changes are captured.
Full Load with CDC
Copies all existing data and then replicates ongoing changes via CDC.
Source database can remain operational; changes are captured continuously.
Minimal downtime at cutover; target stays synchronised in near-real time.
Limited LOB Mode
Defines a maximum LOB size (default 32 KB).
LOBs larger than the limit are truncated.
Faster performance because LOBs are not handled individually.
Full LOB Mode
Handles LOBs of any size without truncation.
Slower performance because DMS processes each LOB individually.
Use for columns containing images, videos, or large text files.
Validation Enabled
DMS compares rows between source and target using checksums.
Adds performance overhead; migration may be slower.
Provides confidence that data is intact; errors are logged.
Validation Disabled
No row comparison is performed.
Faster migration; no overhead from validation checks.
No automatic verification; you must manually verify data integrity.
Mistake
AWS DMS can automatically convert the schema for any database to Amazon Aurora.
Correct
DMS only copies data. For heterogeneous migrations, you must use AWS SCT to convert the schema before DMS can start copying data.
Beginners assume DMS is an all-in-one tool because it handles both the copy and conversion. In reality, the conversion step is separate and required.
Mistake
During a DMS migration, the source database must be stopped to avoid data loss.
Correct
With CDC enabled, the source database can remain fully operational. DMS captures ongoing changes from the source's transaction logs.
Many people think migrations require downtime because that's how older manual migrations worked. AWS DMS was designed to minimise or eliminate downtime.
Mistake
If the replication instance is in a public subnet, it can connect to any source database on the internet automatically.
Correct
The replication instance needs network routes (via subnets, routing tables, and security groups) to both the source and target. Public subnets require a public IP or NAT gateway, but the instance must still have proper security group rules and network ACLs.
People confuse a public subnet's accessibility with automatic connectivity. AWS networking requires explicit configuration regardless of subnet type.
Mistake
Validation in DMS is optional but always recommended because it adds no overhead.
Correct
Validation adds significant performance overhead because DMS must compute checksums and compare every row betweensource and target. It can slow down the migration, especially for large datasets.
Beginners think 'validation is free' because it sounds like a simple check. In reality, it requires reading and comparing all data twice.
Mistake
After a DMS task completes the full load, the migration is finished.
Correct
Full load is only one phase. You must also apply CDC to capture changes made during the full load. Then you perform the cutover to switch applications to the new database.
People misunderstand the migration lifecycle because they think copying data is the only step. They forget that applications still write to the source during the copy.
Mistake
You can migrate from any database engine to any other engine using DMS without any preparation.
Correct
DMS supports specific source and target engine combinations. For instance, you cannot migrate from IBM Db2 to Amazon DynamoDB using DMS. DMS supports only listed combinations. Additionally, for heterogeneous migrations, SCT might not support all object types.
Beginners think 'migration service' means universal compatibility. In reality, DMS has a defined list of supported engines and versions.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, DMS supports this heterogeneous migration. You must first use AWS SCT to convert the Oracle schema to a PostgreSQL-compatible schema, then use DMS to copy the data and apply ongoing changes via CDC.
Yes, by using DMS with continuous CDC. The source database remains fully operational during the full load. When the full load completes and CDC catches up, you switch applications with minimal downtime.
Full load copies all existing data from source to target in one go. CDC (change data capture) replicates ongoing changes (inserts, updates, deletes) that occur after the full load starts, keeping the target in sync in near-real time.
Yes, the replication instance must be able to reach the on-premises source database. You typically set up a VPN connection between your VPC and on-premises network, or use AWS Direct Connect for a dedicated private connection.
DMS offers three LOB modes: 'Don't include LOBs' skips them, 'Limited LOB mode' truncates objects over a configurable size, and 'Full LOB mode' handles any size but is slower. Choose based on your data requirements.
For homogeneous migrations, DMS can create tables and copy data, but it does not migrate indexes, views, stored procedures, or other database objects. For heterogeneous migrations, AWS SCT helps convert these objects, but you may need to manually recreate some.
You can monitor task status in the AWS DMS Console, view logs in Amazon CloudWatch, and check table-level statistics (rows loaded, rows applied) in the DMS task details. DMS also sends CloudWatch metrics like CPU utilisation and read/write throughput.
You pay for the replication instance running time (by the hour), any data transfer charges (for data moved across regions or to/from on-premises), and storage used by logs. DMS itself does not charge additional fees beyond the underlying resources.
You've finished Executing Database Migrations to AWS. Continue through the DBS-C01 study guide to build a complete picture of the exam.
Done with this chapter?