Data migration cost: what a database migration really costs, the pricing models every vendor uses, and the line item that dominates the budget

Aug 29, 2026 9 min read Cost The Adapters team

Last updated September 2026

Input

Output

Field mapping auto-plugged · tap a port to rewire

5 sample records ready

The tool is almost never the expensive part of a data migration. Cloud migration services bill per replication hour, ELT vendors bill per row, consultancies bill per day, and every one of those lines is usually smaller than the time people spend mapping fields and proving the result is correct. Anyone quoting you a migration cost from a per-gigabyte rate is pricing the cheapest component. Here is what each pricing model does when a project runs long, which lines actually dominate the budget, and how to build an estimate that survives contact with the data.

Key takeaways

People cost more than tools. Mapping fields and validating results is the bulk of a migration budget, and neither scales down with a cheaper vendor.
The pricing model matters more than the rate. Per-hour and per-day models bill the overrun. Flat and per-seat models do not.
Row-metered tools charge for the backfill. On a monthly-active-rows plan, the historical load often makes the first invoice the largest you will ever see.
Validation is the line most often left out. Proving the target matches the source, column by column, is real work and it is where finished-looking migrations come undone.
The old system rarely switches off. Budget for the ongoing integration that outlives the project, because it is permanent and the migration was not.
Deleting data is the biggest single saving. Archiving history you will not query shrinks every other line at once.

How much does a data migration cost?

There is no credible per-gigabyte figure, and any vendor offering one is pricing the part of the project that matters least. A migration's cost is driven by the number of distinct source tables, the number of people who have to agree what each one means, and how much validation the business requires before it will sign off. Two migrations moving identical data volumes can differ by an order of magnitude on those three variables alone.

The practical way to get a number is to price the components separately rather than looking for a single rate. Tool or service fees are usually the smallest line. Engineering time for mapping and rehearsal is substantial. Validation and reconciliation is frequently the largest, and it is the one most often missing from the first estimate. Add parallel infrastructure for however long both systems run together, then add the ongoing cost of whatever keeps syncing after cutover, because in most projects something does.

What pricing models do data migration tools use?

Nine models, and the difference between them only becomes visible when the timeline slips. That is the comparison worth making, because migrations overrun as a matter of routine. Every entry below describes the billing unit rather than a price, because these vendors price by usage or by quote and any figure printed here would be invented and would go stale within a quarter.

Data migration pricing models, who uses them, how predictable they are and how each behaves when a project overruns
Pricing model	Typically used by	Predictable?	If the project overruns	Suits
Per replication hour	AWS Database Migration Service	Only if the timeline is	Bills the whole overrun. An idle instance left running after cutover keeps charging	Short, well scoped moves into AWS with a firm end date
Per gigabyte processed	Google Datastream	Yes, once volume is known	Largely flat, because the data volume does not grow just because the project did	Continuous replication where volume is stable and measurable up front
Per pipeline activity and runtime hour	Azure Data Factory	Poorly, before a real run	Compounds. More debugging runs means more activity charges	Estates already on Azure that can absorb some cost variance
Per row, or monthly active rows	Fivetran and similar ELT vendors	Yes for steady state	The historical backfill is charged, so the first invoice is often the largest by far	Ongoing sync after the migration, less so the one-time move
Credits consumed by running pipelines	Matillion, Airbyte Cloud	Moderately	Scales with reruns, and a failed load that gets repeated still consumes credits	Transformation-heavy loads where the work is genuinely variable
Per developer seat and runtime	Talend	Yes	Flat. Time overrun costs nothing extra in license terms	A small permanent team doing migrations repeatedly
Consumption units, quoted annually	Informatica	Contractually, yes	Fixed within the contract, but the contract is annual regardless of project length	Regulated estates needing governance artifacts alongside the move
Per consultant day	Systems integrators	No	Directly proportional. This is the line that grows fastest when scope moves	Migrations dominated by business logic rather than data movement
Flat monthly subscription	Adapters, from $49 a month	Yes	None. A longer project costs the same per month regardless of rows moved	A defined set of sources that keep syncing after the migration finishes

