What are data migration tools?

Data migration tools move data from one system to another as a project with an end date, rather than keeping two systems in agreement forever. They fall into four groups. Cloud-vendor services such as AWS Database Migration Service and Azure Data Factory. Warehouse-focused ELT vendors such as Fivetran, Airbyte and Adapters. Specialist schema-conversion tools such as the AWS Schema Conversion Tool and pgloader. And hand-written scripts, which is still how a large share of migrations actually happen.

What is the difference between data migration and data integration?

A migration ends and an integration does not. A migration moves a defined set of data to a new home, runs a cutover, and is then decommissioned. An integration keeps two live systems in agreement indefinitely. The distinction matters commercially because migration tooling is often priced per project or per hour of compute, while integration tooling is priced as an ongoing subscription. Buying the wrong one means paying a monthly fee for something you needed for six weeks.

What are the main types of data migration?

Five, and they need different tools. Database migration moves between database engines. Storage migration moves the same data to new hardware or a new cloud. Application migration moves the data behind a replaced business system. Cloud migration moves an estate from on premises to a cloud provider. Data center migration moves everything at once. The hardest is heterogeneous database migration, meaning source and target engines differ, because types and identifier rules do not line up.

How long does a data migration take?

The copy is rarely the long part. Moving a terabyte between cloud regions is hours. Agreeing what the data means, mapping types that have no exact equivalent, reconciling row counts, and getting the business to sign off on a cutover window is weeks to months. Teams that estimate from data volume alone underestimate consistently. Estimate from the number of distinct source tables and the number of people who must approve the result.

How do I migrate a database with zero downtime?

With change data capture, not with a bigger export. You take a consistent snapshot of the source, load it into the target, then stream the changes that happened during the load until the target is caught up. Once the lag is near zero you stop writes for seconds rather than hours, let the last changes drain, and repoint the application. The snapshot alone is not enough, because the source keeps changing while it copies.

What usually goes wrong in a data migration?

Silent truncation, almost always. A number loses its cents because the target column was created with the wrong scale, a string is cut because the target has a smaller maximum length, or a timestamp loses its offset and drifts by an hour twice a year. None of these raise an error. The job reports success and the damage is found weeks later during a reconciliation, which is why row counts and column totals must be compared after every load.

How do you validate a data migration?

By comparing totals, not by reading the job status. Count rows per table on both sides. Sum every numeric column that represents money or quantity and compare to the cent. Check the minimum and maximum of every date column, which catches timezone shifts instantly. Then spot check the records at the extremes, because the longest string and the largest number are the two rows most likely to have been truncated.

What is a data migration strategy?

A written decision about three things: whether you move everything at once or in phases, whether the old system stays readable after cutover, and how you get back if the cutover fails. Big bang migrations are cheaper and riskier. Phased migrations run both systems in parallel, which costs more and lets you stop. The rollback plan is the part most often skipped and the only part that matters at two in the morning.

Should you migrate historical data or only current data?

Move what someone will actually query, and archive the rest somewhere cheap and readable. Full history sounds safer and is where migrations go over budget, because old data is where the schema changed, the encoding is inconsistent, and the business rules no longer apply. A common compromise is migrating two to three years into the live system and dropping everything older into object storage as Parquet.

How much do data migration tools cost?

The tool is usually the cheapest line. Cloud migration services bill by the hour of replication compute plus egress, ELT vendors bill by rows or credits, and consultancies bill by the day. The dominant cost in almost every migration is people, specifically the time spent mapping fields and validating results. When comparing quotes, price the whole project including validation, not the per-gigabyte transfer rate.

Data Migration Tools - Database, Cloud, Cost

Which data migration tool should you use?

Pick by what happens after the migration ends. If you are moving a database into AWS and then switching the source off, AWS Database Migration Service does the full load and the change capture and you stop paying when you delete the instance. If the target is BigQuery and the source is MySQL, Postgres or Oracle, Datastream is the shortest supported path. If the source database is full of stored procedures, the real work is code conversion and you want the AWS Schema Conversion Tool or a consultancy, not a data pipeline. If you need lineage and audit evidence for a regulator, that is Informatica territory. And if the old system does not actually switch off, which is the most common case of all, you are buying an ongoing integration rather than a migration, and a flat monthly sync with retries and alerting will cost less than a metered tool running forever.

