Modernizing Without the Rewrite: What to Do With a 20-Year-Old ERP

A 20-year-old ERP is not automatically a problem.

It may still run purchasing, inventory, production, billing, scheduling, or financial controls every day. It may also be surrounded by custom reports, manual workarounds, and integrations that nobody wants to disturb.

That combination is common in manufacturing, retail, healthcare, and energy and utilities.

The usual advice is simple: replace the old system.

The practical answer is more careful. Most organizations do not need to rewrite everything. They need to decide what stays, what connects, and what changes first.

The rewrite-or-suffer choice is false

A full ERP replacement can solve real problems. It can also create new ones.

You must migrate data. Rebuild integrations. Redesign workflows. Train users. Replace reports. Connect scanners, terminals, equipment, suppliers, and operational systems. You must keep the business running while changing the system that carries the business.

That is a large program for a mid-market organization. A three-person IT team may already be busy with password resets, endpoint issues, and an aging network problem. The business may not have spare people to support a multi-year replacement effort.

The same pattern appears in different industries:

A manufacturing ERP or MES predates the current leadership team.
A retail POS estate runs several inconsistent versions across hundreds of stores.
A healthcare scheduling, billing, or EHR system is too central to interrupt.
A utility SCADA-adjacent or OT environment requires strict change control.
A warehouse management system depends on custom reports and one person’s memory.

These systems need attention. They do not always need immediate replacement.

A better question is:

What is the safest and most useful next change?

Start with three options

Every major system should be assessed through three practical options:

Retain it. Keep the system as it is, with targeted stabilization and better operating discipline.
Extend it. Keep the core, but add integrations, modern interfaces, data services, or focused applications around it.
Replace it. Remove a module or platform when its cost, risk, or limitations no longer make sense.

The correct answer may be different for each part of the same ERP.

You might retain the financial core, extend the purchasing workflow, and replace warehouse management. That is not indecision. It is a more accurate view of the environment.

Use this decision framework

Assess the system across the following dimensions. Do not rely on age alone.

Dimension	Questions to ask	Likely direction
Business criticality	What happens if the system is unavailable for one hour, one day, or one week?	High blast radius usually favors retention or phased extension.
Vendor support	Is the vendor still providing updates, fixes, and technical support?	Unsupported software increases replacement pressure.
Total cost	What do licenses, infrastructure, support, custom reports, workarounds, and specialist knowledge cost?	High hidden cost may justify targeted replacement.
Data access	Can the system expose reliable data through APIs, exports, or a controlled data layer?	Accessible data makes extension more practical.
Process stability	Is the business process stable, or is it changing every quarter?	Stable processes can remain. Changing processes may need a new outer workflow.
Regulation and audit	What records, approvals, access controls, and audit trails must be preserved?	High control requirements favor staged change and careful parallel operation.
Operating burden	How many people understand the system? How difficult is support?	A shrinking knowledge base increases risk.

Include the shadow costs.

These include the single employee who understands a custom production report. They include manual reconciliation. They include supplier documents moving by PDF and email. They include entering the same purchase order into several systems. They include the cost of hiring people who still know the platform.

Public guidance from SAP also recommends assessing the total cost of the current system, not only its licensing and infrastructure costs. Its legacy ERP assessment guide is a useful reference for that exercise.

The honest answer is often:

Keep the core. Wrap it. Replace the edges.

Map the environment before changing it

Do not begin with a vendor demonstration.

Begin with an inventory.

Document:

Core applications and versions.
Databases and file stores.
Interfaces and scheduled jobs.
Reports and spreadsheets.
User groups and approval paths.
Network dependencies.
Devices, scanners, terminals, and plant equipment.
Manual steps between systems.
Business owners and technical owners.
Backup, recovery, and support procedures.

Ask users to show how work actually moves. The official process diagram is rarely the full process.

A purchase order may start in an ERP, move to a spreadsheet, become a PDF, travel by email, and return as an attachment. A work order may be entered into one system, printed for the floor, and re-entered when the work is complete.

Those steps are part of the system. If you do not map them, you will miss them during modernization.

BCI-IT’s legacy systems and network support practice follows this sequence: understand the current estate, stabilize critical operations, map dependencies, and then move through phased modernization.

Stabilize what carries critical work

Modernization should not begin with a major disruption.

First, reduce avoidable risk in the current environment.

That may include:

Removing unsupported components where possible.
Documenting critical procedures.
Reviewing backup and recovery steps.
Recording system ownership.
Fixing fragile scheduled jobs.
Improving monitoring and visibility.
Reviewing access rights and least-privilege controls.
Creating a change record for important updates.
Testing recovery procedures.
Resolving network issues that affect system performance.