The row-metered case deserves a specific warning. On a monthly active rows plan, the historical backfill is charged like any other row, so moving five years of history produces an invoice that bears no relationship to the steady-state monthly cost you were quoted. This is not a hidden fee, it is how the model works, but it surprises buyers constantly because the sales conversation is about the ongoing number. Ask what the backfill costs as a separate question. The wider vendor comparison sits on data migration tools.

What are the main costs in a data migration?

Eight lines, and the two that dominate are both people rather than software. Sizes below are relative rather than absolute, because the absolute numbers depend entirely on the table count and the sign-off requirements. We are deliberately not printing percentage splits, since any split we invented would be presented as research and it would not be.

Data migration cost line items, who bears them, relative size and what drives each
Cost line	Borne by	Relative size	What drives it
Discovery and inventory	Your team, plus system owners	Small in money, large in calendar time	Listing every source table and finding an owner for each. Cheap to do and expensive to skip, because unowned tables become scope surprises later.
Field and type mapping	Engineers who know both systems	Substantial	The single most underestimated line. Every column needs a decision, and the ones that need thought are the ones that silently lose data if you get them wrong.
Tool or service fees	Vendor	Usually the smallest line	The number people compare vendors on, and rarely the number that decides the budget. Worth optimizing only after the people costs are understood.
Rehearsal runs	Engineering plus infrastructure	Moderate and repeated	Full-volume rehearsals cost compute and storage each time. Budget for several, because the first one always reveals something.
Validation and reconciliation	Engineering plus finance or ops	Often the largest line	Proving the target matches the source, column by column. This is where migrations that looked finished turn out not to be.
Parallel running	Infrastructure, both systems	Duplicate infrastructure cost	Running old and new together during the transition. Safer than a big bang, and you pay for both estates for the duration.
Cutover and contingency	Everyone, usually a weekend	Concentrated	Overtime, standby staffing and the cost of the outage window itself. Small if rehearsed properly, brutal if not.
Post-migration sync	Whoever owns the leftovers	Ongoing and permanent	The old system usually does not switch off cleanly. This becomes an integration bill that outlives the migration project entirely.

Why do data migrations go over budget?

Because the estimate was built from data volume and the work is driven by data variety. A terabyte in twelve well-documented tables is a straightforward project. Eighty gigabytes spread across four hundred tables, half of which have no owner and several of which contain values that violate their own documented format, is not. The copy is fast in both cases. The disagreement about what the data means is what consumes the calendar.

The second cause is discovering a mapping error late. A migration that silently truncated money, dropped a timezone offset or cut long strings does not fail, it completes and reports success. When reconciliation catches it weeks later, you pay for the original load, the investigation, the fix, the reload and the rescheduled cutover. That is four extra costs generated by one decision made in an afternoon at the start, which is why the mapping deserves more scrutiny than the vendor selection.

Is it cheaper to build a data migration yourself?

For a handful of tables moved once, yes, clearly. A CSV export and a load command is an afternoon and buying anything for it is not worth the procurement conversation. The calculation changes when the migration has to be repeatable, because the parts that cost real time are not the extract and the load. They are retries, resumability after a failure halfway through, per-record error logs, and somebody being told when a run breaks.

Those components take longer to build well than the migration logic itself, and unlike the migration they never finish, because they need maintaining for as long as the pipeline runs. The honest test is whether this is genuinely a one-time move. If the source switches off permanently at cutover, a script is often the right economic answer. If anything keeps syncing afterwards, you have bought yourself a permanent maintenance obligation in exchange for avoiding a subscription.

How do you estimate a data migration budget?

Count tables, not gigabytes. Produce the inventory first, with a named owner per table and a decision about whether each one moves, gets archived or dies. Then estimate mapping effort per table, weighting the ones with money columns, timestamps and free text, since those are where the decisions are. Add rehearsal compute for several full-volume runs rather than one. Add validation as an explicit line rather than assuming it happens in the gaps. Add parallel infrastructure for the overlap period, and add the ongoing sync that follows cutover.

Then apply the pricing model test from the table above to whichever vendor you are considering, using a timeline of roughly double your plan. If the resulting number is acceptable, the estimate is robust. If it is not, the exposure is in the pricing model rather than in the plan, and switching to a model that does not bill for time is a cheaper fix than trying to make an optimistic schedule hold.

