Legacy ERP modernization means bringing an old ERP back to a supportable, adaptable state by one of four routes: upgrading to a current version, extending it with modern interfaces and integrations, replacing it in phases, or rebuilding it as a new system. The right route depends on vendor support status, how much the system has been customised, and how well it still fits the business.
This guide is specific to ERP. For modernization of other kinds of software, such as line-of-business applications and databases, see our broader guide to legacy system modernization options. Here the focus is what makes ERP different: finance and audit history, deep customisation, and the number of processes that depend on one system.
What makes an ERP "legacy"?
An ERP becomes legacy when keeping it running is getting harder or riskier, even if it still works day to day. Age alone is not the test.
Typical markers:
- Vendor support has ended or has a published end date, so security patches, tax updates or fixes will stop
- It runs on an unsupported operating system or database, or on hardware that is hard to replace
- Customisations prevent upgrades, so the business is several versions behind
- Integrations are file drops or manual exports, because the system has no modern interface
- Only a few people can change it, sometimes one contractor
- It cannot support new needs, such as e-commerce, mobile approvals, new entities or new tax rules
Examples of published vendor timelines
Vendor timelines are the clearest trigger, and they are published. Two examples, checked in October 2026 on the vendors' own pages:
- Microsoft Dynamics GP: Microsoft Learn states that support for product enhancements, regulatory (tax) updates and technical support ends on 31 December 2029, with security updates, if needed, available until 30 April 2031.
- SAP ERP 6.0 (SAP Business Suite 7): SAP's support site states mainstream maintenance for Business Suite 7 core applications runs until the end of 2027, with optional extended maintenance from 2028 until the end of 2030. Check which enhancement package you run, because support terms can differ.
Other products have their own dates. Find the lifecycle page for your exact product and version, not only the product family.
How do you assess a legacy ERP before deciding?
Assess four things: support status, customisation debt, process fit and data. A short, structured assessment avoids choosing a route based on frustration alone.
Assessment checklist
- Support: vendor end-of-support date for your version; operating system and database support dates; who maintains it today
- Customisation inventory: list every modification, report, interface and script; mark which are still used
- Process fit: for each main process (procure-to-pay, order-to-cash, record-to-report, production, inventory), note whether it runs fully in the ERP, partly, or outside it
- Integrations: list each connection, how it works (API, file, manual), and how often it fails
- Data: volume, quality, how many years of history, retention requirements set by your accountants
- People: who knows the system; how much of that knowledge is written down
- Risk: security exposure, audit findings, regulatory changes the system cannot handle
The customisation inventory is often the most revealing. Many old systems carry modifications no one uses any more. Retiring them can make an upgrade much simpler. For each modification, ask whether the current version now does the same job through standard configuration; if it does, the change can usually be dropped.
What are the options for modernizing a legacy ERP?
There are four routes, and they can be combined. Choose by how well the core still fits and how urgent the support deadline is.
| Route | What it involves | Fits when | Main trade-off |
|---|---|---|---|
| Upgrade | Move to the vendor's current version, retiring unused customisations | Core processes still fit; vendor has a supported path | Customisations must be rewritten or dropped; does not fix process gaps |
| Extend | Keep the core; add APIs, portals, mobile apps, dashboards and integrations around it | Core is stable and supported for some years; gaps are at the edges | Extends life but not indefinitely; adds systems to maintain |
| Phased replacement | Move processes or entities to a new system one at a time, with temporary interfaces | Support deadline allows time; risk of a single switch is high | Two systems run side by side for a period; interfaces needed |
| Rebuild or replace in one go | Replace with a new package or custom ERP in one go-live | System is small enough, or support ends soon | Highest single-event risk; needs strong testing and cut-over |
If your old system needs a careful route out, our legacy software modernization service covers assessment, data extraction and phased replacement, and our custom ERP software page explains how a replacement can be built module by module.
How does a phased ERP replacement work?
A phased replacement moves one process area, site or entity at a time from the old ERP to the new system, while the two exchange data through temporary interfaces. It is sometimes called the strangler approach: the new system grows around the old one until the old one can be switched off.
Typical sequence
- Build the integration layer first. A clean interface to the old ERP lets new modules read and write data without touching its internals. Our guide to system integration approaches compares the options.
- Start at the edges. Customer portals, mobile approvals, dashboards or a purchasing front end deliver value quickly with limited risk.
- Move an operational process. For example, inventory and warehouse, or production, with stock movements posted back to the old ledger.
- Move the finance core last, at a period start, once the operational modules are proven.
- Switch off the old system, keeping it read-only or archived for history.
Phased replacement trade-offs
- Pro: each step is smaller, testable and reversible; users adapt gradually
- Pro: value arrives before the full replacement finishes
- Con: temporary interfaces cost effort and are thrown away later
- Con: two systems are maintained for a period, and reconciliation between them must be designed
- Con: without firm sequencing, the project can stall halfway, leaving both systems in place
Set an end date for every temporary interface when you design it. That date is what stops a phased programme from becoming permanent.
What happens to the data in the old ERP?
Migrate what the business needs to operate from day one, and archive the rest in a form that stays readable for as long as you must keep it. Moving every historical transaction into the new system is rarely worth it.
| Data | Approach |
|---|---|
| Active master data | Cleanse and migrate |
| Opening balances and open transactions | Migrate at a period start, reconciled |
| Closed transaction history | Keep the old system read-only, or move to an archive database with search and reports |
| Audit trail and documents | Archive with links to transaction references |
| Old customisation logic | Document the business rules before switch-off, even if the code is retired |
Retention periods are a legal and tax question for your accountants. Plan the archive so finance and auditors can answer questions without the old system's licences or hardware. Our ERP data migration plan covers the migration steps in detail.
Illustrative scenario: extend first, then replace
This is an illustrative example, not a client case. A manufacturer runs an on-premise ERP with years of customisation and a vendor end-of-support date three years away. A full switch in one step is judged too risky. In year one, it adds an integration layer and a web-based purchasing and approvals module, retiring email approvals. In year two, inventory and production move to new modules, posting to the old ledger. In year three, finance moves at a financial year start, and the old system becomes read-only for history. Each phase has its own UAT and go-live.
How do you keep a modernized ERP from becoming legacy again?
Legacy is mostly the result of decisions made after go-live, not the age of the code. A few rules keep a new or upgraded system adaptable.
- Prefer configuration to modification, and record every modification with its business reason and owner, so it can be reviewed at each upgrade
- Integrate through documented APIs, not direct database writes or shared files, so either side can change without breaking the other
- Keep documentation alive: process maps, data dictionary, integration list and the customisation register, updated as part of each change
- Spread knowledge: at least two people inside the business who understand each core process in the system, and a support partner who documents what they change
- Review fit yearly: compare the system against current processes, entities and channels, and plan small changes before gaps turn into workarounds
- Own your code and data: for a custom system, make sure source code, deployment scripts and documentation are handed over, so you are never tied to one contractor
| Warning sign after go-live | What to do |
|---|---|
| Spreadsheets reappear for an in-scope process | Find the missing feature or report and add it |
| Upgrades skipped because they look risky | Retest a small upgrade in a copy of the system and schedule it |
| One person handles every change request | Pair a second person and write down the process |
| New integrations bypass the API layer | Route them through the integration layer before they multiply |
When is modernization the wrong move?
If the old ERP is current, supported and still fits, modernization for its own sake adds cost and risk. Extending it with a few integrations or a reporting layer may be all you need.
At the other end, if the system is small, standard and close to its support deadline, a phased programme may be slower and more expensive than a straightforward replacement with a packaged ERP. Packages can be the better choice when your processes are standard and you want the vendor to maintain features and tax updates. If you are weighing those routes, see ERP versus custom development and our list of signs you need a new ERP.
How to start
Run the assessment checklist above: support dates for your version, a customisation inventory, process fit and an integration list. Then write a short brief with our software requirements brief template, so any partner can respond to the same picture.
Timeline Digital builds 2 to 3 key modules as a free pilot before the full project starts, which suits a phased route: the pilot can be the first modules around your old system. Discuss your project with us. Source code for your project transfers to you on full payment, and your data remains yours throughout.