Don't Replace Your Legacy System. Wrap It.

Mike Beentjes — Tue, 28 Jul 2026 09:54:57 +0000

We're Byte Me, a software agency from Alkmaar, the Netherlands. The most valuable advice we give clients is usually not "Let's build something new"; it's "Let's not touch the thing that works." Here's why and how.

The rebuild reflex

Every company running a 15-year-old ERP has had this meeting. Someone opens the ancient interface on the big screen, everyone groans, and a decision crystallizes: "We need to replace this."

We understand the reflex. The UI looks like Windows XP. The one person who understands the database retired. Adding a field takes a change request and three weeks. Every new hire asks why orders live in a system older than they are.

And yet, when companies come to us with "We want to replace our legacy system," our first answer is almost always: you probably don't.

Not because rebuilds are impossible but because the odds are terrible. Big-bang legacy replacements are among the highest-risk projects in software. They take longer than planned, cost more than planned, and the scariest part isn't the code: it's the twenty years of business rules buried in that old system that nobody documented. The weird discount logic for that one big customer. The field that means something different depending on which decade the record was created in. The nightly job everyone forgets exists until you turn it off.

That old system isn't just software. It's your company's institutional memory, compiled.

Ugly ≠ broken

Here's the reframe that changes these conversations: most legacy systems don't have a functionality problem. They have an access problem.

The ERP still processes orders correctly. It's been doing so, reliably, for fifteen years, a track record your rebuild won't have on day one. What's actually painful:

Customers can't see their own orders, so they email and call
Sales can't check stock from the road
Data has to be retyped into the accounting tool, the webshop, the planning board
Reporting means exporting to Excel and praying

None of those problems require replacing the core. They require putting a modern layer on top of it.

The wrap: three patterns

In practice, "wrap it" comes down to three patterns, usually combined.

The API facade

Most legacy systems have some way in: a SQL database, SOAP endpoints, CSV exports, and sometimes literally a shared folder. Whatever it is, wrap it once behind a clean API you design:

[Legacy ERP ] ← adapter → [Facade API ] → portal, webshop, apps, reporting

The facade speaks modern JSON/REST (or GraphQL) on one side and whatever the legacy speaks on the other. Crucially, every new thing you build talks to the facade, never directly to the legacy system. That single rule is what keeps your options open later: when the day comes to swap the core, you replace one adapter instead of rewiring ten applications.

Two hard-won rules for the facade:

Read-only first. Reading legacy data is low-risk. Writing into a legacy system is where dragons live; validation rules often exist only in the old UI, not in the database. Ship the read-only portal first; add writes carefully, one flow at a time.
Don't leak the legacy schema. If your API exposes fields called ORDHDR_STAT_CD, you've built a tunnel, not a facade. Translate to a clean model at the boundary, and keep the weirdness contained.

The sync layer

The second pain, double data entry, dies with a synchronization service: a small job that keeps the legacy system and the modern tools in agreement so humans stop being the integration layer.

This sounds trivial and isn't. The design decision that matters is naming a single source of truth per entity. Orders live in the ERP; the webshop pushes to it, never the reverse. Customer contact details live in the CRM; the ERP receives updates. The moment two systems can both "win" an update, you've built a conflict generator, and someone will spend every Friday untangling it.

Keep the sync boring: idempotent jobs, an explicit queue, logging you can actually read, and alerts when something doesn't match. A sync layer that fails silently is worse than no sync layer; people trust it, and it's wrong.

The strangler

Sometimes part of the legacy system really does need to go; the planning module truly can't do what the business needs. That's where the strangler fig pattern earns its keep: build the replacement for that one module against your facade, run it alongside the old one, migrate users, then switch the old module off. The rest of the ERP never notices.

Over years, module by module, the new system can grow around the old one until maybe nothing of the original remains. Or you stop halfway because the remaining core is fine, and that's a perfectly good outcome too. The strangler pattern's superpower is that every step delivers value on its own, and you can stop at any point. A big-bang rebuild delivers nothing until it delivers everything.

Why we push the thin layer (even though it pays us less)

Let's be transparent about incentives, because this industry has a problem with them.

A full rebuild is a bigger invoice than a facade plus a portal. If an agency's first proposal for your legacy problem is a ground-up replacement, ask them to price the wrap-and-strangle route too and watch how they react. An advisor will engage with the comparison; a salesperson will explain why only the big option "does it properly."

We push the thin layer because it front-loads the value: customers get their portal in months, not years. Double entry stops. The scary migration risk shrinks to one adapter. And the client keeps control; every next step is a choice, not a sunk-cost obligation.

The checklist

Before anyone in your organization says "replace" again, run through this:

List the actual pains. Access? Integration? Reporting? Or genuinely missing functionality? Only the last one justifies touching the core.
Find the way in. Database, API, exports—there's almost always a seam. That seam is worth more than a rewrite budget.
Build the facade, read-only first. One clean API, legacy weirdness contained at the boundary.
Kill double entry with sync. One source of truth per entity, boring and observable.
Strangle only what's truly broken. Module by module, value at every step, with the option to stop.

The unglamorous truth: the best legacy strategy usually isn't a heroic rebuild. It's a modest layer of new software that makes the old software bearable and buys you the freedom to decide the rest later.

Byte Me is a software agency based in Alkmaar, the Netherlands. We build custom software, portals, and iintegrations, oftenon top of systems considerably older than our interns. No sales talk, just a good conversation about what works: byteme.nl

Stopping double data entry with a simple API integration

Mike Beentjes — Thu, 18 Dec 2025 13:42:05 +0000

Double data entry is one of those problems everyone accepts until it starts breaking things.

Sales updates a CRM. Operations copies the same data into another system.
Finance exports everything to Excel. Someone inevitably forgets a step. Suddenly you are debugging human behavior instead of software.

Why double data entry keeps happening. Most companies do not suffer from a lack of tools. They suffer from too many tools that do not talk to each other.

Typical setup:

CRM for customers
ERP or planning tool for operations
Accounting software for finance
A few Excel files in between

Each system works fine on its own. The problem starts at the boundaries.
The real cost is not time. Time loss is obvious, but the bigger problems are:

Inconsistent data across systems
Bugs caused by outdated or incomplete information
No single source of truth
People losing trust in “the system”

Once trust is gone, people create their own workarounds. That is when things really spiral.

You often do not need a new system. The default reaction is often: replace everything. In practice, that is rarely necessary.

In many cases, one small API integration already solves most of the pain:

Data is entered once
Updates are synced automatically
Each system keeps doing what it is good at
No big migration. No massive rewrite.

A simple integration beats a complex rebuild

What works well in practice:

Identify one clear data owner (for example the CRM)
Expose or consume a clean API endpoint
Sync only what is actually needed
Add basic validation and logging

That is it.

No fancy architecture diagrams. No over engineering. When this approach works best. This approach is especially effective when:

Teams already like their existing tools
Only a few processes cause friction
Errors have a direct business impact
You want quick, measurable improvement

It is not about perfection. It is about removing unnecessary manual steps.

Final thought:

Most double data entry problems are not organizational issues. They are integration problems. Fix the data flow, and a lot of “process issues” disappear automatically.

If you are interested in practical examples of this approach in real projects, we work on this kind of integration regularly at Byte Me

DEV Community: Mike Beentjes

Don't Replace Your Legacy System. Wrap It.

Stopping double data entry with a simple API integration