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. The request is also, almost always, the wrong architecture, and giving in to it quietly taxes the programme and then the platform for years.
An ERP is an operational system. Its data model, its indexing and its licensing are all tuned for running today's transactions, not for scanning a decade of closed ones. Loading deep history into it 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 now sifts a decade to find this month's rows. And analytics pays forever, because operational schemas make miserable reporting sources: the question the business actually asks needs six joins and an interpreter.
Meanwhile the actual operational need for history is thin: open balances, open orders, current-and-recent activity for context. That is what belongs in the ERP, and it is a fraction of what gets requested.
Listen carefully and the stakeholder asking for ten years is not asking for rows in the ERP. They are asking 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 deserve 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 actually ask, and report over it with Power BI or whatever the organisation runs. Done this way, the history becomes more useful than it ever was inside the old ERP: joined with current data from the new system, queryable in seconds, and available to the AI and analytics work that operational schemas resist.
There is a bonus that finance teams appreciate: the legacy system can then actually be decommissioned. The pattern where the old ERP is kept on life support purely so someone can look up history is the most expensive reporting tool ever operated.
The framing that works is not "no". It is "everything stays queryable; here is where each question gets answered". Operational context lives in the new ERP. Trends, comparisons and audits live in the lakehouse, one screen away. In our experience the ten-year request dissolves the moment the reporting need is genuinely met, because it was never about the rows. It was about not losing the answers.
The one discipline that makes this work: build the lakehouse path during the migration, not after it. Promised-later reporting is how the pressure to load history into the ERP wins, one exception at a time. The migration programmes we run treat the analytical landing zone as part of cutover scope, and the data conversation gets easier from there.
Duke Le works in Coder Trove's AI, data and analytics practice.