The correction worth making early: every comparison in this category ranks tools by connector count and supported engines, and almost none of them mention type mapping. That is backwards. Two tools that both claim SQL Server to PostgreSQL support will produce different results, because one maps MONEY to PostgreSQL NUMERIC(19,4) and the other maps it to the PostgreSQL MONEY type, whose display depends on a server setting. Neither raises an error. For the ongoing case rather than the one-time move, start with best data integration tools, or change data capture tools if you need a near-zero-downtime cutover. The single hardest route in this category, because the code conversion dwarfs the data movement, is covered on Oracle to PostgreSQL migration tools.

Data migration tools compared

Billing units rather than price tags. Migration pricing is usage based or quote based, so any figure we print goes stale within a quarter. The one flat published figure below is ours. Verify current pricing with each vendor before you sign anything.

Comparison of 12 data migration and database migration tools by owner, approach, best fit, pricing model and main caveat
Tool	Owner	Approach	Best for	Pricing model	Watch out for
AWS Database Migration Service	Amazon Web Services	Managed replication instance doing full load plus ongoing change capture	Moving into or across AWS, especially Oracle or SQL Server to Aurora Postgres	Per hour of replication instance plus storage and data transfer	Schema conversion is a separate tool, and the instance bills while it idles
AWS Schema Conversion Tool	Amazon Web Services	Converts schema and stored procedure code between engines	Heterogeneous migrations where the source has meaningful procedural code	No license charge, you pay for the infrastructure it runs against	Produces an assessment report, not a finished migration. Manual work remains
Azure Data Factory	Microsoft	Pipeline orchestration with copy activities and mapping data flows	Estates already standardized on Azure and needing orchestration too	Per pipeline activity run, per integration runtime hour and per data flow hour	Cost is genuinely hard to forecast before you have run a realistic load
Google Datastream	Google Cloud	Serverless change data capture from MySQL, Postgres and Oracle into BigQuery	Continuous replication into BigQuery with minimal operational overhead	Per gigabyte processed	Source configuration is strict. Binary logging settings must be exactly right
Fivetran	Fivetran	Managed ELT with a large prebuilt connector catalog	Ongoing SaaS and database replication into a warehouse after the migration	Monthly active rows, with monthly active transformations charged separately	A one-time historical backfill can produce an unusually large first invoice
Airbyte	Airbyte	Open source ELT with a very large community connector catalog	Teams happy to self host and to maintain connectors themselves	Free self hosted, or credit based on Airbyte Cloud	Connector quality varies widely because much of the catalog is community built
pgloader	Open source	Command line loader that migrates MySQL and SQL Server into PostgreSQL	One-off engine migrations into Postgres where a script is proportionate	Free	No scheduling, no monitoring and no ongoing sync. It is a tool, not a platform
Matillion	Matillion	Warehouse-native transformation and load, pushing work down to the warehouse	Heavy transformation during the move into Snowflake, BigQuery or Redshift	Credit based, consumed by running pipelines	You still pay the warehouse for the compute the pushdown consumes
Informatica	Informatica	Enterprise data management with migration, quality and governance modules	Regulated estates that need lineage and governance evidence, not just a copy	Consumption units, quoted annually	Substantial platform and a real learning curve for a single migration project
Talend	Qlik	Graphical job design with a large component library and data quality tooling	Complex mapping logic that benefits from being drawn rather than coded	Subscription per developer seat and per runtime	Seat based pricing suits a small team of specialists, not occasional users
Hand written scripts	You	Python or SQL doing the extract, transform and load directly	A small number of tables where the logic is genuinely unusual	Free to write, then paid for in maintenance forever	Retries, resumability, logging and alerting are the parts nobody budgets for
Adapters	Adapters	No-code field mapping with scheduled incremental sync, retries and per-record logs	Migrating then continuing to sync a defined set of databases, warehouses and apps	Flat monthly price from $49, not metered by rows or tasks	A fixed connector catalog. If your source is not on it, we are the wrong tool

The column a table cannot show you is what happens in week six, when a source column turns out to contain values nobody documented. Ask every vendor on this list to show you what a rejected record looks like in their interface and how you replay it after fixing the mapping. If you are evaluating one of these specifically, we keep honest write-ups of Fivetran, Airbyte, Matillion, Informatica and Talend.

The type conversions that quietly lose data

Eight conversions where the obvious target is the wrong one. Each was read from the relevant vendor's own type documentation. None of them raise an error when they go wrong, which is exactly why they are worth checking before the first load rather than after the reconciliation fails.

Source type, correct target type, common wrong target and the reason it loses data
Source	Correct target	Common wrong target	Why it matters
SQL Server MONEY	PostgreSQL NUMERIC(19,4)	PostgreSQL MONEY	The PG MONEY type formats according to the database lc_monetary setting, so the same stored value reads differently on another server
SQL Server DATETIMEOFFSET	PostgreSQL TIMESTAMPTZ	TIMESTAMP	DATETIMEOFFSET is the only SQL Server date type carrying an offset. Every other one maps to plain TIMESTAMP, and promoting them invents a timezone
SQL Server TINYINT	PostgreSQL SMALLINT	A one byte type	PostgreSQL has no single byte integer. SMALLINT is the smallest correct home
SQL Server UNIQUEIDENTIFIER	PostgreSQL UUID	VARCHAR(36)	Storing a UUID as text costs more space and loses index efficiency and validation
Any currency amount	Snowflake NUMBER(18,2)	Snowflake NUMBER	Snowflake NUMBER defaults to (38,0), meaning zero decimal places, so it silently truncates every cent on the way in
Any currency amount	BigQuery NUMERIC	BigQuery FLOAT64	FLOAT64 cannot represent decimal fractions exactly, so totals drift. NUMERIC gives 38 digits of precision and 9 of scale
Long text column	Redshift VARCHAR sized in bytes	A character-count sized VARCHAR	Redshift VARCHAR maxes at 65,535 bytes and multibyte characters consume several bytes each, so a column sized by character count overflows
API timestamp with offset	PostgreSQL TIMESTAMPTZ	TIMESTAMP	Dropping the offset makes an incremental watermark drift by an hour twice a year, which quietly duplicates or skips rows at every clock change

One more rule that catches everyone at least once. Identifier case folding is not consistent across warehouses: Redshift and PostgreSQL fold unquoted identifiers to lowercase, and Snowflake folds them to uppercase. A migration script that works perfectly against one target returns nothing against the other, and the error looks like missing data rather than a naming problem. Pick a convention before the first load. Route-specific walkthroughs live on SQL Server to PostgreSQL migration and MySQL to Postgres migration. The unsigned integers and zero dates on that route get their own tool comparison on MySQL to PostgreSQL migration tools, and the money, GUID and rowversion traps on the Microsoft route are compared on SQL Server to PostgreSQL migration tools. When the destination is a warehouse rather than another operational database, the binlog prerequisites and the boolean problem are compared on MySQL to Snowflake migration tools. Where the destination is a warehouse rather than another transactional database, the constraint model changes completely and the comparison moves to SQL Server to Snowflake migration tools.

Six migration failures that report success

Every one of these leaves a job marked complete and a target that is wrong. They are found weeks later, during a reconciliation, by somebody who is not the person who ran the migration.

Silent data migration failures with their signal, cause and the check that catches each one
Failure	What you see	Cause	The check that catches it
Money loses its cents	No error. Totals are slightly low	Target numeric column created with zero scale, most often Snowflake NUMBER left at its (38,0) default	Sum every money column on both sides and compare to the cent
Long strings are cut	No error, or the whole table fails	Target VARCHAR shorter than the longest source value. Redshift fails the table unless TRUNCATECOLUMNS is set, which then truncates silently instead	Compare the maximum length of every text column before and after
Timestamps shift by hours	No error. Daily counts move between days	An offset-carrying source type mapped to a target type without a timezone	Compare the minimum and maximum of every date column
Rows are missing entirely	No error. The job reports success	A paging ceiling reached, or in Redshift zero-ETL a source table with no primary key, which is simply not replicated	Compare row counts per table, every run, automatically
Case sensitivity breaks joins	Queries return nothing	Redshift and Postgres fold unquoted identifiers to lowercase while Snowflake folds to uppercase, so a script that worked on one fails on the other	Decide a case convention before the first load, then quote consistently
Schema changes never arrive	New columns are absent	PostgreSQL logical replication does not replicate DDL, sequence values or large objects. Only table rows	Version the schema separately and alert on column count changes

