Database Migration Tools: Compatibility and Cutover
Compare database migration tools by source-target pair, schema conversion, downtime tolerance, change data capture, validation evidence, and operating model.
The best database migration tool is the one that supports the required source-target pair, separates schema conversion from data movement, and can meet the allowed downtime with evidence the team can approve. There is no universal winner. A tool that copies rows may not convert stored procedures; a tool that versions application schema changes may not move a production database; and a successful full load does not prove that the application still behaves correctly.
Start with the target platform and the cutover constraint. Then test the specific path with a representative schema, a realistic write rate, and the validation rules that the application and data owners will accept. This comparison covers products and product families with documented roles in those decisions. It does not rank them by sponsorship or claim independent benchmark results. For the wider architectural and operating context, use the data modernization research hub.
Database migration tools compared
| Tool or product family | Documented role and best fit | What it does not settle | Pricing or operating model to verify | Proof required before approval |
|---|---|---|---|---|
| AWS DMS and DMS Schema Conversion | AWS-targeted migrations that need schema assessment/conversion plus a full load and, where supported, change data capture (CDC). DMS Schema Conversion can assess source metadata and export or apply converted SQL; AWS DMS moves data separately. | Conversion output still needs review, and support is path-specific. A schema conversion is not evidence that application behavior or every database object is compatible. | DMS has on-demand and serverless capacity models. AWS says schema conversion is free to use apart from Amazon S3 storage; estimate migration capacity, log storage, regions, and data transfer. | An assessment report with every manual item owned; restart/recovery rehearsal; source-to-target validation for the final load; critical application transactions on the target. |
| Azure Database Migration Service | SQL Server modernization into Azure SQL Database, Azure SQL Managed Instance, or SQL Server on Azure VMs, where the documented scenario supports the chosen online or offline route. Microsoft lists schema migration and private endpoints in the current portal service. | It does not remove the need to remediate source compatibility issues. Current documentation also shows some scenario limits, such as no TDE support in the listed service comparison. | Managed Azure service. Use the current Microsoft tools matrix and pricing calculator for the exact source, target, region, and target-service bill. | A supported-scenario check, remediation list, connectivity test, and a cutover rehearsal showing how writes are stopped or synchronized. |
| SQL Server Migration Assistant (SSMA) | Moving from Access, Db2, MySQL, Oracle, or SAP ASE into SQL Server, Azure SQL Database, or Azure SQL Managed Instance. It is a Microsoft conversion/migration tool for a defined target family. | It is a poor fit when PostgreSQL or another non-Microsoft target is the destination, or when the cutover requires an independently proven ongoing-replication path. | Microsoft provides the product download but no simple project-price figure on the product page. Budget target platform use, remediation effort, and any delivery support separately. | A converted-schema diff, a log of unsupported or changed objects, a representative data load, and business-owner acceptance of the reports and transactions affected. |
| Google Cloud Database Migration Service | Supported scenarios migrate into Cloud SQL or AlloyDB for PostgreSQL. Confirm the exact source, target, version, and migration type in Google’s supported-databases matrix before treating one-time migration, continuous migration, or conversion features as available. | It does not support a dual-write destination. Google’s documentation says the migrated destination becomes the primary after finalization, so bidirectional coexistence needs a different design. | Pay-as-you-go charges can include backfill and CDC, destination database resources, network, and any connectivity VM. Use the current price page for the selected path and region. | A supported-scenario confirmation, a tested conversion workspace where the path includes it, migration-job observability during a realistic load, and a final reconciliation after writes stop. |
| Ora2Pg | A free, GPL-licensed tool for Oracle-to-PostgreSQL-compatible schema and data export. It is useful when the team needs inspectable SQL output and can own execution, remediation, and the target environment. | It does not provide its own ongoing CDC import. Its CDC documentation says --cdc_ready records SCNs for a separate CDC tool rather than applying post-load changes itself. | Software licensing is not the budget line; account for engineering time, PostgreSQL infrastructure, a CDC component if downtime is tight, and support if required. | Generated SQL and code reviewed by target owners; object and row-count test output; data-validation result for a representative set; a separate CDC/restart plan if the source stays online. |
| Liquibase | Controlled, versioned database changes after the target is in service. Its role is database change management and drift/rollback control in delivery pipelines, not source-to-target migration. | It should not be selected as the bulk-transfer or CDC engine for a production database move. That is a different problem and needs a movement/replication design. | Community and commercial editions have different capabilities. Liquibase Secure’s current plans are quote-based, so obtain a written quote and confirm supported database types and support terms. | A versioned change log, tested rollback behavior for the target release, and a pipeline run against a production-like target. |
The fit judgments in this table are editorial synthesis from the linked product documentation. Vendor documentation establishes what a product says it supports; it is not independent proof of throughput, downtime, or conversion completeness.
Separate conversion, movement, replication, and release management
Buyers often use “database migration” to describe four different jobs. Treating them as one is how a tool selection becomes a cutover surprise.
- Schema conversion translates definitions and code: tables, types, views, routines, permissions, and sometimes vendor-specific features. AWS DMS Schema Conversion, SSMA, Google conversion workspaces, and Ora2Pg can contribute here, but each has a defined target scope and unresolved objects must be reviewed.
- Bulk movement copies an initial consistent dataset. A one-time dump and load may be appropriate when the source can stop accepting writes. It is not an online migration simply because the copy completes quickly.
- CDC or ongoing replication captures source changes after the initial load. AWS DMS and Google Cloud DMS document this model for supported scenarios. CDC reduces the cutover window; it does not eliminate a final synchronization, validation, or traffic-switch decision.
- Release-time schema change management controls later changes to the target database. Liquibase belongs here. It can be part of the delivery controls after migration, but it does not replace a source-to-target movement plan.
For example, an Oracle-to-PostgreSQL program may use Ora2Pg or a cloud conversion feature to expose conversion work, a supported CDC tool to keep the target current, and Liquibase to govern later target releases. That is a composed solution, not a claim that one product performs all four jobs. The Oracle to PostgreSQL migration guide covers the source-target decision in more depth.
Choose by source, target, and downtime constraint
The first procurement screen is compatibility, not a feature checklist. Ask the vendor or platform owner to name the exact source version, target edition, authentication pattern, network route, encryption requirement, and database objects in scope. “Supports Oracle” is incomplete if the target is a particular managed PostgreSQL service, the source has PL/SQL packages, or the workload cannot pause writes.
If the workload accepts a maintenance window, prefer a rehearsable offline path when it reduces moving parts. Require a consistent source point, an import record, and a time-bounded validation plan. If writes must continue, require a documented CDC prerequisite and a recoverable position: the log/SCN/LSN position, who owns it, what happens after a network failure, and how the team proves that the target caught up. Do not accept “minimal downtime” as an acceptance criterion. It describes an intended pattern, not the permitted interruption for a specific application.
Heterogeneous migrations add a second gate. Automated conversion is useful for surfacing scope, but target incompatibilities need explicit ownership. AWS’s assessment report, Google’s conversion workspace for a supported path, SSMA’s conversion output, and Ora2Pg’s generated SQL can each make that work visible. The acceptance artifact is the reviewed exception list: object, impact, remediation, owner, test, and disposition. A conversion percentage without that list has little procurement value.
Price the operating path, not the product name
Migration pricing often has a small visible line item and a larger operational bill. For AWS DMS, current pricing distinguishes on-demand instances, serverless capacity, storage, and applicable transfer; schema conversion has a separate storage-only cost model. Google Cloud DMS documents backfill and CDC charges alongside destination, network, and possible connectivity-VM costs. Microsoft’s paths differ by source and target, so the current scenario matrix is a better starting point than a generic Azure estimate. Ora2Pg shifts more of the cost into engineering and the surrounding platform. Liquibase Secure publishes plan scope but asks buyers to get a quote.
Build the estimate from a testable bill of materials: source and target hosting, tool capacity or data volume, log retention, network egress, encryption/key management, temporary environments, support, and the people who resolve conversion issues and sign off validation. Mark unquoted items as unknown. Do not turn a free download, an open-source license, or a no-upfront-commitment model into a claim that the migration is free.
Require a proof-of-concept that can reject the tool
Run the proof of concept on a bounded but difficult slice: a schema with stored code or unusual types, enough data to expose transfer behavior, and a write pattern close to the intended cutover. Give each exit test an owner before the tool is configured.
| Migration phase | Evidence to request | Disqualifier or escalation trigger |
|---|---|---|
| Discovery and conversion | Supported-path confirmation; assessment or conversion report; reviewed list of objects needing manual work | A critical object type is unsupported, or the supplier cannot explain how the exception will be implemented and tested. |
| Initial load | Source position, extracted/loaded/rejected counts, restart procedure, and logs from a forced interruption | The run cannot resume from a known consistent position, or rejects cannot be reconciled to a named rule. |
| CDC and cutover | Documented prerequisites, lag telemetry, final synchronization sequence, and a named write-freeze or drain owner | The team cannot show how changes are ordered, when the target is caught up, or how a failed cutover returns to the source. |
| Acceptance | Schema/object comparison, reconciled business totals, critical transaction and report tests, security/access checks | Row counts pass but a business workflow, report, permission, or recovery gate fails. |
Use this comparison to shortlist migration products. Then use the database migration testing strategies guide to design the wider test program, and data migration rollback planning to build the recovery runbook. Neither should be replaced by a tool dashboard.
A practical shortlist method
Create one scorecard per source-target pair rather than one enterprise-wide product ranking. Eliminate a tool when the official compatibility documentation does not cover the path, the source cannot meet its CDC prerequisites, or its recovery and validation evidence fails the proof of concept. For the remaining candidates, compare the manual-conversion backlog, operational ownership, required supporting components, and the costed bill of materials.
The next useful buying step is to turn that scorecard into a migration plan with clear acceptance owners. The data modernization services guide explains the engagement decisions around scope and governance. Read our methodology for how this site evaluates evidence. This article was researched on August 30, 2026 and should be reviewed quarterly, or sooner when a product changes compatibility, pricing, or support terms.
Chief Analyst, Software Modernization Intelligence · 10+ years B2B market research
Published: