In the rainforest, a strangler fig doesn't kill the tree it grows on by attacking it. It starts as a seed dropped in the canopy, sends roots down around the trunk, and over years quietly wraps the host until the original tree rots away inside it, leaving only the fig standing in its shape. Nothing falls. Nothing goes dark. One day there's simply a new tree where the old one used to be, and almost nobody watched it happen.
It's a strange thing to reach for when talking about business software, but it's the best model I know for how legacy system modernisation should actually work, and the opposite of how most businesses are afraid it has to go.
Every business I've worked with has a version of the old tree still standing. The invoicing system nobody wants to touch. The database that only one person really understands, and they're on holiday this week. The spreadsheet-and-email workaround that's been "temporary" for about six years now. Everyone knows it's a liability. Nobody's had a good enough reason to modernise it, because modernising sounds like felling the whole tree in one go, and that sounds expensive, disruptive, and vaguely terrifying.
Here's the reframe worth sitting with: that system isn't free to keep either. It's just billing you in a currency that doesn't show up as a single number, which is exactly why it's so easy to keep ignoring.
Legacy systems tend to fail slowly rather than loudly, the same way a dying tree doesn't announce it. The cost shows up as friction: reports that take longer than they should, staff who've built quiet workarounds for things the system should just do, an integration that breaks every time a supplier updates their software. For a lot of small and mid-sized businesses, the bulk of the IT budget ends up going toward simply keeping old software standing, which leaves very little left over for anything that actually moves the business forward. And the risk compounds the longer it sits there. Older systems are disproportionately the ones that stop receiving security patches, because the vendor's moved on or nobody remembers how to apply them. It's not unusual for a promising project to get quietly shelved because the legacy platform underneath it simply couldn't take the weight. That's the real sting of an ageing system: it's not that it's slow, it's that at some point it becomes the reason you can't say yes to something good.
None of this is news to the people running these systems. They delay legacy system modernisation anyway, for reasons that are entirely sensible. The scope of the fix feels unbounded, so it's easier to not open that door. The system still works, technically, so there's no obvious trigger to act. And usually, somewhere in the past, a previous attempt at "sorting the IT out" went badly, over budget, over time, and disruptive enough that nobody wants to relive it.
That last one is almost always down to the same root cause: someone tried to fell the tree in a single afternoon.
Rip-and-replace is the instinctive move and it's usually the wrong one for a smaller business. It bundles a long stretch of disruption, a large decision made up front, and one nerve-wracking go-live where everything either works or it very much doesn't. That's a lot to hang on a single weekend, and it's the opposite of how anything actually grows in nature.
The strangler fig approach to legacy system migration means building the replacement alongside the existing system, moving one piece across at a time, and only retiring the old component once its replacement has proven itself doing real work. Invoicing might move first, while stock and payroll carry on as they are for a while longer, still held up by the old trunk until their turn comes. Nothing goes dark. Nothing gets bet on a single cutover.
It takes longer to reach "fully done." It is considerably less likely to take the business down while you're doing it, which is the trade almost every smaller business should make.
In practice, modernising a legacy system without disrupting day-to-day operations starts with an honest map, not a redesign. What systems exist, what depends on what, and which ones nobody can fully explain anymore. That step alone tends to be revealing: the system everyone's nervous about is often lower-risk than the quiet one nobody's thought about in years. From there, the sensible order is whatever combination of highest risk and highest value comes first, which is rarely just "the oldest thing in the building." Quick, low-risk wins, an integration layer that lets old and new systems talk to each other, come before anything structural, in the same way a fig sends out a few exploratory roots long before it can support its own weight.
This is also where prototyping earns its keep. Before committing engineering time to growing a whole new root system around a working part of the business, it's worth putting a rough, clickable version of the replacement in front of the people who'll actually use it, a way of testing whether a single new branch takes before you commit the rest of the plant to growing in that direction. It answers the question an audit can't: does the new workflow genuinely feel better, or does it just look tidier on a slide. We've written about why that step matters more than most small projects give it credit for, worth a read if you haven't seen it: Software Prototyping Is a Strategic Advantage for Small Projects.
Every phase after that should be small enough to undo if it goes wrong, and the transition period, running old and new side by side, deserves as much planning attention as the destination does. It's normal for that stretch to feel like more effort than either system alone, two structures occupying the same space for a while. Owners who don't expect that are usually the ones who panic halfway through.
The payoff, when it's sequenced this way, is a system that stops fighting you: less time spent on workarounds, faster response to customers, and the ability to take on the kind of contract your old platform quietly couldn't handle. There's rarely a dramatic reveal moment where the old system "comes down." More often, you look back and realise it already has, and the business barely noticed the join. It also puts you in a better position to adopt newer tools and AI-assisted workflows further down the line, since those capabilities sit on top of systems that need to be in a fit state to support them first. A modernised core isn't the exciting part of the story, but it's the part everything else depends on.
Where Macaron Land Fits In
This is exactly the kind of work we take on: short, clearly scoped blocks of engineering time, typically measured in days rather than months, brought in to shape the architecture, untangle a specific legacy component, or prototype the replacement before anyone commits to building it for real. No long-term contract, no big-bang rebuild, just expert input at the point it's actually needed, growing the next root exactly where it's wanted.
