Data migration cost: what drives the price of a move

You request quotes from two suppliers to move your data warehouse to the cloud, and the prices are very different. One supplier provides few details about testing, while the other includes several phases you did not expect. This price gap is usually not caused by the cost of the software. Instead, it reflects what each supplier believes the project requires.

Data migration cost is the total expense and effort required to transfer data between systems and verify its accuracy. This cost is determined by eight factors: data volume, the number of source systems, required transformations, reconciliation processes, downtime limits, the cut-over strategy, staff requirements, and post-migration support. Software and platform fees typically represent a small portion of the total budget. The majority of the cost usually comes from labour and personnel time.

This guide is for the person who has to set a budget for a migration and defend it: a head of data, a finance lead or a CTO. It explains the eight drivers that move the effort, how phased and big-bang cut-overs change the bill, why reconciliation is so often missing from quotes, and how to write a brief that produces a quote you can hold a supplier to. It explains what a price should be made of, not what any one supplier charges.

Shipshape Data migrates warehouses, databases and cloud estates onto a governed foundation, reconciled row by row. If you are still deciding whether to move at all, read cloud migration explained first, then come back to the budget.

Why migration quotes vary so much

Price differences between quotes usually result from the scope of work rather than hourly rates. A low quote often covers only the technical tasks, such as copying tables and connecting reports to a new system. A higher quote typically covers a complete outcome. This includes verifying that the new data matches the old data, transitioning all users, and decommissioning the original system. Both quotes can be accurate representations of two different types of service.

The type of migration you are purchasing

The type of migration determines the basic requirements. A storage migration involves moving files and volumes from one device or location to another. A database migration involves moving data between different database engines or versions. An application migration involves moving a system and its data together, which often includes changing vendors. A cloud migration involves moving any of these assets from local infrastructure to a cloud provider. A data warehouse migration typically involves several of these types because the warehouse receives data from multiple sources and provides data to many reports.

How public cost guides categorise expenses

Published guides split the cost in similar ways. Future Processing groups cloud migration costs into four areas: infrastructure setup, data transfer, application refactoring and post-migration expenses. DXC separates direct costs, which it lists as labour, consumption and software licensing, from indirect costs such as training and downtime. Both make the same point. The visible charges are tools and transfer. The larger charges are people time and disruption.

The tool charges are often modest. Google Cloud's Database Migration Service pricing page lists the first 500 gibibytes as free, then $0.40 per gibibyte, per month, per account above that. AWS states on its DMS pricing page that all data transfer into AWS DMS is free. These terms change and depend on configuration, so check them for your own case. They still show why transfer alone rarely explains a large gap between two quotes.

Moving the data is the cheap part. Proving it arrived correctly is where the effort sits.

The eight drivers of data migration cost

Each driver below moves effort, and effort is what you pay for. None of them works alone. A large volume of clean, simple data can cost less to move than a small volume spread across ten sources with years of workarounds.

Data volume

Data volume impacts transfer times, load windows, and storage requirements, but its greatest effect is on testing. Each rehearsal requires a data reload, and these reloads take more time as the volume increases. Costs do not usually scale linearly with volume. If the data structure remains unchanged, doubling the number of rows does not necessarily double the amount of work required. Historical data is as important as total size. You should decide early if you need to migrate every year of records or if you can archive some of them.

Number and type of sources

Each source system brings its own extraction method, data types, quirks and owner. A single modern database is a contained piece of work. Several legacy systems, spreadsheets that act as systems and a supplier feed with no documentation are not. Undocumented sources cost the most, because someone has to work out what the data means before anyone can move it.

Transformations and data quality

A straight copy between like-for-like systems needs little transformation. Most migrations are not like that. Data types change, business rules change, codes need mapping and duplicates need merging. Poor source quality becomes transformation work, because the move is the point where problems become visible. Budget for data cleaning as its own activity rather than hoping it fits inside the build.

Reconciliation

Reconciliation is the work of proving that the data in the new system matches the old one, record by record and total by total. It is the driver most often left out of quotes, and it has its own section below.

Downtime tolerance

If the business can pause operations for a weekend, the migration process is simpler. If the business must remain active, you will require change data capture, incremental loads, and a method to synchronise both systems during the transition. Reducing downtime increases the amount of engineering and testing work required. You should make this decision with business owners rather than only with IT, as it is a business choice that carries a technical cost.

Cut-over strategy

The cut-over strategy determines the number of times you move data or systems. In a big-bang cut-over, you move everything in a single event. In a phased cut-over, you move by domain, region, or system and repeat the process several times. This choice affects both the total cost and the timing of those expenses.

The team

The amount of effort required depends on the specific people performing the work and their existing knowledge. A team familiar with the source system will complete tasks more quickly than a team that needs to learn it. There is also a cost associated with using your own staff. Subject matter experts are required to explain the old data, test the new data, and provide formal approval. Suppliers rarely include this time in their quotes, but it is a real requirement that takes time away from the regular duties of your employees.

Aftercare

The project continues after the launch date. Users will likely identify conflicting reports, system errors will occur in untested scenarios, and you will need to adjust performance settings for actual workloads. If a contract ends at the cut-over date, you will be responsible for these costs. You should ask about the duration and specific terms of the support period.

Choosing between a phased or big-bang cut-over

Both approaches can work. The right one depends on how closely your systems are linked and how much risk the business can carry in a single window.

