Forem: Dcentrica Solutions

Software End of Life vs End of Support (2026)

Dcentrica Solutions — Tue, 21 Apr 2026 21:53:57 +0000

...And What It Means When You're Managing Multiple Websites and Applications

Your digital team doesn't struggle to understand what end of support or end of life means in theory. What they struggle with is the weight of knowing what these signals mean in practice when they're responsible for an entire portfolio of websites and applications.

A single outdated component on just one website might be manageable. But across dozens of them, it becomes something else entirely. Planning, delivery, budgeting, and security are all affected, as are customer conversations.

The distinction between software end of life and end of support matters because definitions affect how your teams prioritize work, where risk is building across your digital portfolio, and determines how early you need to act.

End of support vs end of life

End of support (EOS) means software still "works", but its vendor or maintainer has signaled that they no longer actively support it.

What this means practically is that websites and applications become increasingly vulnerable to a security incident or become susceptible to degraded performance because there's:

no bug fixes (may vary by vendor)
Sometimes or no security fixes (may vary by vendor)
no feature development
no technical or vendor support

Essentially, the software itself may continue to be available alongside its documentation, but users or "consumers" of it can have no confidence of it's ongoing compatibility.

End of life (EOL) on the other hand goes a step further. It's a hard-stop, a signal that "this software should no longer be used". The software itself or a specific version of it has been retired altogether. Continuing to run it becomes harder to justify over time.

Building on End of Support, what this means practically is

no bug fixes (at all)
no security fixes (at all)
no feature development (at all)
not available in some ecosystems, repositories, or marketplaces

For website teams, the practical difference is timing:

End of support is usually the point where risk starts to increase.

End of life is the point where that risk becomes much harder to accept.

These may sound like minor distinctions, but it does change how you should plan.

Why things become harder across multiple websites and applications

If you manage one website, life-cycle issues can often be dealt with as they come up. If you're responsible for ten, fifty, or hundreds, then that approach doesn't hold up for long.

Different websites are often running different CMS versions, plugins, frameworks, hosting setups, run-times, and third-party integrations. All of those have their own support timelines and upgrade paths. Each carry different levels of risk depending on what the site does and who's relying on it.

That is where software end of life tracking starts to matter.

Without a clear view across the portfolio, teams end up asking the same questions over and over:

which sites are approaching end of support?
which clients need an upgrade conversation this quarter?
which issues are genuinely urgent, and which can wait?
where is the biggest concentration of risk?
what should the team focus on first?

When those answers are hard to see, maintenance is reactive. Work is driven by whatever breaks, whatever becomes critical, or whatever someone happens to notice first.

Why spreadsheets and manual tracking only get you so far

