Should you replace your ERP or put a data layer over it?

Replace the ERP when it can no longer be supported or changed safely, or when it cannot record the business. If the problem is reporting or connecting records, put a data layer over it. The common case in between is a business whose ERP still works but will have to be replaced within a few years. For that business the answer is often both, in a particular order. Build the data layer first, so the history and the reports are held outside the ERP before the migration starts.

What the usual answer says

The advice that ranks for this question treats the two as alternatives. In February 2026 Rea Advisory published a warning for contractors against replacing a working ERP for the wrong reasons: "reporting frustration, or fear of 'falling behind,' is not enough on its own." It lists the cases where replacement does make sense, among them unreliable closes, unsupported compliance, and vendor support that is no longer viable. The test carries over to a timber business.

The top result, a legacy-integration guide from Netguru, goes further and discusses sequencing. It asks "whether an integration layer is buying time for that change or quietly replacing the need for it". If you get that wrong, it warns, "the integration layer itself becomes the next legacy system to untangle." What neither page covers is the business whose vendor has already set a date.

When the vendor sets the date

Microsoft has done that for Dynamics GP, which serves here only as an example of a published date. Its lifecycle page states: "we will end Dynamics GP support on December 31, 2029 (previously announced end date was September 30, 2029), for product enhancements, regulatory (tax) updates, and technical support. Security updates/patches, if needed, will be made available until April 30, 2031." Older versions end sooner. Extended support for GP 2016 ended on 14 July 2026, and for GP 2018 it ends on 11 January 2028. Partner support can stretch those dates, but it does not remove them.

Panorama Consulting's 2026 ERP Report, from 170 organisations with ERP projects, names the question a business in that position faces. An organisation "may want validation of whether ERP-native AI capabilities are sufficient or whether a separate data and integration layer is needed to support cross-system reporting and automation."

Why the layer can come first

The first reason is history. Microsoft's own guide to migrating from GP describes what moves by default. For past years, "General ledger (GL) account summary transactions are generated and posted", and a part-paid invoice comes across as a new invoice for the amount still owed. Detailed history can be brought across as a snapshot, back to a year the business chooses. How much history the migration will carry is a question to ask early. A layer that already holds the joined records doesn't depend on the answer.

The second is the reports. The figures leadership relies on are defined in the layer, so the new ERP can be tested by checking that it produces the same numbers.

The cost is real. The layer's connections to the old ERP have to be rebuilt against the new one, and for a while the layer reconciles two systems at once. What carries across is the joined history and the definitions. Whether that is worth connecting twice depends on how much history the business needs.

Problems the new ERP won't fix

A layer also shows which problems belong to the ERP. From Quarri's own work with a lumber and millwork manufacturer: one customer account carried open receivables of more than four times its credit limit. It might come from a missing rule, a process gap or a decision someone took. A new system will not settle it by itself. Finding problems like it before a migration keeps them from being blamed on the old system or expected of the new one.

How to decide

Check the vendor's lifecycle page for your ERP and version. If support ends within the next few years, plan the replacement, and ask the implementation partner early how many years of transactions the migration will carry. If that answer is short and the history matters, build the layer now. Write down when its connections to the old ERP will be retired, as Netguru advises. If the date is not the issue, list the problems driving the question, and sort each into one the ERP cannot record or one about reporting and connecting records. A list made mostly of the second kind will look much the same after a replacement.

When it doesn't apply

A business already in the final weeks before cut-over to a new ERP has no time to build a layer first. With a fixed date and little IT capacity, it may be better to put every effort into the migration. Archive the old history once, and build the layer on the new system. A young business with little history has less to carry across. And some ERPs, especially heavily customised older ones, are replaced because nobody can safely change them, which is a case for replacement on its own terms.

Quarri for finance and strategy teams is built for the people who close the month, explain the margin and answer the board.

Quarri is an AI-native data platform for the timber supply chain. It connects buying, production, sales and inventory for forest management, sawmill, wood products and pulp, paper and packaging operators.