What if the database migration tool you pick in 2027 quietly locks your architecture for the next five years? That sounds dramatic, but it happens more often than teams admit. The three big cloud providers all sell something called “DMS” (Database Migration Service), and on a slide they look interchangeable. Under the hood, they are not.
AWS DMS is a standalone managed replication engine. Azure DMS and Google Cloud DMS are migration orchestrators built around their own target platforms. Choosing between them is less about which brand you trust and more about what you need the tool to do after the first cutover. This article walks through the architecture decisions that will shape 2027 planning: replication topology, change data capture (CDC) coverage, capacity models, and the often-forgotten schema conversion layer.
Why the “DMS” Name Is Misleading
Three products, three design philosophies. AWS DMS launched in January 2016 as a general-purpose replication service. Azure Database Migration Service reached general availability in 2018 as a guided path into Azure data platforms. Google Cloud DMS arrived around 2021 with a similar target-scoped mission.
That history explains the divergence. AWS built a replication engine first and added orchestration later. Azure and Google built orchestration first and leaned on the destination platform’s native tooling for the heavy lifting. For a one-time lift-and-shift, all three work. For anything ongoing, the differences start to bite.
The first architecture question is not “which cloud?” It is “is this a migration or a replication relationship?” Teams that answer that honestly save themselves months of rework.
Decision One: One-Time Cutover or Ongoing Replication?
A cutover migration moves data once, validates it, and flips the switch. Ongoing replication keeps source and target in sync continuously, sometimes for years. These are different problems.
AWS DMS handles both, but its endpoint breadth makes it the stronger choice for continuous replication, including on-premises to cloud and cross-region patterns. Azure DMS and Google Cloud DMS are oriented toward cutover migrations into their own platforms. If your 2027 roadmap includes multi-cloud replication or a phased migration where the old system runs in parallel for a year, that distinction matters more than any feature checklist.
A practical tip from teams that have done this: sketch your replication topology on paper before you open a console. Mark every source, every target, and every direction of data flow. If arrows point in more than one direction, or to more than one cloud, you have already narrowed the field.
Decision Two: How Broad Does CDC Need to Be?
Change data capture is the mechanism that keeps a target current by streaming inserts, updates, and deletes from the source. It is the hardest part of any migration to get right, and support varies sharply.
AWS DMS supports CDC from a wide range of sources, including Oracle, SQL Server, PostgreSQL, MySQL, and MongoDB, to many targets. Azure and Google DMS offer CDC on a narrower set of supported source and target pairs, tied to the services each platform supports. Those matrices change frequently, so any 2027 plan should state “as of” a specific date and check the live support list rather than trusting a blog post.
Common mistake: teams assume CDC works for their exact engine version because it worked for a similar one. Minor version gaps break replication more often than major ones, because log formats and replication slot behavior shift quietly. Test CDC against your real source version, with your real write volume, before committing.
Decision Three: Instances, Serverless, or Target-Tied Capacity?
Capacity planning is where the three services diverge most visibly in 2027.
| Service | Capacity model | What you size |
|---|---|---|
| AWS DMS | Replication instances or DMS Serverless | Instance class or task-level throughput |
| Azure DMS | Tied to target service compute | Target database resources |
| Google Cloud DMS | Migration service provisioning | Migration job capacity and target |
AWS DMS Serverless, which reached general availability in 2024, removes manual instance sizing and scales capacity with task demand. Google’s DMS offers serverless-style provisioning in a similar spirit. Azure’s model leans on the destination service’s compute, which simplifies some decisions and constrains others.
The architecture implication is real. With fixed instances, you over-provision to survive peak load and pay for idle capacity. With serverless, you tune task-level throughput and watch for cost spikes during full loads. If your team already runs workloads across providers, the metrics you collect need to be comparable across all three, which is why a consistent multi cloud metrics track across aws azure google cloud matters before you compare migration costs. (Extract, transform, load (ETL))
Here is the mistake that derails more migrations than any other: treating conversion and replication as one step.
They are separate services in every cloud. AWS has the Schema Conversion Tool (SCT) for translating schemas and code between engines. Azure Migrate provides assessment and conversion features. Google offers conversion tooling, for example for Oracle-to-PostgreSQL moves. None of these are the replication engine itself.
Why does the separation matter for architecture? Because heterogeneous migrations (different engine families) depend on conversion quality, while homogeneous migrations (same engine family) mostly depend on replication fidelity. All three vendors’ native tools are strongest in the homogeneous case. If you are moving Oracle to PostgreSQL, your risk sits in conversion, not in CDC. Budget time and testing for the layer that actually carries the risk.
A useful exercise: list every stored procedure, trigger, and proprietary function in your source database. That list, not the row count, predicts your conversion effort.
Decision Five: How Will You Compare Costs Across Three Clouds?
Cost comparison across AWS, Azure, and Google Cloud is genuinely hard because the billing structures do not line up. AWS DMS charges for replication capacity plus data transfer. Azure DMS is largely free as a service, with cost concentrated in target resources. Google’s pricing ties to the migration service and the destination.
The trap is comparing headline numbers. A migration that looks cheap on service fees can cost far more in target compute, egress, or extended parallel running. Teams that map workloads honestly before committing tend to make better calls, and a structured aws vs azure vs google cloud 2026 comparison is a reasonable starting frame for the 2027 version of the same question.
Two practical habits that work:
- Model the full parallel-run period, including the cutover weekend.
- Include data transfer and egress in every estimate, because they scale with volume, not with time.
Decision Six: Will You Standardize on One Framework?
By 2027, most mid-size and large organizations will run workloads in at least two clouds. That changes the DMS question from “which tool?” to “which framework governs all of them?”
A multi cloud framework run workloads across aws azure google cloud approach treats migration tooling as one layer in a broader operating model. Replication, conversion, cutover runbooks, and rollback plans get standardized even when the underlying services differ. This is more work upfront and far less work during the third migration.
If your 2027 plan involves GPU-heavy workloads, such as vector databases or AI-adjacent data platforms, cost modeling gets even messier, and the aws vs azure vs google cloud gpu pricing 2026 actually breakdown is worth reading before you assume migration costs dominate your budget.
Decision Seven: What Does Your Rollback Plan Actually Require?
Nobody plans to fail, but every architecture decision should survive one. If the cutover goes wrong at 2 a.m., can you fail back?
Ongoing replication makes rollback cheap, because the source stays current and you can simply point traffic back. One-time cutover tools make rollback expensive, because you need a fresh reverse migration. This is the strongest argument for keeping CDC running longer than feels necessary. A week of parallel running costs less than a failed cutover.
Rehearse the failback and the cutover. Teams that test rollback find configuration gaps while the pressure is low. Teams that skip it discover them at the worst possible moment.
What Actually Works in Practice
Across all three platforms, a few habits separate smooth migrations from painful ones.
Start with a small, boring database. Prove the full pipeline end to end, including conversion, CDC, validation, and rollback, before touching anything business-critical. Validate row counts and checksums continuously, including at the end. Keep the migration runbook in version control alongside your infrastructure code. Document which tool owns which layer, because confusion between conversion and replication is the single most common source of delay.
It also helps to understand the destination platform deeply before you migrate into it. If you are moving to Kubernetes-hosted databases, knowing how the kubernetes architecture control plane worker nodes fit together will save you from sizing mistakes that only show up under load.
One more habit worth adopting: treat the supported source and target matrix as a living document. Pin the version you validated, note the date, and re-check before each wave. Matrices shift with every provider release cycle.
Conclusion
The AWS DMS vs Azure DMS vs Google DMS decision is not really a vendor contest. It is a set of architecture questions: cutover or continuous replication, how wide your CDC coverage must be, whether capacity is instance-based or target-tied, and whether conversion is treated as its own layer. Answer those honestly in 2027, and the tool choice mostly makes itself. Skip them, and you will discover the answers during a cutover weekend, which is the most expensive classroom there is.
FAQ
What is the main difference between AWS DMS, Azure DMS, and Google DMS?
AWS DMS is a standalone managed replication engine with broad endpoint and CDC support. Azure DMS and Google Cloud DMS are migration orchestration services scoped to their own target platforms. The practical difference shows up in ongoing replication and cross-cloud scenarios, where AWS DMS generally offers more flexibility.
Can Azure DMS or Google DMS replicate data between two different clouds?
Both are designed primarily for migrations into their own platforms, so cross-cloud replication is not their core strength. If your architecture requires continuous replication between providers, verify the current supported source and target matrix before assuming it works.
Is CDC support the same across all three services?
No. AWS DMS covers CDC from a wide range of sources to many targets. Azure and Google DMS support CDC on a narrower set of pairs tied to their target services. These matrices change often, so always check the live documentation rather than relying on older articles.
Yes, in most heterogeneous migrations. AWS SCT, Azure Migrate, and Google’s conversion tooling are distinct from the replication engines. Treat conversion and replication as separate layers with separate testing and risk profiles.
Is serverless capacity available on all three platforms?
AWS DMS Serverless became generally available in 2024, and Google offers serverless-style provisioning. Azure’s capacity model is tied more closely to the target service’s compute. The shift means capacity planning moves from instance sizing toward task-level throughput tuning.
How long should I keep replication running after cutover?
Long enough to prove stability and rehearse a failback. Many teams run parallel for a week or more. The cost of extended parallel running is usually far lower than the cost of a failed cutover with no way back.
The final habit is documentation hygiene: record the exact service tier, engine version, and capacity mode you validated, then re-test before each migration wave rather than trusting a plan written months earlier. Provider roadmaps move faster than most migration programs, and a setting that behaved one way in January can behave differently by the time your third wave runs in autumn. Write the assumptions down, date them, and assign someone to own the review. That single practice prevents more surprises than any tool comparison table ever will.