The pattern across all six is the same: the migration tool did exactly what it was told, and what it was told was wrong. No amount of retry logic helps, because nothing failed. The only defense is comparing totals between source and target after every load and alerting when they move apart.

Six limits worth knowing before you size the job

65,535

Byte ceiling on a Redshift VARCHAR

Content above it fails the whole table unless TRUNCATECOLUMNS is enabled, which then silently truncates instead. Sized in bytes, not characters. AWS documentation, read 16 August 2026.

(38,0)

Snowflake NUMBER default precision and scale

Zero decimal places by default, so every currency column declared as a bare NUMBER loses its cents with no warning. Use NUMBER(18,2). Snowflake documentation, read 13 August 2026.

1,500

BigQuery load jobs per table per day

A migration that loads one small file per table per minute exhausts the daily quota before lunch. Batch into larger files. Google Cloud documentation, read 15 August 2026.

128 MB

Redshift automatic file split threshold

Uncompressed CSV and columnar Parquet at or above this size are split automatically. GZIP CSV and JSON load serially, so split those by hand. AWS documentation, read 16 August 2026.

100 to 250 MB

Snowflake recommended load file size, compressed

Files above 100 GB are explicitly not recommended, and the default COPY timeout is 24 hours. Snowflake documentation, read 13 August 2026.

500M

Datastream row threshold needing a unique index

Backfilling a MySQL table larger than 500 million rows requires a unique, non-null index, and binary logging must be ROW format with FULL row images. Google Cloud documentation, read 15 August 2026.

All six read from the vendors' own documentation on the dates shown. Numbers we deliberately do not print anywhere on this page are the list prices of AWS DMS, Azure Data Factory, Fivetran, Informatica or Talend for your workload, because all of them are usage or quote based and any figure would be invented. If a comparison page quotes you an exact monthly cost for a migration tool without knowing your row counts, treat the rest of that page with the same suspicion.

How to run a data migration that reconciles at the end

Step 01 / Inventory

Count tables and owners before you count gigabytes

Volume determines how long the copy runs. The number of distinct tables, and the number of people who must agree what each one means, determines how long the project runs. Produce a list of every source table with a named owner and a decision about whether it moves, gets archived, or dies. The tables nobody will claim are usually a third of the estate, and deleting them is the single cheapest win available in any migration.

Step 02 / Map types

Decide every type mapping explicitly, in writing

This is where migrations lose data, and it happens quietly. Automatic type inference picks the obvious target, and the obvious target is wrong for money, for timestamps with offsets, and for anything near a length ceiling. Write the mapping table down and review it with someone who knows both engines. The table further down this page covers the conversions that most commonly go wrong between SQL Server, PostgreSQL, Snowflake, BigQuery and Redshift.

Step 03 / Load once

Run a full rehearsal against production-sized data

A rehearsal against a thousand sample rows proves the mapping compiles. It does not prove the migration works, because every interesting failure in this category is triggered by scale or by the unusual record. Load the real volume into a throwaway target, time it, and keep the timings. That number is what you will use to negotiate the cutover window, and a guess is not good enough when the business is offline while it runs.

Step 04 / Reconcile

Compare totals, not job statuses

A job that reports success has proven that requests returned without exceptions. It has not proven that the data arrived intact. Count rows per table. Sum every money and quantity column. Check minimum and maximum dates. Then inspect the records at the extremes, because the longest string and the largest number are the rows most likely to have been truncated. Automate this comparison so it runs on every load rather than once at the end.

Step 05 / Cut over

Stream changes so the outage is seconds, not hours

Take the snapshot, load it, then apply the changes that occurred during the load using change data capture until replication lag is near zero. Now stop writes, let the last few seconds drain, verify, and repoint the application. The outage is the drain time rather than the copy time. Keep the source readable and writable for a rollback window afterwards, and decide in advance what evidence would make you use it.

Step 06 / Keep running

Decide what stays connected after the project ends

Most migrations are not clean replacements. The old system keeps feeding something, or a downstream report still reads the source, or a second system needs the same data continuously. That leftover requirement is an integration, not a migration, and it needs different tooling with schedules, retries and alerting. Deciding this at the start avoids discovering in week ten that the migration tool you bought cannot run on a schedule.