Most agencies start in a reasonable place. A spreadsheet, wiki or even a configuration management database (CMDB). Maybe a few reminders in a ticketing system, calendars or even a system developed in-house (maybe don't do that). Whatever it is, teams are reliant on an occasional technical audit and a hope that insights are forthcoming.

This can work for a while. But once you're managing multiple websites across different clients, teams, products, or business units, it gets harder to trust and harder to maintain as you scale.

The challenge is not just in the collection of end-of-life data, it's also in turning that data into something usable.

A spreadsheet might tell you a framework version is old. It usually does not tell you:

which live websites or applications are affected
how close each component is to end of support
where the highest business or security risk sits
how work should be sequenced across the portfolio
what needs to be raised with clients or stakeholders now

A life-cycle date on its own is just reference information. The value comes from understanding what that date means in the context of the websites you actually manage.

Resources like our Is It End of Life tool are useful for checking support status across common technologies. But checking a date is only part of the problem. You still need to know how that date affects your portfolio.

When should you update libraries and components then?

Best practice, before support ends (End of Support), not after.

That sounds obvious, but in reality the right timing depends on more than the life-cycle date itself.

Support timelines

If a CMS, framework, or runtime has a published support end date, that should shape your overall planning horizon. A source like isitendoflife.com can help confirm whether a version is still supported, but it does not help create the plan for you, and gathering this information is time consuming over a wide digital portfolio.

Business criticality

Not every website matters equally. A low-risk campaign site and a core business platform may not be treated the same way. The more important the site, the less risk tolerance there should be for unsupported components.

Upgrade complexity

Some updates are minor. Others need code changes, regression testing, infrastructure changes, or stakeholder coordination. The harder the upgrade path, the earlier it needs to show up in planning as these activities will often take weeks or months of your team's capability.

Portfolio scale

If several websites are heading toward support deadlines at the same time, the issue stops being purely technical. It becomes a delivery and capacity problem as well.

Your clients may see this too if you are too busy on what you feel is higher priority, so reputational risk comes into play.

Security and compliance expectations

For some teams, unsupported software is not just untidy maintenance. It can create security, audit, governance, or client assurance issues.

A useful rule of thumb is not to wait until software is obviously obsolete. The better time to plan is while support is still active and the window to act is still manageable.

What teams should actually be tracking

A life-cycle date is only the starting point.

For teams that are already reasonably mature, the more useful question is not just whether a component is supported. It is whether they can see the operational implications clearly across the websites they manage.

This means tracking:

the technologies each website is running
the components are approaching end of support
which components are already end of life
how critical each affected website is
how difficult the upgrade path is likely to be
how soon action needs to happen
how many sites are exposed to the same issue

A team might fully understand end of support vs end of life as concepts and still be carrying more risk than they realize because they cannot see where those conditions exist across the portfolio.

Managing multiple websites without losing sight of maintenance risk

When people ask how to manage multiple websites more effectively, life-cycle visibility is a big part of the answer.

Managing multiple websites is not just about content governance, uptime, or design consistency. It is also about knowing where maintenance risk is building, and being able to respond before that risk turns into disruption.

A more sustainable approach usually looks something like this:

Keep an up-to-date website and application inventory

Know what each website is running across CMS versions, plugins, frameworks, run-times, hosting dependencies, and major integrations.

Map life-cycle status

Track which components are supported, which are nearing end of support, and which are already end of life.

Prioritize by impact

Not every issue needs immediate action. Prioritize based on business criticality, security exposure, effort to remediate, and how broadly the issue appears across the portfolio.

Plan ahead

Use life-cycle visibility to shape quarterly or half-yearly maintenance planning, rather than waiting for urgent issues to force the work onto the roadmap.

Communicate clearly

Make it easier to explain what is coming, what matters now, and where clients or stakeholders should expect investment.

This is where a portfolio-level view becomes far more useful than isolated checks.

It is one thing to know a version is unsupported. It is another to know which websites are affected, how urgent the issue really is, and how that work fits into the rest of your maintenance programme.

Turning life-cycle data into actual planning

Knowing that a version is approaching end of support is useful.

Knowing which ten websites are affected, which three carry the most risk, and which two can reasonably wait until next quarter is much more useful.

That is the difference between reference data and operational visibility.

For teams managing multiple websites, life-cycle information becomes much more valuable when it helps answer questions like:

what needs action now?
what can wait?
where are we carrying the most risk?
which upgrade conversations need to happen this month?
how do we stop maintenance becoming reactive?

Rather than being just another reference source for life-cycle dates, Metaport is designed to help delivery and portfolio managers see maintenance risk across the websites they manage, identify where attention is needed first, and plan work more confidently.

Metaport achieves this providing tools such as the App Planner, Policy-based notification and the Application Health Report for each application.

We will continue to build new features that focus on these questions, and we'll continue to not fall into the 'AppSec tool' trap. All the while we invest in meaningful integrations to compliment tools you are already using at a technical layer such as Dependabot, JIRA, DependencyTrack, Redmine, GitHub and GitLab.

For agencies and digital teams that have outgrown spreadsheets and one-off audits, Metaport points to a more practical way of turning life-cycle and dependency information into portfolio-wide planning, risk awareness and prioritization.

Some final thoughts

The difference between end of support and end of life does matter.

But for teams managing multiple websites, the bigger issue is not definition. It is visibility.

End of support: Usually the point where risk starts rising.
End of life: When deferral becomes much harder to defend.

The challenge is being able to see those signals clearly across the portfolio before they turn into urgent problems.

That is why software end of life tracking matters in practice. Better visibility leads to better planning, better prioritization, and better conversations with clients and stakeholders.

If your delivery leads are already checking support dates by interrupting your developers, spending hours manually curating spreadsheets, the next step is being able to see what those dates actually mean across the websites you manage.

Do you work in a digital agency? We'd love to know how you're thinking about your own internal systems.

If you want to level-up your own agency's website and application monitoring, alerting, and planning, then be among the first to know when Metaport SaaS arrives.

But don't take our word for it, have a look at it yourself and let us know what you think.

Should agencies build their own website security and maintenance solutions?

Dcentrica Solutions — Mon, 20 Apr 2026 01:26:18 +0000

Or: Why agencies shouldn't build their own Alpaca Management System.

We've been talking to agency development teams for quite some time and it remains a fascinating process. We've gone from assuming that studio and agency maintenance practices leave something to be desired, to having the data tell us they are. *

Of those companies we've spoken to, we found that some have almost no formal maintenance processes or reporting tools at all (we're talking to these guys). Others already operate well-known application security tools for monitoring and notification.

But most pertinent are those agencies we're not talking to at all. Rather, they don't want to talk to us.

Why? Because they've cobbled together a solution themselves which appears to work for them for the time being.

It's April 2026 and the age of AI is very much upon us, where practically anyone can build and deploy a software application in a matter of days.

