Skip to content
ERP business case

Data migration effort estimator — person-days and calendar weeks

Data migration effort estimator: record counts by object and cleansing complexity give person-days, mock-load cycles and calendar weeks.

Free · no signup · runs in your browserUpdated
Short answer

Estimate migration effort object by object: divide each record count by a realistic cleansing throughput, multiply by a complexity factor, add per-object mapping setup, then add mock-load cycles and contingency. The default six objects — 150,600 records — come to 184.5 person-days, or 15.4 calendar weeks with three people at four productive days each.

Data migration is the part of an ERP project that slips. Not because the loading is hard, but because the effort scales with how bad the data is, and nobody measures that until the first extract lands three weeks late.

This data migration effort estimator sizes the work object by object: record counts, a cleansing-complexity factor for each object, mock-load cycles and a contingency. It returns person-days per object, total effort, and calendar weeks at the team size you actually have rather than the one on the plan.

Your numbers

records

1,200 records/day assumed, plus 3 days setup. Enter 0 to leave it behind.

records

1,200 records/day assumed, plus 4 days setup. Enter 0 to leave it behind.

records

600 records/day assumed, plus 5 days setup. Enter 0 to leave it behind.

records

20,000 records/day assumed, plus 5 days setup. Enter 0 to leave it behind.

records

400 records/day assumed, plus 5 days setup. Enter 0 to leave it behind.

records

2,000 records/day assumed, plus 3 days setup. Enter 0 to leave it behind.

Plan
cycles

Three is the usual shape: prove, fix, reconcile.

% of build

Load, compare and fix work for one cycle.

%

Rejects, re-extracts and late scope.

people

Count part-timers as fractions.

days

Four out of five is realistic for anyone who still has a day job.

Result

Total migration effort
184.5 person-days

15.4 calendar weeks with 3 people at 4 productive days each

Records in scope150,600
Map, cleanse and load (build)87.9 days
Mock loads (3 cycles)65.9 days
Contingency at 20%30.8 days
Calendar weeks15.4 weeks
Person-days per 1,000 records1.23
Effort by object, before mock loads and contingency.
ObjectRecordsCleansingPerson-daysShare of build
Customers & contacts4,200Mixed ×1.68.69.8%
Items & part masters12,500Messy ×2.429.033.0%
Open transactions3,100Mixed ×1.613.315.1%
Historical transactions120,000Clean ×1.011.012.5%
BOMs & routings1,800Messy ×2.415.818.0%
Inventory balances & costs9,000Mixed ×1.610.211.6%
Items & part masters: 12,500 ÷ 1,200/day = 10.4 days × 2.4 + 4 setup = 29.0
All objects, 150,600 records = 87.9 person-days to map, cleanse and load
3 mock loads × 25% of build = 65.9 person-days
+ 20% contingency on 153.8 = 30.8 person-days
184.5 person-days ÷ (3 × 4 days) = 15.4 calendar weeks
15.4 calendar weeks fits inside a typical implementation, but only if migration starts in week one rather than after the design workshops. The largest object is Items & part masters at 29.0 person-days — 33.0% of the build — so that is where a cleansing sprint pays back first. Re-estimate after mock load one.

Everything is computed in your browser. Nothing you type is sent anywhere or stored.

The formula

Person-days = Σ [ Setup + (Records ÷ Records per day) × Complexity ] × (1 + Cycles × Cycle share) × (1 + Contingency)
Setup
Per-object field mapping, load script and validation queries. Fixed effort — it does not shrink with volume.
Records
Rows you intend to load for that object, after you decide what stays behind in the legacy system.
Records per day
Records one person can cleanse, map and verify in a productive day. Object-specific: a BOM is not a customer record.
Complexity
Data-quality multiplier applied to the cleansing effort: 1.0 clean, 1.6 mixed, 2.4 messy.
Cycles
Mock loads. Each one costs the cycle share of build effort in load, compare and fix work.
Contingency
Planning buffer for rejects, re-extracts and the object nobody mentioned.

Calendar weeks divide total person-days by team size × productive days per week. Four productive days out of five is realistic for people who still have a day job — using five is how migration plans end up two months light.

Worked example

Customers & contacts
4,200 · mixed
Items & part masters
12,500 · messy
Open transactions
3,100 · mixed
Historical transactions
120,000 · clean
BOMs & routings
1,800 · messy
Inventory balances & costs
9,000 · mixed
Plan
3 mock loads at 25%, 20% contingency, 3 people × 4 days
Result
184.5 person-days · 15.4 calendar weeks

Items dominate: 12,500 ÷ 1,200 a day = 10.4 days, × 2.4 for messy data = 25.0, plus 4 days of mapping = 29.0 person-days. All six objects total 87.9 person-days to map, cleanse and load. Three mock loads at 25% of build each add 65.9 days, and 20% contingency adds 30.8, giving 184.5 person-days — 15.4 calendar weeks for three people working four productive days each.