The migrations teams actually run

SQL Server to PostgreSQL

The most common license-driven migration. The work is in the type mapping and the stored procedures, not the row copy. MONEY, DATETIMEOFFSET, TINYINT and UNIQUEIDENTIFIER all need deliberate targets.

On premises database to a cloud warehouse

Moving reporting off the transactional database into Snowflake, BigQuery or Redshift. The trap is file sizing and identifier case, both of which differ by warehouse and both of which are easy to get wrong once.

Warehouse to warehouse

Redshift to Snowflake, Snowflake to BigQuery, BigQuery to Snowflake. Identifier folding is opposite between Snowflake and the others, and numeric defaults differ, so scripts do not port unchanged.

MySQL to PostgreSQL

Usually driven by a need for stricter typing and better extensions. Character sets, zero dates and unsigned integers are the three recurring problems, and none of them announce themselves.

Accounting system replacement

Moving a ledger between accounting platforms. Historical balances, chart of accounts mapping and reconciling to a known period close matter far more than throughput here.

Migration then ongoing sync

The very common case where the old system does not switch off. You need a one-time move plus a scheduled incremental sync afterwards, which is two different jobs on the same field mapping.

Each of these has a dedicated walkthrough: SQL Server to PostgreSQL, SQL Server to Snowflake, MySQL to Postgres and its tool and type conversion comparison, Redshift to Snowflake, Snowflake to BigQuery, BigQuery to Snowflake and QuickBooks to Xero.

When another data migration tool is the right answer

We would rather you buy the correct thing than churn in month three. Five situations where Adapters is not what you want.

You need stored procedure conversion

If the source database holds thousands of lines of T-SQL or PL/SQL business logic, the hard part is translating code, not moving rows. The AWS Schema Conversion Tool or a specialist consultancy is the right answer. We map fields between systems and we do not convert procedural code.

It is a genuine lift and shift of an entire data center

Moving hundreds of servers and their storage is an infrastructure programme with physical transfer appliances and network planning. Cloud vendor migration programmes exist precisely for this and they are the correct tool.

Your source is not in our catalog

We support a fixed, tested set of databases, warehouses and business applications. If your source is a mainframe, a bespoke internal system or a niche vertical application, an open catalog like Airbyte or a custom script will get you there and we will not.

You need governance evidence for a regulator

When the deliverable includes documented lineage, data quality scoring and audit artifacts for a compliance review, that is what Informatica and similar enterprise platforms are built to produce. Our logs are operational, not a governance package.

It is one table, once

If you are moving a single table one time, a CSV export and a COPY command is twenty minutes of work. Buying anything for that, including us, is not worth the procurement conversation.

Four questions worth asking every vendor

Does the price change if the migration takes twice as long as planned?

Usage-metered tools bill for the overrun, and migrations overrun routinely. Ask specifically what a doubled timeline costs, because that is the realistic case rather than the pessimistic one.

Can it run a full backfill and an incremental sync on the same mapping?

If those are two separate configurations, they will drift apart, and the drift shows up as duplicated or missing rows at cutover. One mapping serving both is what you want.

What happens to a single bad record?

The answers range from failing the whole batch to skipping it silently. Skipping silently is the dangerous one. You want the record quarantined, logged, visible and replayable without rerunning everything.

Who gets told when a load fails at three in the morning?

Ask to see the alert, not the dashboard. A dashboard nobody is looking at during a cutover weekend is not monitoring, and this is the question that separates tools that survive month one.

Where to go next

If the source and target keep running after the move, you need an integration rather than a migration. These cover both sides of that line.

Change data capture tools

The mechanism behind a near-zero-downtime cutover, and the tools that implement it.

Best data integration tools

The wider category, for when the two systems have to stay in agreement permanently.

Best iPaaS platforms

When the requirement is business applications agreeing with each other, not databases.

Snowflake ETL tools

Loading mechanics, file sizing and the numeric defaults that truncate money.

BigQuery ETL tools

Load job quotas, file size ceilings and why money belongs in NUMERIC.

Postgres ETL tools

Logical replication, what it does not replicate, and how to load Postgres properly.

Redshift ETL tools

Zero-ETL constraints, the VARCHAR byte ceiling and COPY file splitting.