• The big bang approach involves moving everything in a single window. This method is less expensive to operate because it requires only one cut-over and avoids the need to synchronise two systems over a long period. It carries higher risk because all problems occur simultaneously and the rollback plan must account for the entire system.
• The phased approach moves data in stages based on business domain, region, or source. Each stage is smaller, which makes it easier to verify. This method has a higher total cost because it requires multiple rehearsals and cutovers. Additionally, the old and new systems must run simultaneously for a longer period.
• In a parallel run, both systems operate at the same time. You compare their outputs before you turn off the old system. This method provides the most confidence, but it has the highest running cost because you pay for two environments and two sets of checks.

Phasing is often the better choice for a complex estate, because the first phase tests the method and gives you real effort figures for the rest. A first phase that succeeds also makes the case for funding the next one. A cloud migration roadmap sets out how to sequence those stages and which workloads should move first.

Reconciliation: the line item people forget

Reconciliation is often excluded from project quotes because it does not create new features. When budgets are limited, stakeholders view it as an unnecessary check on work that is expected to be accurate. However, problems arise when the first financial report from a new system contradicts previous data, leaving staff unable to identify the error. Without reconciliation, you cannot confirm if a migration was successful. You only know that the process is complete.

What reconciliation involves

• Row counts per table and per load, compared between source and target.
• Calculate totals using business keys, such as monthly revenue or stock levels by site. This ensures that differences are presented in terms the business recognises.
• Field-level comparison, to catch truncation, rounding, encoding and date problems.
• A record of every difference, including the cause and the decision to fix, accept, or explain it.
• Get approval from the data owners, rather than only from the team responsible for the migration.

You should reconcile every rehearsal rather than only the final run. This process requires effort, but it also builds confidence. Our guide to data reconciliation describes these methods in detail, and our article on data lineage explains how to trace a discrepancy back to the specific step that caused it.

A migration is complete when the data totals are verified and the owners have provided formal approval, rather than when the final process finishes executing.

How it protects against data loss

Data loss in a migration is rarely a single dramatic event. It is usually a filter, a join or a type conversion that drops records without warning, and only reconciliation catches it. Keep the source system intact and read-only until reconciliation passes, take a full backup before cut-over, and keep a tested rollback plan until the new system has run for an agreed period.

Hidden costs after cut-over

Significant costs occur after the transition. These expenses are predictable and should be included in the initial budget.

• Dual running occurs when organisations continue to pay for the licences, hosting, and support of an old system while they gain confidence in a new one.
• Reports and integrations must be updated. Dashboards, data extracts, and downstream feeds that connected to the old system require rebuilding or reconfiguration. Some of these connections are only identified when they fail to function.
• Cloud platforms charge for compute and storage based on usage. Because of this pricing model, inefficient queries result in higher costs on your bill.
• Performance tuning: workloads function differently on new platforms and require adjustment under actual operating conditions.
• Training requires staff to learn new software and different methods for locating data. DXC includes these training requirements as an indirect cost of the migration process.
• Decommissioning and archiving: you must retire the old system correctly and keep all records for the duration required by your legal and regulatory obligations.

If you are moving reporting into a warehouse for the first time, it helps to understand how data warehousing changes the running cost, because the bill moves from servers you own to usage you pay for.

How to brief a migration for a real quote

A vague brief produces a vague quote, and a vague quote is where overruns start. The aim is a fixed-outcome quote: a price tied to a defined result rather than to hours spent. You can only get one if the result is defined.

What to include in the brief

• List each source system, its owner, its approximate size, and indicate if it is documented.
• Specify the platform you intend to use, or note that the decision is still pending.
• How much history must move, and what can be archived instead.
• The downtime the business will accept, agreed with the business owners.
• Indicate your preferred cut-over method, or request that the supplier suggest a method and explain their reasoning.
• Define the reconciliation standard, including the items that must match, the required level of detail, and the individual responsible for approval.
• Which reports, integrations and users must work on day one.
• Specify the duration and scope of support needed after launch.

Define done before you ask for a price

Write a definition of what finished means. A clear definition should list the data that was moved, the checks it passed, and the reports that operate. It also identifies the users who have switched and the date when the old system ceases operation. A supplier can price these specific requirements. A supplier cannot price "migrate the warehouse" without making a guess, and such guesses are either padded or wrong.

Pay for discovery first

If your sources are poorly documented, ask for a short discovery phase priced separately before receiving a main quote. That phase profiles the data, maps the sources, and tests a sample migration. The output provides a scope that you can use to hold a supplier accountable. The process also gives a clear point at which to stop the project. If discovery indicates the data is not ready for migration, you will learn this before spending the main budget.

Compare the quotes for each driver. If a quote omits costs for reconciliation, aftercare, or your staff's time, it is not cheaper. The provider has simply shifted those costs onto you.

What this means for you

Data migration cost is mainly people time, and people time is driven by the eight drivers: volume, sources, transformations, reconciliation, downtime tolerance, cut-over strategy, the team, and aftercare. Tool and transfer charges usually make up the smaller portion. The quotes that appear cheapest often omit reconciliation and post-go-live support, which are the elements that determine whether the new system can be trusted.

Start with a brief that defines done. Consider phasing a complex estate so the first stage proves the method and pays for the next. Treat reconciliation as a deliverable, not an extra. A migration is also the right moment to put your data on a governed foundation, because moving it once properly costs less than moving it twice.

Our data migration service moves warehouses, databases and cloud estates onto a governed foundation, reconciled row by row and supported past cut-over. We scope first, build on the data foundation and stay after go-live, and we will tell you if a migration should wait until the data is ready to move. Talk to us to turn your brief into a scope you can hold us to.

Frequently asked questions