What does it cost to keep the old system running after migration?

More than most plans allow, and for longer. Parallel running means paying for two estates: licenses, infrastructure, backups and the staff attention both require. Teams budget this for the planned overlap and then extend it, usually because one downstream consumer has not been migrated and nobody wants to be the person who breaks it. Setting a hard decommission date at the start, with a named owner, is what stops a temporary overlap becoming a permanent second system.

Seven ways to reduce data migration cost

Delete before you move

The cheapest data to migrate is the data you decide not to migrate. Run the inventory first and be aggressive about it: tables nobody will claim, staging tables from projects that ended, history beyond what anyone queries. Archiving old records to object storage as Parquet keeps them readable for a fraction of the cost of carrying them into the new system, and it shrinks every subsequent line in this budget at once. In most estates this single decision removes a third of the work.

Fix the type mappings before the first full load

A rehearsal that loads correctly is cheap. A rehearsal that loads incorrectly and gets discovered during reconciliation costs the load, the investigation, the fix and the reload. The conversions that go wrong are predictable: money into a numeric type with zero scale, offset-carrying timestamps into a type without a timezone, and text into a column sized by character count when the target measures bytes. Decide those explicitly, in writing, before anything runs at volume.

Rehearse at full volume once, early

Teams rehearse against sample data because it is fast, then discover at cutover that the real volume behaves differently. Every interesting failure in a migration is triggered by scale or by the unusual record, and neither exists in a thousand-row sample. One full-volume rehearsal early gives you a real duration to negotiate the cutover window with, and turns the riskiest unknown in the project into a measured number.

Automate reconciliation instead of staffing it

Manual validation is the line that quietly consumes the most people time, and it does not scale with the number of tables. Write the comparison once: row counts per table, sums of every money and quantity column, minimum and maximum of every date column. Run it after every load rather than once at the end. The upfront cost is a day or two and it converts an open-ended manual effort into a job that either passes or does not.

Know what depends on a table before you move it

A migration that technically succeeds can still break a dozen downstream reports, dashboards and jobs nobody remembered were reading the old table. Those breakages arrive after cutover, when the project team has moved on, and they are charged to whoever is still around. Mapping which downstream assets depend on which tables is far cheaper before the move, and tracing those dependencies with a data lineage tool that reads the warehouse turns an archaeology exercise into a lookup.

Price the pricing model, not the headline rate

Compare vendors on how the bill behaves when the project takes twice as long, because that is the ordinary case rather than the pessimistic one. A per-hour replication service and a flat subscription can look similar on a six-week plan and diverge sharply on a fourteen-week reality. Ask each vendor directly what a doubled timeline costs, and ask what the historical backfill costs on a row-metered plan, because that first invoice surprises people every time.

Decide the post-migration state at the start

Most migrations do not end with the old system switched off. Something keeps feeding it, or a downstream report still reads it, or a second system needs the same data continuously. That leftover is an ongoing integration with its own permanent cost, and discovering it in week ten means buying a second tool under time pressure. Deciding it in week one lets one tool and one field mapping cover both the move and what follows.

Where this leaves you

Price the project, not the transfer. The vendor rate is the easiest number to obtain and the least useful one for deciding whether a migration is affordable, because it sits underneath two much larger lines that no vendor quotes: working out what the data means, and proving the copy is correct. Get the table inventory done, decide the type mappings explicitly, automate the reconciliation, and pick a pricing model that does not punish you for the overrun that is probably coming.

For the tool comparison itself, including how each option bills and where each one is the wrong choice, see data migration tools. For a near-zero-downtime cutover, the mechanism is change data capture. And for the ongoing spend that starts once the migration ends, we broke that down separately in what data integration really costs. Where the budget is driven by a licence renewal rather than by data volume, the numbers behave differently again, and that case is worked through on Oracle to PostgreSQL migration tools.

Move the data once, then keep it in sync on a flat monthly price

One field mapping serves the backfill and the incremental runs that follow, with retries, alerts and per-record logs. From $49 a month, never metered by rows.

Try the live demo

No credit card required.