Historical ERP data belongs in a data warehouse or lakehouse with reporting on top. The new ERP needs only open balances, open orders and recent activity, and loading a decade of closed transactions into it raises migration effort, platform cost and reporting pain.
Somewhere in every ERP migration, a stakeholder asks for ten years of history in the new system. The reasoning is sincere: the history exists, people query it, and leaving it behind feels like loss. Giving in to it taxes the programme and then the platform for years.
An ERP is an operational system. Its data model, indexing and licensing are tuned for running today's transactions, and scanning a decade of closed ones is outside that design. Deep history costs three times over. The migration pays first: historical records must be mapped to the new master data and schema, validated and reconciled, which multiplies the hardest workstream in the programme for data nobody will transact against. The platform pays next, in storage and in every query that sifts a decade to find this month's rows. And analytics keeps paying, because operational schemas make poor reporting sources: a routine business question needs six joins and someone who knows the schema.
The operational need for history is small: open balances, open orders, current and recent activity for context. That is a fraction of what gets requested.
Listen carefully and the stakeholder asking for ten years wants to keep answering questions: how has this customer's volume trended, what did we pay for this component across five years, how do this year's margins compare. Those are analytical questions, and they need an analytical home.
That home is a warehouse or lakehouse. Extract the history once from the legacy system, land it in inexpensive storage, model it for the questions people ask, and report over it with Power BI or whatever the organisation runs. Done this way, the history is more useful than it was inside the old ERP: joined with current data from the new system, queryable in seconds, and available to AI and analytics work.
Finance teams also get to decommission the legacy system, instead of keeping it licensed and supported purely so people can look up history.
The framing that works is "everything stays queryable, and here is where each question gets answered". Operational context lives in the new ERP. Trends, comparisons and audits live in the lakehouse. In our experience the ten-year request goes away once the reporting need is met.
Build the lakehouse path during the migration. Reporting promised for later is how the pressure to load history into the ERP wins, one exception at a time. The Dynamics 365 migration programmes we run treat the analytical landing zone as part of cutover scope. Our AX 2012 to D365 migration guide covers what data moves and what stays behind, and D365 data migration before UAT covers rehearsing the data that does move.
Usually not. Open balances, open orders and inventory positions must move and reconcile to the ledger; closed transactions are better kept in a warehouse or lakehouse.
Yes, once its history has been extracted and the reporting it supported is available from the lakehouse.
Power BI is the common choice in Microsoft estates, and most reporting tools can query a warehouse or lakehouse.
Hai Tran leads ERP data work at Coder Trove.