Data migration is the most consistently underestimated workstream on every ERP programme I have run. The vendor scopes three months of data work. The reality lands at six to nine. By cutover, half the team is firefighting duplicates and the steering committee is asking why nobody flagged it earlier.
I built this estimator to push that conversation forward by a few months. It sizes the work by data object, by volume, and by target ERP, and it returns a person-day estimate, a cost band, and a recommended migration approach. It is vendor-agnostic across SAP S/4HANA, SAP ECC, Oracle Fusion Cloud, Oracle E-Business Suite, and Microsoft Dynamics 365 and AX.
The output is a range, not a single point, because the truth is a range. The variables that move the number most are data quality, the number of source systems, and how much history you choose to bring across.
Pick your target ERP. Add the data objects in scope and the record volumes you expect for each. Set the data quality flag honestly. The estimator returns effort by object, a total person-day range, a cost band, and a recommended approach (Migration Cockpit, LSMW, custom ETL, or hybrid).
Everything runs in your browser. Nothing is sent anywhere. Nothing is stored. Adjust the inputs as often as you need to stress-test the result against your own assumptions.
- Customer master: sold-to, ship-to, payer, bill-to relationships, partner functions
- Vendor master: supplier records, payment terms, withholding tax, bank details
- Material master: basic data, plant views, sales views, MRP, accounting and costing
- GL accounts and chart of accounts: primary and secondary costs, hierarchies
- Cost centres, profit centres, internal orders: controlling master data
- Open purchase orders: header, items, schedule lines, account assignments
- Open sales orders: header, items, conditions, partner data
- Open invoices (AP and AR): open items with assignments and clearing rules
- Inventory balances: by storage location, batch, special stock
- Historical financial transactions: postings, balances, year-end carry-forward
- Asset master and depreciation history: by asset class and depreciation area
- HR master data: employees, org units, positions where SuccessFactors or HCM is in scope
Enter your migration details
Fields marked * are required.
The pattern is always the same. Discovery happens in workshops, with the system owners present. They tell you the data is "broadly clean." The estimate gets built on that statement. Nobody runs a single profiling query before the number gets into the business case.
I had a manufacturing client tell me their part numbers were standardised. We pulled the data and found 12 different formats in active use. On another programme, the system of record for customer notes turned out to be a custom field nobody had documented, and three years of history disappeared because the mapping missed it. On a finance migration the only person who understood the legacy chart of accounts had retired five years earlier.
The expensive moment is finding these issues during cutover rehearsal, not in planning. A data quality fix discovered in week two of discovery costs days. The same fix discovered in mock cutover three costs the programme weeks, sometimes a quarter. By that point the dates are public, the change network is mobilised, and pulling go-live is a board conversation.
The right move is to profile the data before the estimate is signed. Run actual queries against the source. Count duplicates. Count nulls. Count records that fail your target system's mandatory field rules today. The estimator assumes you will do this. The cost band widens sharply when you set the data quality flag honestly.
The right approach depends on the target ERP, the data volumes, and how many source systems you need to consolidate. Below is the rough shape of what I reach for, with effort relative to the simplest option.
| Approach | Best for | Effort multiplier | Tools |
|---|---|---|---|
| SAP Migration Cockpit (LTMC / LTMOM) | Greenfield S/4HANA, standard objects, mid volumes | 1.0× | LTMC, LTMOM, SAP-delivered templates |
| LSMW | ECC, legacy migrations, programmes still on older releases | 1.2× | LSMW, recorded BDC sessions |
| Custom ETL via SAP BTP / Integration Suite | High volume, complex transformations, multi-source consolidation | 2.0× | BTP, CPI, SAP Data Services, Syniti, SNP |
| Hybrid (Cockpit + ETL) | Brownfield S/4HANA conversions and selective migrations | 1.5× | Cockpit for masters, ETL for transactional history |
| Oracle-native | Oracle Fusion Cloud and EBS targets | 1.3× | FBDI, ADFdi, Oracle GoldenGate |
| Dynamics Data Management Framework | Dynamics 365 F&O and AX targets | 1.3× | DMF entities, Azure Data Factory |
Custom ETL is the most flexible and the most expensive. The honest test for whether you need it is whether your source data violates the target's standard rules in ways no template can fix without per-record logic. If the answer is no, stay with the delivered tools.
- SAP S/4HANA (greenfield, brownfield, selective)
- SAP ECC (still relevant for parallel landscapes and late migrations)
- Oracle Fusion Cloud ERP
- Oracle E-Business Suite (R12)
- Microsoft Dynamics 365 Finance and Operations
- Microsoft Dynamics AX (2009, 2012)
- Programme managers sizing the data workstream before the SI commits a number.
- Data migration leads stress-testing their internal estimate against an independent baseline.
- CIOs and CFOs sanity-checking the data line in a multi-million-dollar implementation budget.
- Independent advisors producing defensible numbers in proposals or assurance reviews.
- In-house ERP teams building the business case without paying for a separate scoping engagement.
- A defensible number, fast. Object-by-object person-day estimate instead of a single guess.
- Vendor-neutral. Built on patterns across SAP, Oracle, and Microsoft programmes, not from a single vendor's playbook.
- Approach recommendation. Tells you whether Migration Cockpit, LSMW, custom ETL, or a hybrid is the right starting point.
- Volume and quality aware. Cost band widens when data quality drops, the way real programmes do.
- Free, browser-only, no sign-up. Nothing leaves your machine. Refresh and restart as often as you need.
How accurate are the data migration estimates from this tool?
The numbers reflect the patterns I have seen across SAP, Oracle, and Dynamics programmes over the last 25 years. They are designed to anchor a planning conversation, not to replace a profiling exercise on your actual data.
The single biggest accuracy lever is whether you have run profiling queries against the source. A cost band built on an honest data quality flag holds up. A cost band built on workshop optimism does not. Use the estimator output as the baseline number for your SI conversation. If their estimate is materially lower, ask which data quality assumption they are making and how they validated it.
Should I migrate historical financial transactions or just open items?
For most programmes the right answer is open items plus opening balances, with history kept readable in the legacy system through a read-only archive or a reporting layer. Migrating full transactional history multiplies the effort, slows reconciliation, and rarely earns its cost.
The exception is regulated industries where statutory retention requires the history to live in the system of record, or businesses where rolling year-on-year comparisons in the new system are an actual operating requirement. In both cases, the estimator's effort multiplier for historical data reflects the heavier lift.
Which migration approach does the tool recommend?
It picks the starting point based on target ERP, object set, and volumes. Greenfield S/4HANA with standard objects usually lands on Migration Cockpit. Brownfield conversions and selective migrations lean toward a hybrid. High volumes, multiple source systems, or heavy transformation push the recommendation to custom ETL on BTP or an equivalent platform on the Oracle or Microsoft side.
The recommendation is a starting point. The real decision happens after a proof-of-concept on a sample of your data, not from a calculator. Treat the output as the working hypothesis you take into that exercise.
Can I export the plan or share it with my team?
The calculator runs entirely in the browser. You can screenshot the result, or copy the per-object numbers into your own planning spreadsheet. There is no account, no export-to-PDF flow, and nothing is stored server-side. That is deliberate. If you want a deeper walk-through of the numbers, book a 30-minute call and bring the screenshot.
Does it cover non-master data like configuration and security?
No. The estimator scopes master data and transactional data only. Configuration data, security roles, custom developments, and integration objects sit in different workstreams with their own effort drivers and shouldn't be lumped into the data line. Putting them all into one number is one of the reasons data migration estimates get blown out at the planning stage.
How does it handle multi-region and multi-entity rollouts?
The estimator sizes a single migration event. For a multi-region rollout, run it once per wave and add the waves together, with a reduction factor for the templates, mappings, and tooling you reuse from wave one onward. In my experience the second wave costs roughly 60 to 70 percent of the first, the third drops to around 50 percent, and stabilises from there. Local statutory data objects (tax, payroll, banking) are usually the part that does not reuse cleanly.
Does the tool work for ECC to S/4HANA brownfield conversions?
Yes, and it adjusts for the lower effort on objects that convert in place versus those that need re-mapping. A brownfield conversion typically lands at 40 to 60 percent of the data effort of an equivalent greenfield migration, because customer, vendor, material, and chart-of-accounts structures carry across without re-extraction. The bigger lift is usually the business partner conversion and the new GL impact on historical postings.
Is the calculator free?
Yes. No sign-up, no email gate, no payment. The calculation runs in your browser and nothing is stored or sent anywhere. If you want help building the data migration case once you have a number, book a 30-minute call.