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
Top comments (0)