This work may not look impressive in a steering committee presentation. It is still important.

A modernization program built on an unstable network, unknown dependencies, and undocumented reports will move slowly. It will also produce arguments about symptoms instead of decisions.

Build a data and integration layer

The old ERP does not need to perform every new function.

It needs to participate in modern workflows safely.

A data and integration layer can connect the ERP to newer applications without creating a new point-to-point connection for every requirement. It can expose approved data, standardize formats, manage business rules, and provide a clearer record of what moved where.

This matters when:

Supplier documents arrive electronically.
Work orders must connect to field or plant systems.
Store transactions must reach inventory and finance.
Scheduling must connect to staffing or billing.
Warehouse activity must connect to purchasing and fulfillment.
Operational data must move between plant systems and business applications.

The layer should not become another mystery box. Define ownership, access controls, data quality checks, monitoring, and failure handling.

Use clear interfaces. Record changes. Make dependencies visible.

BCI-IT’s cloud software and infrastructure services cover cloud migration, application modernization, integration, delivery automation, backup, disaster recovery, and managed operations across AWS, Azure, and existing environments.

Replace the highest-friction edges first

Do not replace the whole platform because one workflow is painful.

Find the parts that create the most delay, manual entry, confusion, or operational risk.

Examples include:

A supplier portal that still depends on email attachments.
A warehouse screen that requires several duplicate entries.
A custom report that takes days to update.
A scheduling interface that users avoid.
A store process that varies by location.
A form that must be printed, signed, scanned, and emailed.
A production workflow that cannot provide timely status information.

Replace or modernize that edge first.

This approach is sometimes described as gradual replacement. The idea is straightforward. Build the new path beside the old path. Move one process at a time. Keep the old path available until the new one has proven reliable. Then retire the old piece.

It is similar to replacing sections of a bridge while traffic continues to use the remaining lanes. The bridge still needs engineering. The difference is that the organization does not close every lane at once.

Run old and new in parallel when the stakes are high

Parallel operation adds work. It also provides evidence.

For a high-risk process, run the existing and new workflows together for a defined period. Compare:

Transaction counts.
Totals and balances.
Processing times.
Exceptions.
User approvals.
Reports.
Downstream effects.

Define the exit conditions before the parallel run begins.

For example:

Data reconciles within an agreed tolerance.
Required reports match.
Users complete the process without unsupported workarounds.
Performance meets the operating requirement.
Recovery steps are documented and tested.
Business owners approve the transition.

Do not run both systems forever. Set a review date and a decision point.

Keep a controlled release path

Modernization fails when every change becomes an emergency.

Use a controlled release path with:

Defined owners.
Testing in a non-production environment.
Business approval.
Access based on job responsibility.
Change records.
Audit trails.
Deployment checklists.
Rollback steps.
Post-release monitoring.

This applies to ERP changes, custom software, cloud services, network work, and integrations.

A release path also helps you explain the program to a CFO and COO. You can show what is changing, why it is changing, what risk it addresses, and how the business can recover if the change does not work as planned.

Make the business case in operational terms

Do not justify modernization with vague promises.

Tie each phase to a visible business problem:

Fewer duplicate entries.
Faster purchase order processing.
More reliable inventory information.
Fewer manual reports.
Better recovery readiness.
Reduced dependence on one specialist.
Clearer supplier communication.
More consistent store or plant operations.
Safer and more predictable releases.

Then explain what you are not doing.

You are not replacing a stable core without evidence. You are not pausing operations for a theoretical future state. You are not adding a new tool without assigning ownership.

That distinction makes the investment easier to defend.

Decide what stays, what connects, and what changes first

A 20-year-old ERP may be difficult. It may also contain years of business knowledge.

The goal is not to protect old technology forever. The goal is to preserve useful capability while reducing avoidable risk.

Start with the environment map. Stabilize critical work. Add a dependable data and integration layer. Modernize the interfaces and workflows that create the most friction. Replace modules when the evidence supports replacement. Test every phase. Keep rollback possible.

BCI-IT has more than 25 years of delivery experience across legacy systems, cloud environments, software delivery, infrastructure, and network engineering. Our teams work across three countries, with onshore and offshore delivery options and 24/7 support coverage.

Before you commit to a replacement program, have a focused conversation about the current estate.

Contact BCI-IT to map the environment and decide what stays, what connects, and what changes first.