How much to charge for a data migration
How much to charge for a data migration comes down to what the client stands to lose. They are moving from an old CRM, an ageing database, a pile of spreadsheets or a system the vendor is shutting down, into something new. Everything they know about their customers, orders and money is in that data. Find what a clean move is worth to them, and what a broken one would cost, then price against that and itemize the parts that drive effort: audit, cleanup, mapping, testing and cutover.
Claude Code makes the scripts quick. Reading an export, transforming the fields and loading them into a new system is work it does well, and it can write the checks that compare the two sides. That is exactly why pricing by hours undersells you. What still takes time is the part nobody sees in the sales call: fields that mean different things to different staff, duplicate customers, dates in three formats, and the one table nobody remembered existed. Build the quote around those.
Find out what is at risk before you quote
Do not quote from a record count. Ask four questions in the first call: what systems the data lives in today, what the business uses it for every day, what has to be true on the first morning in the new system, and what happens if something is missing or wrong. The last answer sets your price more than anything else.
Three kinds of data migration clients and what to price against
| Client | What they are moving | Price against |
|---|---|---|
| Small business switching tools | Contacts, deals and notes from one CRM or spreadsheet into another | Staff time to re-enter it by hand, and leads lost in the gap |
| Company leaving a legacy system | Customers, orders, invoices and history from an old database or app being retired | The cost of keeping the old system running, and the risk of losing financial records |
| Business consolidating after growth | Several spreadsheets and tools merged into one source of truth | Hours spent reconciling between systems, and decisions made on wrong numbers |
If they cannot tell you what is in the old system, that is your answer: sell a paid audit first and quote the migration after. Paid discovery for AI projects covers how to sell that, and client discovery questions before you quote has the questions.
The CCC Data Migration Quote
Six parts of a data migration quote
| Part | What it prices | Question to ask the client |
|---|---|---|
| Audit | Exporting everything, listing every table and field, and finding what is actually used | Who can give me admin access and a full export of the old system? |
| Cleanup | Removing duplicates, fixing broken records and agreeing what to leave behind | Do you want old, inactive records moved, archived or dropped? |
| Mapping | Matching each old field to the new system and deciding what to do with the ones that do not fit | Who on your team knows what each field really means? |
| Test runs | Moving a sample, then a full copy into a test space, and checking counts and totals against the old system | Who will check the test data and sign it off? |
| Cutover | The final move, freezing changes in the old system, and switching the team over | When can the business stop using the old system for a day or a weekend? |
| Support window | Fixing problems found in the first weeks of real use | Who reports issues after go-live, and how fast do they need fixing? |
The audit is your anchor line, and I like to sell it as its own small project. It protects you from quoting blind, and it gives the client a clear picture of their own data, which they usually have never had. If they walk away after the audit, you were still paid for real work.
Cleanup and mapping get their own lines, always. This is where migrations run over. The script that moves the data is quick. Getting the operations manager and the finance lead to agree what "active customer" means is not. Quote those conversations as real work, because they decide whether the new system is trusted on day one.
Agree what done means in writing
Migrations end in arguments when nobody defined finished. The owner expects everything to look exactly as it did, just in the new tool. Some fields will not have a home, some history will be summarized, and some junk will be left behind on purpose. Put the rules in the proposal: what moves, what gets archived, what gets dropped, and the checks that prove it worked.
My take: promise checks, not perfection. Agree that record counts match, that key totals such as open invoices or customer balances match the old system, and that a named person on their side signs off the test run before cutover. Once they have signed off, a missing field they forgot to mention is a change request, not your mistake. How to handle the "guarantee results" objection covers what to say when they push for more.
Keep the data and the backups in the client's accounts
A migration puts every record the business has in your hands at once. Treat that seriously in the proposal. The exports, backups, the test environment and the new system all sit in the client's accounts, with you added as a user. Do not keep copies on your laptop after the job, and say in writing when your access ends.
Always take a full backup of the old system before you touch anything, and agree a rollback plan: if the cutover goes wrong, how the team goes back to the old system and for how long it stays available. If the data includes payment, health or identity information, ask early what rules apply and get their answer in writing. That decision is theirs with their advisers. Is Claude Code safe for client work covers how to talk about it, and connecting Claude Code to a database covers working with live data carefully.
Always quote the support window
Problems in a migration show up when real people use the new system. A report looks wrong, a customer's history is split across two records, a workflow depended on a field nobody mentioned. If you have not quoted for that, you fix it for free while the client wonders if they made a mistake.
Put a fixed support window in the first proposal, next to the build price. Say what it covers: fixing records that did not move correctly and answering questions about where things went. Say what it does not cover: new fields, new reports and changes to the new system's setup. If they want ongoing help after that, offer a retainer. How to price a maintenance retainer covers the structure.
How to present the data migration quote
- Lead with the outcome in the owner's words. One line on what is at stake, such as years of customer and invoice history moved without losing a record, then the price.
- Offer three options. A starter version that moves active records with basic cleanup, a standard one with full cleanup, mapping, test runs and a planned cutover, and a full one that adds history, archives and a longer support window. Most owners pick the middle one when it is clearly the best value.
- Itemize it. Audit, cleanup, mapping, test runs and cutover, then the support window as its own line. Itemized quotes get trimmed, not rejected.
- Take a deposit and tie the rest to milestones, with sign-off of the test run as one of them. How much deposit to charge and how to structure milestone payments cover the schedule.
And skip hourly. Claude Code makes the scripts fast, so an hourly rate turns that speed into a pay cut. Why I stopped charging hourly for AI builds covers why. If the client also wants a tool their staff use on top of the new data, see how much to charge for an internal tool.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
How much should I charge for a data migration?
Price it on what the data is worth to the business and what a failed move would cost, not on the number of records. Charge for the audit, cleanup, mapping, test runs and cutover as separate lines, and quote a support window for the weeks after go-live.
Why do some data migrations cost more than others?
Because of mess, not size. A clean export into a similar system is quick. Several sources, duplicates, fields that mean different things, financial history and a business that cannot stop working during the move take far more time.
Should I charge separately for a data audit before a migration?
Yes. A paid audit tells you what is in the old system before you quote the move, protects you from pricing blind, and gives the client a clear picture of their data even if they stop there.
What should a data migration proposal include?
What moves, what gets archived and what gets dropped, the checks that prove it worked such as matching record counts and totals, who signs off the test run, the backup and rollback plan, and what the support window covers.
Who should own the data during a migration?
The client. Exports, backups, test environments and the new system stay in their accounts with you added as a user. Do not keep copies after the job, and agree in writing when your access ends.
Last reviewed by Duncan Rogoff on November 3, 2026