There's a story being told of the decreasing existential moat supposedly surrounding traditional software and SaaS providers which we'd like to drill into: Does self-managed software - built with the help of AI or otherwise - really spell the end of the traditional SaaS? Or are we collectively missing the obvious?

When I was a senior developer, I'd advocate that my team allocate at least 25% of their estimates to doing nothing at all.

OK, that's not strictly true. Developers are knowledge workers, so what I was actually asking was that the 25% be spent just thinking, something developers find hard to do in front of a keyboard because in their world, key-presses == productivity.

So it would be more than a shame if as engineering professionals, a developer's hard-won skills, knowledge, and experience were cast aside because when considering building a tool ourselves - we'd have fallen at the first hurdle - not thinking too deeply first.

Back in the day

Going back to first principles, it's pertinent to ask why does SaaS as a category of software even exist? And while we're at it, we might equally ask why anyone uses software at all?

Software didn’t used to be so-named. It was commonly referred-to as a program, only available for install on a desktop PC via a floppy disk. Later it was available via the upstart CD-ROM, and later still came the internet which provided the ability to download all that you needed (and much that you didn't, but did anyway).

SaaS is just the most modern incarnation of software-programs along these same principles we've been used-to for decades. Prior to the relatively modern era - 2010 and after, we had "Application Service Providers" (ASP), "Web-based Software", and "Cloud Applications" to name just three.

Apart from the name; software upgrades, new features, bug-fixes, and design tweaks are provided to users with the same minimal amount of effort required. The same can be said of how software is paid for. Old school programs came in a physical box with a manual which mostly went unread, and was purchased from a physical shop.

The main difference is that users no longer need to exert any physical energy downloading or installing anything (pulling out a company credit card doesn't count). For products and services offered over the web, the subscription based payment model has since become the ubiquitous standard.

Irrespective of whether it's downloaded, installed, or web-based, software provides something which its users cannot do, don't want to do, or can do vastly more efficiently than they alone can ever do. And it's among these three advantages where the software value proposition lies, a proposition predicated on something being cheaper, faster, or less hassle to pay someone else to manage, than it is to do otherwise.

Were Alpacas the way forward?

I once visited an Alpaca farm in the early 2000s. I got talking with the owner who quietly disclosed to me that only half of his income derived from farming the animals themselves.

His further disclosure as to where the other half came from will go with me to my grave:

Alpaca Management System!

This guy had developed alpaca management software and he had a monopoly on the market (it was the only such software in existence at the time). The software was distributed via CD-ROM and when a new version was released, it was just sent out via snail-mail.

Alpaca have unique characteristics which owners and farmers need help with in order to get the most (money) out of the animals which the system provided to its users, something the users alone could not (easily) provide for themselves.

From Alpaca to AI

The messaging from AI providers and those engineers at the bleeding edge of agentic AI and AI-powered software development, seems to be that everyone is either going to build - or should soon be in a position to build - their own Alpaca Management Systems.

But anyone who's built software professionally for any length of time should have a few questions by now. Chief among these for us is to ask who (or what) is responsible for the things we currently pay traditional software providers to do on our behalf?

Assuming that an AI is never asked to "mark its own homework" by designing, building, and testing its own output, then the most suitable candidate is someone with hands-on experience in managing software maintenance, performance, APIs, platform and framework upgrades, as well as UI redesign work.

An experienced software engineer employed as an internal agency resource for example.

I think it's useful to ask what we think AI should really be doing for us. When something is capable of assisting in the build, test, and deployment of software, and doing so faster than any traditional delivery team, and when anyone can build software to a specification, doesn’t the proverbial rising tide raise all boats, not just your own?

And where is the business left whose value proposition is perhaps predicated on faster time-to-market as a result of software built in-house, when their competitors can do exactly the same thing themselves and at the same speed?

While everyone is seemingly focused on a race to the bottom, what actually happens to the software under production when the internal resource - the one hand-holding the AI - is inevitably requested to do internal, billable work?

We've seen what happens when the very systems agencies have commissioned to monitor and report on the maintenance standing of customer's websites and applications is itself in urgent need of monitoring and maintenance.

When this happens, we'll have arrived at an interesting purgatory which previously existed at the tail-end of the installable software era, and at the onset of ASP/Web-based/SaaS era. An era characterized by Frankensteinian ticketing systems, internal search engines, and where customer data was stored on intranets.

Maybe an AI assistant could be deployed to remedy the situation. But to do so in such an unplanned, ad-hoc fashion looks way too much like the situation our non-communicative agency friends appear to be trying to avoid.

We kicked-off an industry survey in early 2025 and which is still going. Give it a nudge here.

Do you work in a studio, development or agency team? We'd love to know how you're thinking about your own internal systems.

If you want to level-up your own agency's website and application monitoring, alerting, and planning, then be among the first to know when Metaport SaaS arrives.