The cost of a data migration or automation project depends on a handful of things you can mostly see before anyone quotes: how many systems are involved, how clean the data is, how much history you move, how many other systems have to connect to the new one, how many people need to approve and test it, how much training is needed, and who does which part of the work. A project that moves one clean list from one system to another is a very different size from one that moves ten years of jobs, stock and customer history out of a database nobody fully understands. We don't publish price ranges, because they would mislead more than help. We scope each project and give a fixed quote after a free initial chat. This article explains each cost driver, how to keep the scope down, and the questions to ask any provider, including us.
If your question is mostly about automation or AI work rather than moving data, our post on what a process, automation or AI project costs covers that side in more depth.
The things that make a project bigger or smaller
How many systems are involved
Every system adds work. Someone has to get access to it, understand how it stores information, export from it or connect to it, and test what comes out. Moving customers from one accounting system to another is one source and one destination. Replacing a job system that also takes stock from a spreadsheet, prices from a supplier file and timesheets from an app is four sources, and each one has its own quirks.
How clean the data is
This is usually the biggest unknown. Duplicate customers and suppliers, product codes that changed halfway through, free-text fields used for three different things, dates stored as text and records that point to nothing all have to be fixed or decided on before they move. If you move messy data, the new system starts with the same problems. Our post on data cleansing before a migration explains how to find and fix duplicates, and our data cleansing services page covers what that work involves.
How much history you move
Moving open items (current customers, open invoices, stock on hand, jobs in progress) is far less work than moving every closed transaction back to the beginning. Each year of history adds records to map, check and reconcile, and old records are often the messiest. Many businesses move open items and summary balances, then keep the old system as a read-only archive for looking things up. Our data migration plan and checklist covers how to decide.
How many integrations the new system needs
A new system rarely stands alone. If it has to send invoices to the accounts, take orders from a website or pass timesheets to payroll, each of those connections (an integration) has to be built or set up, tested and looked after. A migration with no integrations and one with five are different projects, even if the data moved is the same.
What the old system does that nobody wrote down
Old systems, especially custom databases and heavily customised software, often hold business rules in places nobody remembers: a query that applies a discount, a macro that closes off the month, a report that only works if a certain field is filled in. Finding these takes time, and missing them is how a project goes wrong after go-live. The more custom the old system, the more of this there is.
Approvals, testing and sign-off
Someone in the business has to check the trial migration, compare totals, and agree that the result is right. If one person can sign off, that is quick. If finance, operations and each site manager all need to check their own figures, it takes longer, and their time is part of the real cost even if it isn't on the invoice.
Training and change
People need to learn the new screens, and some processes change. A system used by three people in one office needs less training than one used by staff at several sites, on the road and in the warehouse. Writing a short standard operating procedure (SOP) for each changed task helps the change stick.
Who does what
A provider can do everything, or your team can do some of it: cleaning the customer list, checking trial results, writing the SOPs, training the team. Work your team does lowers the quote but takes their time, so be honest about how much time they really have during a busy month.
How to keep the scope down
- Move less history. Move open items and balances; keep the old system as a read-only archive for anything older.
- Clean before you move. Fix duplicates and dead records in the old system first, or at least agree the matching rules.
- Retire what nobody uses. Old reports, forms and fields that nobody has looked at in a year don't need to be rebuilt.
- Do it in stages. Move the part that hurts most first, prove it works, then decide on the next stage. For example, if your quoting is the biggest problem, move that before stock.
- Use what you already pay for. Check whether the new system has built-in imports or connections before paying for custom work.
- Name one decision-maker. A single person who can answer questions and sign off avoids weeks of waiting.
Questions to ask any provider
Whoever you ask for a quote, these questions make quotes comparable and expose surprises early:
- Is this a fixed quote for a defined scope, or an estimate that can grow? What happens if the scope changes?
- How much history is included, and what happens to the rest?
- Who cleans the data, and what happens to records that can't be matched?
- How many trial migrations are included, and how are the results checked?
- How will you reconcile the old and new systems: record counts, balances, open items?
- Which integrations are included, and who looks after them afterwards?
- What training and documentation do we get?
- What do you need from our team, and roughly how much of their time?
- What happens to the old system after go-live, and can we still see the old records?
- What support is included after go-live, and what does it cost after that?
Our post on red flags when hiring an automation or AI consultant lists warning signs to look for in the answers.
When the scope isn't clear yet
Sometimes you know what has to move. Other times the problem is wider: several systems, a few spreadsheets, and nobody quite sure what depends on what. Nobody can honestly quote a migration until that is clear. That's what our fixed-price $5,000 Process & Systems Audit is for. We map your key processes and systems and give you a written report, including where information gets retyped or stuck and what to fix first. The report is yours whether or not you work with us afterwards. If the scope is already clear, we can quote straight from a free initial chat.
Frequently asked questions
How much does a data migration cost?
It depends on the number of systems, how clean the data is, how much history you move, the integrations needed, and how much testing and training is involved. We scope each project and give a fixed quote after a free initial chat. The only fixed price we publish is the $5,000 Process & Systems Audit.
What is the most common reason a migration costs more than expected?
Data that turns out to be messier than anyone thought, and rules hidden in the old system that only surface late. Looking at a sample of the real data, and at the old system's queries and reports, before quoting catches most of this.
Is it cheaper to move all our history at once?
Usually not. Every year of history adds records to map, clean and reconcile. Moving open items and balances, and keeping the old system as a read-only archive, is often the smaller job.
Can our own team do part of the work?
Yes. Your team can clean lists, check trial results, write procedures and train colleagues. That lowers the quote, but plan for the time it takes them.
Why give a fixed quote instead of an hourly rate?
So you know the cost before you commit, and so the provider has to understand the systems and data before starting. Any change to the scope is agreed in writing, with its cost, before the work is done.
If you're weighing up a migration or automation project and want a straight view of what it involves, book a free initial chat. You can also see how we move data between systems.