Assume your software will outlive its end-of-life

We still run an Umbraco v4 site. On purpose.

It does everything the customer needs, it does it safely, and the cost of dragging it up to current would buy a lot of things they'd rather have. So it stays. Every so often someone finds out and reacts as though we've admitted to riding a horse to work while the car sits in the garage. End-of-life was years ago. Why is it still running?

End-of-life is a date on the vendor's calendar. It isn't a fact about the customer's business.

That distinction matters more than it sounds, and it's the thing I watch agencies miss when they move from delivering projects into shipping their own software. A version that's quietly doing its job is one of the better places a piece of software can sit. Nobody's touching it and nothing's breaking, and the rare support ticket is a dull one. The trouble comes from underneath. A platform ships a major release that breaks compatibility, a dependency gets deprecated, a support window closes and the security patches stop arriving. The customer didn't ask for any of it. They were happy. The ground shifted.

Everyone asks whether it's still supported. The question I care about is whether it still does the job, and whether it's safe to run. When the answer to both is yes, leaving it alone is usually the sensible call.

The catch is that you don't always get to leave it alone, and you rarely get to choose when.

We learned this one from the buying side. Igloo, our own platform now, came to us from the agency that originally built it on Umbraco. They'd shipped it without much thought for what happens once a version is years past its prime, and the licence terms carried an open-ended support commitment to match. It left us bound to support a set of customers more or less indefinitely, on builds going back five, even ten years. We've since reworked that model, and support is now timeboxed, which protects us and sets a clearer expectation with the customer at the same time. The open-ended version of it was a slow, quiet liability, written into the terms long before anyone felt the weight of it. Anyone who's taken on a product someone else built knows the feeling: you inherit their assumptions about how long it would all last.

I think of one B2B client in particular. A few years back they went through a major version jump that went badly. The platform they were on changed shape underneath them, and what should have been a step turned out to be a cliff. It cost them real money, and more than the money it left them wary. You can't really blame them for that. Next time an upgrade came up, the conversation opened with "remember last time?" Wariness like that is a cost in its own right, and it stays on the books for years.

Here's the principle I'd hand to anyone building software that other people will run for a decade. Assume the version you ship is the version that outlives its own end-of-life. Then build so that day arrives as a non-event.

Keep your dependencies at arm's length, so when one of them is deprecated you're replacing a part while the rest of the system carries on. Don't wed your release schedule to the platform's, since the day they decide to push a breaking change shouldn't be the day your customer's site falls over. And write the documentation as though the person reading it joined the team long after the framework went quiet, since at some point that's exactly who'll be reading it. That last habit gets skipped more than any other. It's also the one that saves you when a five-year-old build lands back on the desk and nobody who built it still works here.

The obvious objection to all of this is security, and it deserves a straight answer. A version being past its support window doesn't make it dangerous on its own. It means nobody's shipping patches for it, which is a different thing. The real question is exposure. What can reach the software in the first place, what sits in front of it, and whether the bits with known holes are the bits anyone can get to. An old system that's well understood and contained can be safer than a shiny current one nobody's watching. What you can't do is stop paying attention. The day you decide an old version is 'fine' and look away, you've turned a managed risk into a liability.

Running old software on purpose, with someone watching its exposure and ready to act when something shifts, is a position you can defend to a board or an auditor. Letting it run because upgrading is a hassle and nobody has looked at it in three years is neglect wearing the same clothes. The work is in telling the two apart, and in making sure you're the first kind.

None of this is an argument against upgrading. Plenty of upgrades earn their keep, and there's a whole separate conversation about when and why, which I'll come to in a later post. The version you ship will most likely still be running long after the vendor has stopped caring about it, so build and document it for the long, quiet life it's going to have. Read "supported" as a useful signal, then judge the system on whether it still does the job. And when a customer's old setup is running safely and doing what they need, recognise it for the win it is, right up until someone else's roadmap takes the decision out of your hands.

We've spent twenty years living with the long tail of software we've built and inherited, the v4 site and the decade-old Igloo builds included. If you're an agency starting to ship your own products, or you're sitting on a system everyone keeps calling "end-of-life" and you're not sure whether that's a problem you have or a problem you've been told you have, we're happy to talk it through.