What data integration really costs

The ongoing side of the budget, broken down by pricing model.

All connectors

Every source and target pair we support, with the field mapping for each.

Questions buyers ask about data migration tools

What are data migration tools?: Data migration tools move data from one system to another as a project with an end date, rather than keeping two systems in agreement forever. They fall into four groups. Cloud-vendor services such as AWS Database Migration Service and Azure Data Factory. Warehouse-focused ELT vendors such as Fivetran, Airbyte and Adapters. Specialist schema-conversion tools such as the AWS Schema Conversion Tool and pgloader. And hand-written scripts, which is still how a large share of migrations actually happen.
What is the difference between data migration and data integration?: A migration ends and an integration does not. A migration moves a defined set of data to a new home, runs a cutover, and is then decommissioned. An integration keeps two live systems in agreement indefinitely. The distinction matters commercially because migration tooling is often priced per project or per hour of compute, while integration tooling is priced as an ongoing subscription. Buying the wrong one means paying a monthly fee for something you needed for six weeks.
What are the main types of data migration?: Five, and they need different tools. Database migration moves between database engines. Storage migration moves the same data to new hardware or a new cloud. Application migration moves the data behind a replaced business system. Cloud migration moves an estate from on premises to a cloud provider. Data center migration moves everything at once. The hardest is heterogeneous database migration, meaning source and target engines differ, because types and identifier rules do not line up.
How long does a data migration take?: The copy is rarely the long part. Moving a terabyte between cloud regions is hours. Agreeing what the data means, mapping types that have no exact equivalent, reconciling row counts, and getting the business to sign off on a cutover window is weeks to months. Teams that estimate from data volume alone underestimate consistently. Estimate from the number of distinct source tables and the number of people who must approve the result.
How do I migrate a database with zero downtime?: With change data capture, not with a bigger export. You take a consistent snapshot of the source, load it into the target, then stream the changes that happened during the load until the target is caught up. Once the lag is near zero you stop writes for seconds rather than hours, let the last changes drain, and repoint the application. The snapshot alone is not enough, because the source keeps changing while it copies.
What usually goes wrong in a data migration?: Silent truncation, almost always. A number loses its cents because the target column was created with the wrong scale, a string is cut because the target has a smaller maximum length, or a timestamp loses its offset and drifts by an hour twice a year. None of these raise an error. The job reports success and the damage is found weeks later during a reconciliation, which is why row counts and column totals must be compared after every load.
How do you validate a data migration?: By comparing totals, not by reading the job status. Count rows per table on both sides. Sum every numeric column that represents money or quantity and compare to the cent. Check the minimum and maximum of every date column, which catches timezone shifts instantly. Then spot check the records at the extremes, because the longest string and the largest number are the two rows most likely to have been truncated.
What is a data migration strategy?: A written decision about three things: whether you move everything at once or in phases, whether the old system stays readable after cutover, and how you get back if the cutover fails. Big bang migrations are cheaper and riskier. Phased migrations run both systems in parallel, which costs more and lets you stop. The rollback plan is the part most often skipped and the only part that matters at two in the morning.
Should you migrate historical data or only current data?: Move what someone will actually query, and archive the rest somewhere cheap and readable. Full history sounds safer and is where migrations go over budget, because old data is where the schema changed, the encoding is inconsistent, and the business rules no longer apply. A common compromise is migrating two to three years into the live system and dropping everything older into object storage as Parquet.
How much do data migration tools cost?: The tool is usually the cheapest line. Cloud migration services bill by the hour of replication compute plus egress, ELT vendors bill by rows or credits, and consultancies bill by the day. The dominant cost in almost every migration is people, specifically the time spent mapping fields and validating results. When comparing quotes, price the whole project including validation, not the per-gigabyte transfer rate.

The full cost breakdown for a migration project, including the people time that dominates it, is in what a data migration really costs. For the difference between moving data once and moving it continuously, see ETL vs ELT. The route with the most measured demand of any on this site is covered separately in Postgres to Snowflake migration tools, where Snowflake publishes two conflicting type mappings for the same columns. The route with the largest license question attached to it, because Snowflake's own connector reads through Oracle XStream, is on Oracle to Snowflake migration tools.

Data migration tools compared: database migration tools, cloud data migration tools, and what data migration software costs