How the data migration effort estimator builds its number

  1. 1.Records divided by a per-object throughput gives raw cleansing days. The throughputs differ by an order of magnitude between objects, so a single blended rate will mislead you.
  2. 2.Multiply by the cleansing-complexity factor for that object. One clean source with consistent keys is 1.0; several legacy systems with no shared identifier is 2.4 or worse.
  3. 3.Add per-object setup for field mapping, the load script and the validation queries. Fixed effort, unaffected by volume — which is why small objects are never free.
  4. 4.Add mock-load cycles, each costing a share of the build effort: load, compare, fix, repeat.
  5. 5.Add contingency, then divide the total by team capacity to convert person-days into calendar weeks.

Migrate in this order

OrderObjectWhy hereCommon trap
1Accounts, subsidiaries, currenciesEverything else posts against itRenumbering accounts after transactions are loaded
2Customers, vendors, contactsReferenced by every open documentDuplicate parents; addresses that fail validation on load
3Items, units of measure, BOMsReferenced by inventory and open ordersUOM conversions, and inactive parts nobody will admit owning
4Inventory balances and costsMust reconcile to the GL on cutover dayA costing-method change hidden inside the balance
5Open transactionsThe business cannot trade without themPartially fulfilled and partially billed lines
6Historical transactionsOptional, and the first thing to cutLoading history as live transactions instead of an archive

What actually consumes the days

  • Deciding, not loading. Which of four near-identical customer records is the real one is a business decision, and business decisions take meetings.
  • Reject loops. A 3% reject rate on 12,500 items is 375 rows inspected by hand — and you will inspect them at least twice.
  • Reconciliation. Proving the loaded data equals the source is the task that gets cut from the plan and then done anyway during cutover week.
  • Late scope. Open service contracts, serial numbers, attachments, price lists: the object nobody mentioned always arrives after the mapping is signed off.
  • Waiting for the legacy extract. Effort you cannot start is still time on the calendar, which is why the weeks figure matters more than the person-days.

Reconciling each load

Every object needs a paired count-and-sum check on both sides, run after each cycle and kept as evidence: record count, total value, and a spot list of edge cases. is read-only by default and shows the SuiteQL behind each answer, which makes it usable as the target-side check — count and value per object, on demand, without raising a report request. It is pre-launch and NetSuite-first, with Infor SyteLine, M3 and LN ready.

Once the effort is sized, price the rest of the project around it with the ERP implementation cost estimator, and check the payback assumptions with the ERP ROI calculator.

Frequently asked questions

How long does ERP data migration take?

It depends on record counts and data quality far more than on the ERP. Size it per object: records divided by a realistic cleansing throughput, times a complexity factor, plus mapping setup, plus mock loads and contingency. Six common objects covering 150,600 records come to about 185 person-days here, or 15 weeks with three people.

How many mock loads should I plan?

Plan three. One proves the mapping, one clears the rejects, one reconciles against the reports the business will actually sign off. Each cycle costs roughly a quarter of the build effort in this model. Teams that budget for one usually run three regardless, with the extra two landing in cutover week.

What is a cleansing complexity factor?

A multiplier on per-record effort that reflects data quality. One source with consistent keys is 1.0. Duplicates, missing fields and manually typed keys around 1.6. Several legacy systems with no shared identifier 2.4 or worse. These are planning defaults, not measurements — replace them once your first extract shows the real reject rate.

Should we migrate historical transactions?

Only what you will genuinely query. Opening balances plus open documents get you live; history is a reporting convenience that can be loaded later or left in the legacy system as a read-only archive. In the default scope here, 120,000 historical records account for 11.0 person-days, so cutting them shortens the critical path.

Who should do the data cleansing?

The people who own the data, not the implementation partner. A partner can build the mapping, write the load scripts and reconcile the results; only your team knows which of the four Acme Corp records is the customer you invoice. Budget those internal hours explicitly or they reappear as slipped dates.

Is this estimate reliable enough to put in a contract?

No. It is a planning aid. Its value is showing which objects dominate the effort and what a scope cut is worth, so the conversation happens with numbers. Re-estimate after the first mock load, when you know your actual reject rate and the throughput your team really achieves on your data.

Related calculators

ERP business case
ERP implementation cost estimator

Estimate ERP implementation cost from licence, services, data migration, integrations, training and contingency, scaled by users, sites and complexity.

ERP business case
ERP ROI calculator

Build an ERP ROI case from your own numbers: hours saved, inventory and receivables released, rework avoided. Get ROI %, payback months and 3-year NPV.

ERP business case
ERP TCO calculator

Model 5-year ERP total cost of ownership: subscription or licence, implementation, internal FTE, infrastructure, upgrades and support. Cloud vs on-prem.

ERP business case
ERP user licence cost calculator

ERP user license cost calculator: enter your own seat rates and term to get annual cost, cost per user and a 3-year projection with uplift.

Read the background

ERP strategy
ERP data migration guide: sequence, cleansing and cutover

ERP data migration guide: the object load sequence, cleansing before mapping, how many mock loads are realistic, reconciliation and cutover.

ERP strategy
What does an ERP implementation cost?

What drives ERP implementation cost: scope multipliers, services-to-licence ratios, the internal time nobody budgets, and what to ask an integrator.

All 50 ERP & finance tools

Stop calculating it by hand. Just ask your ERP.

This calculator needs you to find the inputs first. ERPray pulls them from your own ERP account and computes the answer live — with the exact query shown so you can check it.

Get early access — freeBrowse all 50 tools