Published on Jun 2, 2026
If you’re moving databases to AWS, you’ve probably already run into the question: can we just use AWS Database Migration Service and handle this ourselves, or do we need outside help? Good question. And the honest answer is: it depends on what you’re migrating and what state your infrastructure is in.
This article walks you through how AWS DMS works, when it’s the right tool for the job, and when the complexity of your migration calls for a different approach.
AWS Database Migration Service (DMS) is a managed cloud service that moves databases to AWS with minimal downtime. It supports migrations between the same database engine (homogeneous) and between different engines (heterogeneous), and it can keep your source database fully operational during the move.
That last part matters a lot. In most real-world migrations, you cannot afford to take a database offline for hours while data transfers. DMS solves that with continuous data replication: it captures changes from the source in real time and applies them to the target until you’re ready to cut over.
AWS DMS uses three main components working together:
The typical flow looks like this: DMS connects to your source database, reads the existing data, loads it into the target, then switches to Change Data Capture (CDC) mode. CDC tracks every insert, update, and delete on the source and mirrors those changes on the target in near real time. When you’re ready to switch over, the target is current, and you flip the connection.
👇🏻 Here’s a breakdown of the three migration task types DMS supports:
Migrates all existing data from source to target in one shot. No ongoing sync. Use this when you can afford a brief downtime window, or when you’re migrating a database that isn’t actively written to.
The most common approach for production systems. Migrates existing data first, then captures and applies ongoing changes until you cut over. This is how you achieve near-zero downtime.
Skips the initial full load. Use this when you’ve already loaded the data by another method (like a native backup/restore) and only need DMS to handle ongoing changes.
This is the first thing to figure out, because it determines how much complexity you’re dealing with.
You’re moving from PostgreSQL to PostgreSQL, MySQL to MySQL, Oracle to Oracle. The schema and data types are compatible, so DMS can handle the move without transformation.
This is the simpler scenario. DMS does the heavy lifting: replicates data, handles CDC, and lets you cut over when ready.
A common example in cloud-to-cloud migrations is moving from Azure Database for PostgreSQL to Amazon RDS for PostgreSQL. The engines match, so you’re mostly dealing with network connectivity and schema validation, not schema conversion.
You’re moving from Oracle to Amazon Aurora PostgreSQL, or from SQL Server to MySQL. The schemas are incompatible. Data types don’t map one-to-one. Stored procedures, functions, and views need to be rewritten.
This is where AWS Schema Conversion Tool (SCT) comes in, and where things get significantly more complex.
These two tools are almost always used together in heterogeneous migrations, but they do completely different things.
AWS Schema Conversion Tool (SCT) handles the structural layer. It converts your source database schema to the target database format. It translates object definitions, data type mappings, and where possible, converts stored procedures and triggers. SCT gives you a report showing what it converted automatically and what requires manual intervention.
AWS DMS handles the data layer. Once the schema is in place on the target (either created by SCT or manually), DMS moves the actual data and keeps it in sync.
The practical sequence for a heterogeneous migration:
💡 Pro tip: Don’t skip the SCT assessment report before starting a heterogeneous migration. It tells you the percentage of code that can be converted automatically versus what needs manual work. If the manual effort is high, your timeline needs to reflect that. Not the time DMS takes to transfer data. The manual work is always what takes longer.
You’re moving a database that lives in your data center to Amazon RDS, Aurora, or another AWS managed database service. DMS handles the replication over a Direct Connect link or VPN. The primary complexity here is network throughput and latency during the initial load.
This is the most common pattern we see at Perfsys. Companies outgrow their initial cloud setup on Azure or GCP, or decide AWS fits their stack better, and need to move their databases as part of a broader infrastructure migration.
In our Azure-to-AWS migration for a B2B software company , we replaced Cosmos DB (Gremlin) with Amazon RDS for PostgreSQL. Because the engines were completely different, this wasn’t a pure DMS task. We had to redesign the data model before any data moved. DMS handled the transfer once the target schema was ready, but the actual migration work happened in the architecture phase.
The company migrated 27 cloud applications in 2 months. The database migration was one piece of that, and it required a different approach than someone moving PostgreSQL to PostgreSQL would need.
DMS isn’t only for one-time migrations. Some teams use it for ongoing replication to analytics databases, disaster recovery targets, or read replicas across regions. The CDC capability makes this practical without custom replication infrastructure.
Multiple databases into one. Multiple schemas that need to merge. DMS supports multi-source migrations, though the complexity of data mapping and conflict resolution grows quickly.
AWS DMS is genuinely good at what it was designed for: moving relational data between compatible systems with minimal downtime. When the source and target engines match, the setup is straightforward and the replication is reliable.
Where it gets complicated:
Large binary objects (LOBs). Tables with large columns (BLOBs, CLOBs, large text fields) slow DMS down significantly. Full LOB mode preserves data accurately but at a real performance cost. Limited LOB mode is faster but truncates data above a certain size. You need to audit your schema before you decide which mode to use.
Heterogeneous schema complexity. SCT converts a lot automatically, but complex stored procedures, proprietary SQL syntax, and non-standard data types require manual work. The more your source database relies on engine-specific features, the more rewriting you’ll do.
Data validation. DMS has a built-in validation feature that compares row counts and some data checks between source and target. It’s a useful starting point, but it’s not a substitute for application-level testing. We’ve seen cases where row counts matched but data integrity issues only surfaced when the application ran against the new database.
Network configuration. DMS runs in your VPC. Getting connectivity right between the replication instance, source, and target is tricky, especially in cross-cloud or hybrid scenarios. It requires careful security group and routing configuration. Mistakes here are quiet: the task simply fails or stalls without obvious error messages.
AWS DMS is a powerful tool. It’s also a tool that rewards teams who have done this before.
Here are the signs that a migration is more complex than a standard DMS setup:
Your source database uses engine-specific features heavily. If your Oracle database is full of complex PL/SQL, or your SQL Server relies on linked servers and SQL Agent jobs, the SCT conversion report will tell you how much manual work you’re looking at. That work is usually underestimated.
You’re migrating multiple databases as part of a larger infrastructure move. When database migration is one piece of a broader cloud migration (moving applications, setting up new networking, rebuilding CI/CD), the coordination and sequencing matter as much as the technical steps. Getting them wrong means rollbacks, downtime, and frustrated teams.
Compliance requirements are part of the project. If your migration needs to satisfy SOC 2, HIPAA, or ISO 27001 requirements, the database move is one piece of a larger compliance story. Encryption in transit, key management, and audit logging all need to be set up correctly from the start. Access controls too. This is a separate discipline from migration. Perfsys covers it under AWS Security & Compliance as part of the overall project scope.
You can’t afford data loss or extended downtime. The theory of near-zero downtime migrations is sound. The practice depends on how well the replication is configured, monitored, and validated. An experienced team has seen failure modes that aren’t in the AWS documentation.
At Perfsys, we’ve run migrations ranging from straightforward RDS moves to full Azure-to-AWS platform migrations with 27 applications and multiple database engines. The technical complexity varies enormously, and the right answer for your team depends on your specific stack, timeline, and risk tolerance.
If you’re evaluating whether your migration is the kind you can run in-house with DMS or the kind that needs a structured plan and external expertise, our team is happy to talk through it . No sales pitch. Just a straight conversation about what your migration actually involves.
If you’ve assessed your migration and DMS is the right tool, here’s how to approach the setup:
AWS DMS pricing is based on the replication instance you provision, billed per hour. A single-AZ dms.t3.medium instance runs at roughly $0.09/hour. Multi-AZ replication instances cost roughly twice as much, but they give you automatic failover if the instance goes down mid-migration. For a production cutover, that’s usually worth it.
Data transfer costs apply when moving data out of your source region, and storage is billed for the replication instance’s logs. For most migrations you run, the replication instance cost is the dominant line item. You pay only while the instance is running, so stopping it promptly after cutover matters. People often forget that part.
💡 Pro tip: Size up your replication instance for the initial full load, then scale down for the CDC phase. The full load is compute-intensive; ongoing replication is not. Switching instance class takes a few minutes and can meaningfully reduce your migration bill.
AWS DMS is the right tool for a specific job: moving database data to AWS with minimal downtime, especially when the source and target engines match. When you’re dealing with heterogeneous migrations, complex schemas, or database moves that are part of a larger infrastructure transition, the complexity scales up quickly.
The question isn’t whether DMS can technically do the job. It usually can. The question is how much coordination, schema conversion, validation, and risk management your migration actually requires. Getting that answer right before you start is what separates a smooth cutover from a three-week incident.
Whether you’re moving from Azure, GCP, or on-premise, we’ll tell you exactly what your migration involves, what DMS can handle, and where you’ll need extra hands. No open-ended scoping. Just a straight answer.
Eugene Orlovsky
CEO & Founder | Serverless architect with 10+ years of hands-on experience designing cloud-native architectures on AWS, backed by multiple AWS certifications. He is writing bridges deep technical expertise with real-world business strategy, covering topics from AWS best practices to scaling tech-driven organizations.
85%
Reduction in form creation time
3×
Faster grant application completion
3
months full platform delivery
Perfsys built four AI services for EPIRA.ai on AWS Bedrock, automating grant form creation (80–90% faster) and pre-application eligibility scoring. Delivered in 3 months by 2 engineers with a fully serverless, scalable architecture.
4
Sub-brands unified under one login
2–3×
Faster onboarding of new products
35%
Fewer login-related support requests
Perfsys designed and implemented a customized Keycloak SSO solution aligned with the client's AWS architecture and business requirements. The customer gained a secure, reliable identity management setup that improved access control, simplified authentication, and supported efficient cloud operations.
Need to move fast? Our cloud team is ready to scale, secure, and optimize your systems. Get serverless expertise, 24/7 support, and seamless CI/CD pipelines when you need it most.
