Free Tool
Data migration scope and effort estimator
When moving from an old system to a new one, the timeline is set by how readable the source is and how clean the data is — not by how many rows there are.
Five inputs produce a rough engineer-day range: record count, source system type, number of entities to move, field count and data quality. The output is a planning estimate rather than a quote, and every weight and multiplier used is written out below in full. The real duration becomes clear after the first trial load.
This is a planning estimate, not a quote. The real duration is set after the first trial load. Tell us about your data →
How the estimate is built
The model has four parts and all of them are visible here. The goal is not a claim of precision but a repeatable, arguable order of magnitude.
- Base effort: 2 days. Whatever the record count, every migration carries setup: getting access to the source, pulling sample output, reviewing the target schema.
- Volume weight. Record count is counted in orders of magnitude: 1 up to 10,000; 2 up to 100,000; 3 up to 1,000,000; 4 above that. It is deliberately logarithmic, because effort does not grow linearly with rows — the script is the same script.
- Structure weight = entities × 0.5 + fields ÷ 20. This is where the real effort hides: every entity brings a mapping decision and every field brings a transformation rule.
- Multipliers. Base + volume + structure is multiplied first by the source multiplier and then by the quality multiplier. The result is presented as a range: the lower bound is 80% of the computed value, the upper bound 135%.
| Source system | Multiplier | Why |
|---|---|---|
| Spreadsheets / CSV | 1.0 | Easy to read; the real work is in formats and rules |
| Packaged ERP | 1.3 | Wide schema, limited export, code tables must be resolved |
| Legacy custom software (DB access) | 1.5 | Undocumented schema; field meanings inferred from code |
| Closed system (screen reports only) | 2.0 | Data is reconstructed from report output; verification is expensive |
| Paper / PDF / scanned | 2.8 | Readable data must be produced first; error rate managed separately |
| Data quality | Multiplier | Symptoms |
|---|---|---|
| Clean | 1.0 | Single source, mandatory fields filled, no duplicates |
| Mixed | 1.35 | Some duplicate records, empty fields, dates in free-text boxes |
| Dirty | 1.8 | Multiple sources, same record spelled several ways, hand-corrected rows |
Years of history add a small weight too: 0.3 days for every year beyond three. The reason is not technical but regulatory — codes, units and tax rates used in earlier years may differ from today’s, and every difference is another transformation rule.
Where the effort goes
The phase split reflects the working order this tool assumes:
- Field mapping (35%). The longest and least visible phase. Every field in the old system is matched to something in the new one, and rules are written for fields with no counterpart. This phase needs business knowledge rather than technical skill, and it depends on how much time one person on your side can give it.
- Transformation scripts (30%). Turning the mapping decisions into code that is repeatable and reversible.
- Trial load and reconciliation (25%). The data is loaded into the target, totals are compared against the old system, and every difference is explained one by one. Skip this phase and the migration looks complete but fails at month end.
- Cutover (10%). The switch moment, the final incremental load and the rollback plan.
What actually makes migrations run long
In practice most of the delay comes from decisions rather than data:
- The “move everything” reflex. Moving a full ten-year archive is, in most companies, money spent on data nobody will open again. Moving the active period and leaving history in a read-only archive is often the better call.
- No single owner of the answers. If nobody can say what a given field means, the mapping phase stretches out of proportion.
- Leaving reconciliation to the end. If totals are only checked the day before cutover, there is no time left to react when a difference appears.
- Planning to clean the data after the move. Dirty data does not get cleaned once it is inside the new system. It spoils the first impression and breaks user trust from day one.
What you can do now to make migration cheaper
Three tasks done before the project starts will pull the number of days down directly. First, pick a single source of truth for every entity: which file is the definitive customer list? Second, merge duplicates at the source — that job belongs to whoever knows the data, not to a developer. Third, decide up front which period will move and write that decision down. With those three in place, migration becomes the most predictable line in the project.
To see the band for the whole scope, use the budget and timeline estimator; if the old and new systems have to run side by side for a while, the integration complexity score measures that separately. For the same subject in prose see our ERP data migration page and the migration guide.
Frequently Asked Questions
Is record count really what drives migration effort?
It is the weakest driver of the three. Moving a million rows and moving ten thousand is almost the same script. Effort is driven by how the source can be read (API, database, files, paper), how many entities have to be linked together, and how dirty the data is. The tool asks about all three separately and gives record count the smallest weight.
What does engineer-day mean here?
One engineer spending one full day on the work. Two engineers shorten the calendar but rarely reduce the total engineer-days; coordination overhead usually adds a little. When you convert to a calendar date, add the verification and reconciliation days on your own side too.
How do I judge data quality?
One simple test: how many different spellings exist for the same customer or the same stock item? The more, the dirtier the data. Empty mandatory fields, dates written into free-text boxes, unit confusion and hand-corrected rows all fall into the same bucket. You choose the level in the tool; we make no assumption about your data.
What if the old system will not export our data?
There is no data that cannot come out, only data that comes out expensively. If the vendor offers no export, the order of attack is: file outputs of on-screen reports, direct read-only database access under licence, and as a last resort structured extraction from screens. The source option in the tool reflects that difference through a multiplier; the most expensive option is a paper or scanned archive.
Is migration billed separately?
Migration is part of delivery in the enterprise package and is not priced as a separate line. Added to a starter single-process project afterwards, it becomes an additional module. The number of days on screen is an effort estimate for planning purposes, not a price.
Let us look at your data together
Thirty minutes settles the source, the quality and the period to move — the real duration follows from there.