This is one of those problems that can sit quietly in the background for a long time. A website launches. An application goes live. The team celebrates briefly and moves on to the next project. Over time, that new system becomes one more thing in a growing estate of frameworks, libraries, dependencies, hosting environments, SSL certificates, integrations, APIs, and security obligations.

Nothing looks especially urgent if you or your org has maintenance blind spots.

A framework reaches end of life (EOL). A dependency vulnerability is published. A client asks whether they are exposed. A developer has to stop planned work to investigate. A project manager has to re-scope work that now needs budgeting. Maybe a Statement of Work is required. Maybe a proposal or business case needs to be built. Someone then has to explain why something that “just worked” last week now needs time, money, and attention.

The technical fix may be a few hours, a few days, or in the case of larger upgrades and migrations, several months. The cost around the fix is usually the bigger problem.

In our whitepaper, Hidden Costs in Application Maintenance: How Proactive Agencies Win, we describe maintenance as a blind spot in agency operations. Not because teams are careless, but because the information needed to manage maintenance properly is often spread across engineering knowledge, Slack threads, spreadsheets, hosting platforms, existing application security (AppSec) tools, version control repositories, and individual memory.

Maintenance is often reactive. It starts after something fails, after a client escalates, or after a security risk becomes visible enough that it can no longer be ignored. The knowledge is also usually siloed. Developers may know where the risks are, but that does not mean project managers, account leads, delivery leads, or executives have a useful portfolio-wide view or know if a problem found in one project doesn’t also affect others.

That is where the issue stops being technical and starts becoming commercial.

Unplanned maintenance pulls people away from planned work. It creates context switching. It disrupts delivery momentum. It makes budget conversations harder. It can make an agency look less in control than it actually is.

What Reactive Maintenance Costs in Real Terms

Using conservative industry data and typical developer charge-out rates of USD $75–$150 per hour, the financial cost of ad-hoc maintenance can be modeled fairly quickly.

Take cross-portfolio end-of-life (EOL) planning as one example.

If EOL planning takes around 10 hours per project annually, spread across developers and project managers, then a 10-project portfolio represents roughly 100 hours of unplanned effort. At

USD $75–$150 per hour, that equates to USD $7,500–$15,000 per year in time that may not be properly forecast, budgeted, or recovered.

Now take cross-portfolio vulnerability review and risk analysis. If vulnerability review takes around 1 hour per project, per week, then a 10-project portfolio creates around 10 hours of recurring weekly effort. At the same charge-out range, that becomes approximately USD $3,000–$6,000 per month in avoidable cost.

That is before the wider operational cost is counted: context switching, delayed roadmap work, emergency client communication, re-planning, proposal effort, and the loss of confidence that comes when clients feel issues are being discovered late rather than managed early.

For one application, the cost may feel tolerable. Across 20, 40, or 100 maintained applications, the numbers start to look very different. This is the commercial shape of the problem.

Reactive maintenance is not just a technical risk. It is margin leakage hiding inside normal delivery operations.

Leveraging AI Makes This More Complicated at Scale

AI is making it faster to create software, scripts, internal tools, prototypes, features, and automation. That is useful, but it also means organisations may be creating more digital assets than they have maintenance discipline for.

Every new asset creates a future obligation. Dependencies need monitoring. Runtimes need patching. APIs change. Hosting environments age. Security risks emerge. AI-generated code may also introduce patterns that are harder to understand later, particularly when it was created quickly and without enough architectural context.

The AI cost model is changing as well. More AI platforms are moving toward usage-based pricing or tightening the economics around heavy use. So the cost of running and maintaining digital assets is no longer just hosting, software licences, support retainers, developer time, and security tooling.

AI usage itself becomes another cost line teams need to understand and justify.

That matters because the reactive maintenance cost is already material. Even a simple 10-project model can point to USD $7,500–$15,000 per year in unplanned EOL planning effort, and USD $3,000–$6,000 per month in recurring vulnerability review and risk analysis.

If AI increases the volume of software being created, and adds another usage-based cost layer to reviewing, analysing, remediating, and maintaining that software, visibility becomes more important, not less.

That creates a simple but uncomfortable question:

Are we creating more digital assets than we can afford to maintain well?

That is not an argument against AI. It is an argument for better visibility. Shipping faster is only useful if teams can still govern, secure, maintain, and explain what they have shipped.

The Fix is Only One Part of the Cost

A common mistake is to measure maintenance by the fix itself. That misses all the surrounding cost that customers may assume is simply “a cost of business.”

The maintenance question is no longer just

How much does it cost to fix this issue?

It is closer to

How much are we spending to discover, understand, explain, prioritise, and repeatedly rework issues we could have seen or planned for earlier?

What Changes When Maintenance is Planned

A proactive agency has a different conversation with its clients. It can see which applications are approaching end of life. It can identify which clients are affected by a vulnerability. It can plan upgrade windows before they become emergencies.

The tone of the conversation changes from,

We have a problem and need to fix this urgently

to:

We are tracking this across your environment. Here is what is coming, here is the likely impact, and here is how we recommend planning for it.

Commercially, it is significant. It builds confidence. It makes maintenance easier to budget. It gives project managers better information. It also creates a stronger basis for ongoing client relationships. Maintenance stops being only a cost centre and becomes part of the service model.

Where Metaport Fits

This is the problem we are working on with Metaport.

Metaport is designed to help agencies and digital teams see maintenance risk across the applications they manage. It brings together signals around end-of-life (EOL), dependencies, vulnerabilities, and SSL expiries, so teams can move from reactive discovery to proactive planning.

The value is in making maintenance risk visible at the portfolio level, in a way project managers, delivery leads, and leadership can actually use.

Because the hard part is not always fixing the issue. Often, the hard part is seeing it early enough to have the right conversation, with the right person, at the right time.

Want to stop maintenance from creeping up on you?

Take a tour of Metaport

Your digital teams don’t struggle to understand what end of support or end of life mean in theory. What they do struggle with is the weight of knowing what such signals should 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’s 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 how early you need to act.

Do you manage multiple websites at scale? We’re keen to talk to you. How do you plan for End of Life and End of Support?

Lets chat

End of support vs end of life

End of support (EOS) means software still “works”, but its vendor or maintainer is signaling that they’re no longer actively supporting it.

What this means practically is that websites 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

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, runtimes, 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.

So, when should you update software?

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.

We know a thing or two about agencies and managing software EOL dates.
In this guide, we offer some practical steps and boilerplate copy for use in your own customer conversations.

Get EOL Guide

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 a current inventory

Know what each website is running across CMS versions, plugins, frameworks, runtimes, 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.

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 is usually the point where risk starts rising.

End of life is where 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.

That is exactly the kind of visibility Metaport is built to provide.

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.

Take Tour

We’ve been talking to agencies for quite some time. It has been, and remains a fascinating process - because we’ve gone from assuming that agency maintenance practices leave something to be desired, to having the data tell us that it is indeed so. *

Of those we’ve spoken to, we’ve found that some have almost no formal maintenance processes or reporting tools (we’re talking to these guys). Others already operate well-known application security tools for monitoring and notification (Metaport integrates with some, so we’re talking to these guys too).

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

Why? Well it’s not for want of asking. It’s because they’ve cobbled together a solution themselves which appears to work for them for the time being.

Is your agency in this camp too? We’re keen to talk to you. What did you build? Out of what, and why?

Let's Chat

Democratising software or diminishing lived experience?

It’s March 2026 and we’re very much established in the age of AI 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 want to query: 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 would 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 I what I was actually asking was that the 25% be spent thinking. Developers find not doing physical things like that really hard because in their world, key-presses == productivity.

So it would be ore than a shame if as engineering professionals, our hard-won skills, knowledge, and experience were cast aside because when considering building a tool ourselves - we’d 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” and was 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 the 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. As is the means by which software is paid for. Old school programs came in an actual box with a manual which mostly went unread. They were 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 near ubiquitous standard.

Irrespective of whether it is downloaded, installed, or web-based, software provides something which its users can not not 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 and 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). It 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, which 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, which can be done 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 software, is itself in urgent need of monitoring and maintenance.

And when this happens, we’ve 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 characterised 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 un-planned, ad-hoc fashion looks way too much like the situation our non-communicative agency friends appear to be trying to avoid.

Thanks for reading.

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

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.

Try Metaport

Every company seeks stable, predictable revenue. And for agencies the cyclical workflow makes that especially critical:

Specification → Design/Build/Test → Launch → Next project

When agencies treat maintenance as an afterthought, they leave revenue on the table and risk reputation damage if an incident occurs. In today’s AI‑driven world - where vibe‑coding, spec driven development (SDD), and agent orchestration accelerate delivery, then simply “keeping the lights on” after launch is no longer sufficient (if indeed it ever was).

Just as human developers benefit from peer review, AI‑generated code also needs a systematic review process. By embedding ongoing health checks and post‑launch stewardship into the delivery pipeline, agencies turn maintenance into a revenue‑generating, risk‑mitigating advantage.

Does your agency do its own health checks? Let us know what they include. Would automated reporting be useful?

Let's Chat

Predictable revenue as a component of consistent delivery

Agencies thrive on mature, predictable revenue, and that starts with a maintenance program that customers value and rely on. By keeping digital products under active, ongoing care, just as we would with physical assets, businesses reduce risk and unlock growth.

A proactive approach tackles three often‑overlooked challenges:

• Software End‑of‑Life (EOL): Updating libraries, frameworks, and servers before support ends eliminates surprise upgrades and migration costs, keeping services smooth and uptime high.

• Security Posture: Regularly patched software blocks attackers, protects data, and preserves brand reputation, turning potential fines and breach expenses into savings.

• SSL Certificate Renewal: Timely reminders, as well as automated renewals prevent “Not Secure” warnings in browsers, sustains SEO/GEO rankings, and maintains conversion rates, freeing teams to focus on planned initiatives.

Providing a health‑check for every managed application which covers these three indicators, gives agencies and their customers a clear, data‑driven picture of risk, reinforcing confidence and driving steady, predictable revenue.

Why health metrics strengthen maintenance agreements

A maintenance agreement isn’t a cure‑all, and major upgrades are rarely covered because of upfront costs and limited end-of-life (EOL) data. Still, modern contracts are already tying performance to clear metrics such as Return To Operation (RTO) and Recovery Point Objective (RPO), priority‑based response times, and expiry‑date windows. So adding agency‑specific health data is both feasible and valuable.

The key is in presenting that data in the customer’s language. When a customer asks, “Do we really need this?” the answer should focus on the protective benefits rather than the expense:

• Business continuity: Up‑to‑date software, licenses, and certificates keep operations running smoothly.

• Regulatory compliance: Continuous compliance avoids costly audits and penalties.

• Brand reputation: A secure, reliable service reinforces trust with users and partners.

When health metrics are displayed in concise reports which include executive summaries, clear recommendations, and a side‑by‑side view of the current state versus the cost of doing nothing, customers can see the tangible value. The maintenance line item then becomes a logical, even essential, investment in stability and growth.

How a rapid health check works (and why it’s valuable)

A health check for a typical midsize website or web‑app can be compiled in less than a day, making it a practical, repeatable component of any agency’s maintenance routine.

1. Data collection & cross‑referencing: Every library, framework and O/S version is matched against vendor support calendars to surface upcoming end‑of‑life dates.

2. Scoring model: The system weighs vulnerability severity, business impact of impending EOL dates, and SSL‑certificate timelines to generate a single, easy‑to‑read Health Score.

3. Executive summary: The score is visualised as green (on‑track), amber (needs attention), or red (at risk), giving leaders an instant view of application health.

4. Recommendations summary: A concise “fix‑now” list is paired with a risk‑impact brief that outlines the benefits of timely remediation.

Because metrics are expressed as concrete numbers or clear “stamps” (e.g., “3 critical CVEs, framework EOL in 24 months, SSL renewal in 30 days”), the report transforms abstract concerns into specific agenda items for the next customer account meeting.

The result is a proactive roadmap that protects continuity, strengthens compliance, and builds confidence in the digital product’s long‑term performance.

How detailed the report is and how fast it can be prepared now become key differentiators for agencies: Customers expect to see risk before it materialises.

Metaport provides on demand health reports for every application in your portfolio.

Try the demo

Application health as a strategic benefit

A health‑check report gives agencies a natural upsell path, differentiates them from competitors, and boosts customer retention. Customers who see continuous value rarely churn after the first project.

Risk scores can be fed straight into customers’ risk registers, satisfying auditors and board members, while the recommendations give them enough foresight to budget upgrades proactively instead of scrambling at the last minute.

Most importantly, knowing their website or app will stay secure, compliant, and performant underpins marketing campaigns, drives conversions, and strengthens overall trust.

We call a one‑day turnaround “fast”; from the customer’s view, consistent delivery is the next biggest advantage.

Embedding health reporting into a website maintenance programme

A solid maintenance programme is built around recurring snapshots that capture health‑check findings, risk levels, and clear actions. Typical alerts look like:

• “Two critical CVEs. Patch within 48 h.”

• “Framework reaches end‑of‑life in Oct 2026. Start migration planning this quarter.”

• “SSL certificate expires 15 Jun 2026. Renew by 1 Jul to avoid browser warnings.”

By weaving health checks into support contracts, agencies turn a one‑off service into an ongoing partnership. And with the right tooling, reports are generated immediately and automatically, slashing production time and cost while still providing a billable and value‑driven deliverable.

A call to action for agencies

1. Standardise the health check: Build a repeatable workflow and embed it into your delivery pipeline. It can be as simple as a bullet‑list in a wiki; elegance isn’t the name of the game but consistency is.

2. Turn the first check into a teaching tool: Show customers how a regular “website‑maintenance” review safeguards their revenue. Price the value, not the labour, and position the contract fee as a risk‑transfer.

3. Showcase the report: Publish anonymised examples on your website and company LinkedIn page. Demonstrating real‑world insights builds credibility and even draws-in new business.

Closing thoughts

Security‑related incidents are climbing every year, and a single breach can erase months of SEO, GEO, and brand investment.

When software components are refreshed as often as you get a haircut, website and application health is no longer an optional pillar of any agency’s digital strategy.

A disciplined maintenance programme anchored by regular health checks and a clear, actionable report delivers three simultaneous advantages:

1. Protects both the customer’s and the agency’s business from costly downtime and compliance gaps.

2. Creates a sustainable revenue stream by turning reactive fixes into proactive stewardship.

3. Builds trust, converting one‑off projects into long‑term partnerships.

If your agency still treats post‑launch support as an afterthought, you and your customers may be one incident away from a pretty rough day.

Take the first step today: run a health audit on a recent launch, share the findings with the customer, and watch the conversation shift from “extra cost” to “strategic investment.”

Use this example application health report generated by Metaport as a starter.

Having trouble persuading your customers to upgrade? Take inspiration from our Agency EOL Survival Guide.

Metaport powers-up your agency with:

• Cross-portfolio search (end-of-life, vulnerabilities, packages) and notifications

• Customer-shareable assets like EOL roadmaps, calendars and health reports

• Integrations with existing AppSec and task management tools

Sound interesting? Try the demo for free or join the waitlist.

Try Demo

What’s a portfolio anyway?

It doesn’t matter if you’re a gargantuan digital agency or just a freelancer. If your customers number in the tens or the thousands, the collection of websites and applications you manage on their behalf represent your portfolio.

Much like a hire car company, the window into your portfolio is the single source of truth that tells you which customer owns which application in your “fleet” - even if that window is provided by a wiki, a CRM, some spreadsheets or someone’s head.

For that hire-car company to run smoothly, it needs to know the condition, road-worthiness, and geographical location of each vehicle. Without that information being readily available to all parts of the business, it’s very hard to reliably hire anything out to a customer.

Digital agencies themselves have been around since at least the mid 90s, so it’s hard to imagine their fleet management models not working working well.

But if that’s the case, why do charts like this exist in the 2020s?

With respect to security vulnerability remediation, dependency management, and end-of-life (EOL) software planning, it appears as though agencies still have some work to do.

How well does your agency respond to maintenance issues and security threats?

Take Agency Survey

Why should portfolios be managed?

If the previous chart needs a summary it’s that agencies don’t appear to have a birds-eye view of their fleet. If they did, you’d expect the numbers to be lower.

If teams can’t easily identify where an application is hosted, the technologies and versions it’s built from, and when dependencies and components need to be updated, it’s an expensive challenge rather than a well-practiced workflow to supply colleagues and stakeholders with timely information for feature development, planning and budgeting purposes.

Keeping on the right side of support contracts is harder too. Upcoming delivery and maintenance work is based on the current state of those applications, which if not known, means it’s also harder to convince customers to sign support contracts.

Security Vulnerability Management

Data-breaches, zero-day exploits, and other internet malfeasance with the potential of harm at a national level now occur every single day to companies somewhere in New Zealand and globally.

• Log4Shell - 2021 (Global): 100+ million affected applications and devices

• Medicare - 2024 (Australia): 12.4 million individual (people) affected

• Shai Hulud - 2025 (Global): 700+ open source JavaScript packages affected

• ManageMyHealth - 2025 (NZ): 120,000 personal health records leaked

As an agency, it’s definitely worth asking tough questions like these as often as possible:

• “Are we prepared for the next Shai-Hulud style supply-chain attack?”

• “How will we identify which of our apps is affected when it happens?”

Your existing security tools will absolutely help you in these situations, but if only a subset of your customers’ apps are hooked-up to them, then you’ll need a plan for effectively attending to the remainder.

Many security tools are designed to be triggered from automated Continuous Integration (CI) pipelines, but for many agencies such setups are still not common.

End of life (EOL) Software Planning

Vendors of licensed software such as Microsoft, Oracle, RedHat, and others, usually have a close relationship with their customers who are tuned into their product announcements.

The same arrangement doesn’t really exist in much of today’s websites and web-applications, built as they are from hundreds of third-party, open source software packages.

A software product’s road-map represents the dates when new features will be added, old ones removed, and legacy versions retired. But for open source maintainers however - whose work is often voluntary and unpaid - the resources don’t exist for road-maps of any kind.

In this scenario, agencies need to take up the slack and monitor their own systems and those of their customers for such maintenance issues on a “best efforts” basis.

And when this happens, some agency blind-spots reveal themselves:

• Poor End-of-life (EOL) data availability, so EOL is simply ignored

• Security tools focus on individual codebases and container images, not collections

• Cyber and DevOps roles leverage technical data, but don’t plan the work, PMs do

When portfolios are managed in part using security tools with a focus on individual “things” - repositories, registries, images - then it is difficult to prioritize and assess risk across portfolios, so what’s an agency to do?

If your agency doesn’t already have a portfolio-wide dashboard, make a start with an application/website inventory. Use wikis, CRMs, or Metaport which is designed for agencies.

Without one, agencies cannot quickly identify when key software components are no longer supported. With this knowledge, cybersecurity risk is reduced because of the advanced notice for replacing unsupported products that are more susceptible to security vulnerabilities.

For legacy application management the OWASP has its own advice, as does this useful one-page Agency End-of-life Survival Guide.

How does your agency do EOL planning? Is it lagging behind, or worse, is it not doing it at all?

Let's Talk

So how are agencies managing their portfolios?

An agency business is an outcome orientated organization and outcomes govern an agency’s portfolio management strategy. Some have a customer-first or operational risk perspective, others may be more process, workflow, or revenue driven.

Whichever way your agency does it, it needs to be done with full awareness as to the pros and cons of each approach.

In our previous post Why SCA, SAST, and SBOMs don’t equal EOL planning for digital agencies, we put forward the case for security tooling which represents the business of agencies better.

In this post, we’re also advocating for fleet management tools designed for digital agencies, with the best news of all being that the two are not mutually exclusive.

If you or your agency wants to be the first to know when an agency orientated portfolio management system finally lands, join the waitlist.

Join Waitlist

It’s all about expectations

The right time to promote the importance of maintenance and support contracts is when customers approach agencies to inquire about working on a new software project or to purchase website maintenance services.

Ask any project manager and they’ll tell you that setting expectations early is what you do before any delivery starts. It pays dividends down the track when things inevitably change and course corrections are needed.

But be careful not to over-promise. When that happens, the pressure is on the agency to maintain what could become an unsustainable effort over the relationship’s term. It then becomes quickly obvious that slowing down or reneging is all but commercial suicide.

Under-promising on the other hand gives agencies some wiggle room, but only when the intention is to improve. With respect to website maintenance services, it’s the agency’s responsibility to flag its importance proactively - it is the domain expert after all.

How does your agency deal with setting expectations? When do you broach maintenance expectations with customers? We’d love to know.

Let's Chat

Who should be suggesting a maintenance contract anyway?

Whenever a customer has a strict set of security, performance, and maintenance requirements of their own is the ideal time to play any trump cards you have, and to wrap an eventual contract around them:

• 24x7 or round-the-sun support

• Standardized Recovery Point Objective and Recovery Time Objective (RPO and RTO)

• Repeatable maintenance workflows for mitigating security vulnerabilities

• Documented pricing (or pricing ranges)

• Boilerplate plans to underscore end of life software best practices when end-of-life (EOL) dates hit (upgrades, LTS, or NES licensing)

For those less technically savvy customers, it behooves agencies to be pragmatic and to ensure that both entities are covered from a business perspective with auto-renewing support contracts, because without one:

• Ad-hoc maintenance work means unpredictable income and inconsistent risk mitigation

• Incident response takes longer as there’s no documented process

• Customers’ production applications are left vulnerable for longer

• Tooling investments become harder because sufficient revenue isn’t available

Smoke and Mirrors vs Actual Process - The Fine Line

As an agency, you’re most qualified to understand maintenance and contractual shortcomings.

Everyone knows maintenance isn’t sexy, that developers will complain, and convincing customers to spend money on work they and their own stakeholders won’t be able to see, remains very challenging.

But if in sales pitches and RFP responses, agencies find themselves needing to stretch the truth in order to win work, that’s a strong “smell” that it’s only a matter of time before being approached for similar work and having to repeat the effort, while the rest of the team again fails to navigate what’s been promised - absent themselves.

There is an intermediary state which agencies can sometimes adopt. While “approximating” their actual capability in a pitch, the business may decide prior to allocate internal time - noting it as an investment, and not another internal cost - to actually use what’s been pitched as a guide for exactly what needs to be done better, when compared to current state:

• Named: Specific AppSec and ASPM tools used in day-to-day maintenance

• Documented: Steps followed in security vulnerability and incident responses

• Specified: Incident response times, RPO, and RTO calculations

• Planned: Deliberate software EOL upgrades, budgets, and license timelines

Going one step further, agencies can augment existing website copy and sales material with these - their principles of maintenance excellence.

Such self-promotion is a valid point of difference worthy of consideration by prospective customers which may not immediately invoke an understanding of its value proposition. But by virtue of its inclusion in promotional material, should cause customers to pause to consider.

Follow the Money

In business, everything boils down to money. Agencies are no different and repeat, predictable income is king. Even the most well-intentioned and process-driven agency still needs to profit enough from its activities to stay in business and to build amazing software.

So it shouldn’t be too revolutionary to concede that effort-in equals revenue-out with respect to developing and promoting customer support contracts.

Revenue earned from support work can be reconciled with upgrade, re-licensing, and decommissioning projects from those same customers. With the right analysis, marketing and sales material becomes more targeted, as do your customer conversations.

Why is it so difficult?

There are a few possible reasons for the existence of customers and their web applications - sans any sort of maintenance contract.

The History Factor

There are 15+ year old Java and PHP monoliths still chugging away out there with little more in the way of a support contract, than a promissory note for maintenance services rendered.

The situation is unlikely to change until something forces the hand of an agency or its customer - say a state sponsored DDOS attack on key government web infrastructure for example.

The Invisibility Factor

Some customers will justify not paying for something if they cannot see it. Precisely because of this, an agency’s hands are tied, unable as they are to provide a satisfactory reason for work the customer is technically correct in saying no-one will ever see.

What can be seen though is data from governments around the world describing the downstream effects and costs to business of security vulnerabilities found in commonly used software.

• Log4Shell - 2021 (Global): 100+ million affected applications and devices

• Medicare - 2024 (Australia): 12.4 million individual (people) affected

• Shai Hulud - 2025 (Global): 700+ popular JavaScript packages affected

The Implausibility Factor

Humans are awful at accounting for things which haven’t occurred yet. Some go further and adjust mental models and end up believing that something awful will never occur - the commercial equivalent of burying heads in sand.

The irony of this attitude isn’t lost on security practitioners. Data-breaches, zero-day exploits, and other internet malfeasance with the potential of harm at a national level now occur every single day to somebody, somewhere in New Zealand and globally.

No matter how much agencies - and even customers - might wish to rationalize away the potential of something “bad” happening to them, forewarned is fore-armed.

Has your agency encountered any of these issues? Let us know, we’d love to talk.

Let's Talk

So, what’s an agency to do?

Irrespective of your agency’s maturity with respect to its ratio of customers to valid maintenance contracts, consider the following as a summary:

• Talk to customers: Support plans aren’t needed on day one, but an intent to get one is. Design one together with your customers

• Know your portfolio: Update it often. CRMs, wikis and spreadsheets get stale quickly

• Understand threat landscapes: Armed with some knowledge of popular modes of attack, find real world examples featuring similar technologies

• Implement security tooling: Some application security tooling is better than none but not if only a subset of a portfolio is covered

• Push back: Contrary to popular belief, customers will respect you more. Agencies have the domain expertise, so armed with context, experience, and knowledge - argue your position

In our previous post Why SCA, SAST, and SBOMs don’t equal EOL planning for digital agencies, we put forward the case that there’s a need for maintenance and security tooling which represents the business of agencies better.

If you or your agency wants to be the first to know when agency orientated security tooling finally lands, join the waitlist.

Join Waitlist

You can also level-up your agency’s approach to end of life software best practices. Get the 1-page EOL Survival Guide for agencies.

The unique business model of an agency

We’re seeing many “helpful” LinkedIn recommendations which offer to help companies achieve more secure software. What’s clear from reading them is that the business of digital agencies is less well known outside the ecosystem than you’d imagine.

From a pure security perspective, greater exposure to security realities is a good thing - even for agencies - that is unless the initial steps needed to improve security standing is more difficult to achieve than for other IT companies.

Agencies are getting the message from their industry counterparts and from customers though: That security-first and maintenance-first delivery is fast becoming the only acceptable way of doing business in the 2020s.

Indeed, recent experience demonstrates that buyers score RFPs based on how respondents claim they secure and maintain the system in production. With an increase in agency uptake of application security tools, then the signals appear generally positive that agencies are taking note.

Just one small problem remains: Most of today’s application security tools are not actually built with agencies in mind at all.

If planning is a core part of customer-facing roles in high-performing agencies, then it follows that they either require dedicated security resource to triage and action security tool outputs or that a repeatable workflow is implemented for use by the rest of the team.

Failing in either respect is the difference between useful data and data which is actually usable.

Which AppSec tools does your agency use? Do they provide a portfolio-wide view for your team?

Take Survey

Security platforms aren’t “security tools” in the traditional sense

Modern AppSec platforms have become best-in-class for what they were designed to do. They help security-mature companies identify and remediate risk inside individual code-bases, container images, and cloud tenancies, and they assume a familiar operating context:

• A small number of internally owned products

• Deeply technical users

• A direct path from finding, to fixing, to deploying

For product companies, the model works exceptionally well, but for digital agencies and studios, it only partially fits.

Agencies manage project portfolios, not just individual repositories and registries

An agency’s business differs in that it operates across dozens or hundreds of client systems, where each has its own commercial contract, delivery cadence, and risk tolerance.

And for more diverse agencies, technology stacks, version control, and hosting solutions also vary markedly.

What this means is that; security data and the way it’s presented serves a broader purpose than repository or container image-specific remediation alone. It helps agencies plan client work because they’re not just beholden to the one company, but to those represented by each customer, for responsibilities including:

• Budget forecasting

• Maintenance planning

• Feature development

• Pipeline scheduling

This is why an agency-first platform does not center around individual “things” (repos, container images, etc). Rather, it positions agencies for proactive maintenance, post go-live activities and end of life software best practices, by providing an agency-wide means to aggregate end-of-life (EOL) dates, package-dependency, and security vulnerability data across entire portfolios.

Individual repositories and registries remain important, but they‘re subordinate to the questions agencies actually need answers to about their own portfolios.

Built for customer-facing roles

Agency roles at the coal-face of customer planning are not security engineers or DevOps practitioners but project managers, account managers, and executives. Each needs confidence that their insights can be reliably acted upon and confidently explained to customers.

This customer-centric context changes the environment radically. For data and findings to be useful to agencies, it should be:

• Framed around actions able to be performed by traditionally non-technical roles

• Suitable for proactive planning meetings and conversations, not just pull requests

• Presented within design, copy, and help media which explains why not just what

Cross-portfolio visibility unlocks repeatable work

Traditional tools are designed well to answer the question: “Is this repo or image vulnerable?” leaving those skilled enough to interpret the answer to provide recommendations. But agency platforms need to be able to answer higher leverage questions:

• Which customers’ apps include software due to go EOL this quarter?

• Which packages implicated in supply-chain attacks impact our portfolios?

• Are SSL certificate expiry dates likely to affect our customers in the next month?

• What upgrade work can be grouped, scheduled, and sold proactively?

By enabling cross-portfolio search and notifications across EOL software, dependencies, and security vulnerabilities, agencies move from reactive security responses to repeatable maintenance, upgrade work, and delivery.

A strategic difference

We’ve spoken a little about less-technical users. It’s true that security and engineering-laden data minimizes the range of people able to act on it, which may further engender agency information silos. But this role-orientated positioning has more to do with context than any technical capability.

Agencies see the world through a fundamentally different lens optimized for customer-first strategic work. It must balance security, delivery, and commercial realities.

This distinction is subtle, but for agencies in the context of security tooling, it’s the difference between those which merely alert and those which enable.

Get the 1-page EOL Survival Guide for agencies to level-up your agency’s approach to end of life software best practices.

Keen to know when agency orientated security tooling finally lands? Join the waitlist and be the first to know.

Join Waitlist

The Practice

Agencies work in multiples. Multiple apps across multiple customers, with retainers and projects that can easily add up to thousands of dollars a year per client when everything runs smoothly.

End of life vs end of service life matters more than people think. When a production app or website relies on components that are out of support, agencies take on extra security, compliance, and operational risk. They also miss a straightforward chance to turn maintenance into planned, billable work instead of last minute effort.

In the real world, “EOL management” usually isn’t one big migration. Sometimes it starts that way, especially with older apps that haven’t been upgraded in years. But once you get past the initial cleanup, it should look like a repeatable process you can run across your whole portfolio.

1. Discover: What’s out of support or EOL in your portfolio?

2. Assess Risk: What’s the downstream effect of an EOL or unsupported software component?

3. Plan: For each affected application, plan and estimate for the upgrade effort.

4. Communicate: Discuss impact, effort, timelines, and budgets with customers ahead of time (no-one likes scrambling for budget).

5. Implement: Follow application or platform specific upgrade guidance and documentation.

6. Monitor and Notify: Monitor key framework and O/S components for upcoming EOL dates. This is critical, very few agencies do it adequately (or at all).

When done well, agencies prevent avoidable security breaches and downtime. When done consistently, customers stick around because they see a process they can trust, not chaos and last second “we need to update stuff now” messages. When done poorly though, customers notice quickly. Churn goes up, reactive maintenance takes over, and your team burns time on manual fixes that don’t move the business forward.

There’s a clear upside here. Agencies leave thousands of dollars on the table every year when upgrade projects show-up unplanned or get priced badly because nobody tracked end of life in the first place. The downside is reflected in news such as this piece from IBM reporting that in 2024 the global average cost of a data breach hit $4.88M.

Staying ahead of EOL and end of service life protects systems, agency margins, and customer trust.

What is meant by “support” anyway?

Most websites and apps rely on a stack of third party software components, like frameworks, libraries, operating systems, databases, web servers, and programming languages. Agencies put these pre built building blocks together to create custom solutions for clients. Over time, they need updates to add features, fix bugs, and patch security issues. Eventually, maintaining multiple older versions becomes too costly or complicated, so maintainers stop supporting them.

This is where the importance of end of life vs end of support starts to matter. Agencies that stay on top of risk usually track three milestones:

End of life (EOL)

A maintainer ends standard support for a software package at a specific version or a range of versions, for example v1.2 through v1.9. After EOL, end-users generally shouldn’t expect regular updates or normal support channels to keep up any support.

End of Support (EOS)

Standard support ends, meaning end-users stop getting new features and bug fixes. Support narrows down to security related fixes only. People often treat EOS as “it’s still safe because security patches continue”, but that window doesn’t last forever.

End of Long Term Support

Paid extended support ends. Once this happens, there are no more vendor provided fixes, even if end-users and agencies are willing to pay for a premium contract.

The risk is straightforward. Once security fixes stop at the end of EOS, the software is effectively at end of life in real world terms. Known vulnerabilities stay open, and any new vulnerabilities discovered later won’t get patched. That turns the software into a permanent liability.

This isn’t a theoretical problem. Verizon, a major US communications company, reported in its 2024 Data Breach Investigation Report that security vulnerability exploitation as an initial access method nearly tripled and made up 14% of breaches.

Best Practice

What “best practice” actually covers:

1. Security: reduce agency and customer exposure to unpatched security vulnerabilities, unsupported software, and supply chain compromises.

2. Compliance: meet contract requirements for security, business continuity, and supportability. This also makes it easier to proactively recommend the right support contracts to customers before something breaks.

3. Operations: make changes more predictable, cut down on incidents, and document clear ownership so fixes don’t fall through any cracks.

4. Cost: plan upgrades instead of scrambling. Whether you use an annual EOL fund, project based remediation, or risk based allocations, you get fewer last minute upgrades and avoid expensive “special” maintenance contracts.

5. Impact: fewer outages, more reliable performance, and stronger trust between the agency and the customer.

A lot of end of life remediation starts only when something forces the issue, vendor or maintainer notificatins, penetration test findings, media publicised security vulnerabilities, or cloud and platform changes. That’s usually when people start asking about end of life vs end of service life, and realising too late that those dates can occur differently depending on the vendor and the support model in place.

With a bit of upfront discovery, agencies can predict these lifecycle dates and plan mitigation before risk and urgency spike.

Agencies can’t manage what they can’t see, so the first move is to build a complete, living inventory of what’s running and what they depend on.

1. Agency portfolio list

List every managed website and application. Capture its framework version, operating system version, hosting environment, and the end of life vs end of service life dates that apply. Include who owns it, who supports it, and what “done” looks like when an upgrade lands.

2. Libraries and frameworks

List each site’s and app’s direct and indirect dependencies, known security vulnerabilities, and their respective end of life vs end of service life dates. This is where supply chain risk hides, so don’t stop at top level packages. Array.

3. Monitored systems

Document how you monitor exposure over time, not just as a one off audit. Enumerate all vulnerability scanning and Software Composition Analysis (SCA) tools which run in code repositories, CI pipelines, and container registries. Track what gets scanned, how often, alert routing, and who’s accountable for remediation.

Risk

Before taking action, agencies first need to determine which of their customers’ managed apps and sites to prioritize, in a process of risk and criticality assessment. This will of course be unique to each agency, but it needn’t be too complicated. An in-exhaustive list of considerations is provided below which when used in conjunction with established prioritization frameworks from e.g. Mozilla and OWASP to name but two, becomes the foundation of a rigorous process:

• C&C (Certification & Compliance)

  • Prioritize apps with existing PCI-DSS, HIPAA, SOC 2, and/or ISO 27001 compliance

• Data sensitivity

  • Prioritize apps which manage PII (Personally Identifying Information)

  • Prioritize apps representing customers’ businesses (e.g. government vs small business)

  • Prioritize apps by no. affected users (e.g. all citizens vs a small industry segment)

• EOL exposure and component dependencies

  • Prioritize apps in production vs CI or internal app hosts

  • Prioritize apps with upstream/downstream components which are or are not under agency control

  • Prioritize apps with known security vulnerabilities by rating or score: e.g. Severity, EPSS, CVSS or KEV scores

• Contract basis

  • Prioritize apps (and clients) based on Non-Functional Requirements (NFRs) e.g. Return To Operation (RTO), and Recovery Point Objective (RPO)

  • Prioritize apps (and clients) based on Service Level Agreements (SLAs)

Actions

Understanding and assessing agency-specific risk can be done in isolation, but deciding on a treatment path such as: upgrade, replace, refactor, retire, isolate, or pay for extended support, requires a customer conversation based on an analysis by an expert such as a senior developer:

• Upgrade: move to a supported version (often fastest ROI)

• Replace: swap product/vendor (common for legacy tools)

• Refactor: re-architect code to remove obsolete components

• Retire: decommission unused systems (high-leverage win)

• Isolate: reduce exposure with segmentation and strict access

• Extended support: Purchase LTS or NES (Never Ending Support) licenses 1

In addition to the decision which needs to be made, there are some longer term next-steps which stand agencies in good stead.

Next Steps

Encourage Contracts

While most agencies have their own template T&M, SoW and S&M contracts, they’re not typically well-sold to customers. Customers too can always do even more up-front by specifically asking agencies for security posture evidence, migration references, and concrete SLAs, the latter being especially important for regulated environments and customers e.g. central government.

Set-up Check-ins

Agencies should have a process for booking regular check-ins for managed applications and customers. Creating an EOL maintenance calendar and road-map aligned to budgets and release cycles in an excellent way to do this. 2

Document Policies

Agencies benefit from having documented internal standards, the benefit being twofold; for the agency itself and its customers, when shared with them:

• Production systems must run vendor-supported software and/or N-1 versions

• EOL dates will be discussed 12 months prior to elapsed date

• Estimates will be provided 12 months prior, so that customers can negotiate budget with adequate notice

• Expectations of incident response time, process, recipients, and content

Getting Started

First 30 days

Start with a baseline inventory. Create one shared view of what’s running in production across applications and websites. Then define agency/team policy for “end of life vs end of service life” so everyone in the team uses the same language and the same rules.

Build your first end of life software list and decide what “unsupported” means inside your organisation. For example, does it mean no security patches, no vendor support tickets, no compatible libraries, or all of the above? Identify the top 10 high and critical applications and sites that are already end of life, or soon to be end of life. Create an exception template that requires a clear owner, a reason, compensating controls, and a time-bound expiration date.

Next 60 days

Prioritise and remediate high-risk applications and sites. Focus on what’s internet-facing and what touches sensitive data first. Knock out quick wins, then schedule upgrades that need planning.

Remediate the highest-risk items first. Where upgrades aren’t possible, apply compensating controls and document evidence. That might look like tightening WAF rules, adding CDN protections, restricting access paths, increasing monitoring, and putting extra alerting around known attack patterns. Treat exceptions like a short-term bridge, not a strategy.

By 90 days

Finalise ownership across teams so every application and site has a named accountable owner. Publish dashboards that show what’s end of life, what’s approaching end of life, what’s covered by exceptions, and what’s been remediated.

Set a monthly cadence for review and remediation so this becomes routine operational work, not a once-a-year reactive occurance.

TL;DR

So what are end of life software best practices?

They’re the repeatable program that keeps unsupported software out of production or at least tightly controlled with time-bound exceptions.

And how does end of life software best practice work?

Through continuous discovery, risk-based prioritization, clear decision making, disciplined execution, and measurable activities.

Finally, is end of life software best practice worth it?

For most organizations, yes of course! Locked-in pipelines of upgrade work are gold for agency bottom lines. But it obviously also reduces breach and outage risk, and improves audit readiness, especially on internet-facing and “crown-jewel” systems.

Forewarned is forearmed. Metaport is designed for agencies. It helps them plan EOL dates with their customers, with shared calendars, roadmap gantt charts and automated notifications months, or even years before EOL dates elapse.

Risk, in the context of application security is of course always relative: The owners of a low-traffic recipe blog have fewer regulatory or legislative guidelines to adhere to than a government department running a nationwide identity system with millions of daily users.

In the context of website, and web-application security, the focus on risk isn’t unreasonable considering the regular tide of reported data-leaks, exploits, and hacks, as well as industry research - particularly the most recent 2025 OWASP Top 10 report - all of which serve to cement-in that the threat to industry remains real.

But it pays to consider that for a number of organisations; agencies, studios, and in-house development teams, the analysis required to assess risk for themselves and on behalf of their customers, is made more difficult by the very nature of their business.

Ironically, it’s the Project Managers, Product Owners, and Account Managers working within agencies who require access to risk-orientated data for planning with their customers and stakeholders - but is instead siloed within traditional engineering and security teams.

If a way can be discovered to present data in a meaningful way for proactive planning purposes, then there are financial as well as reputational opportunities for agencies in the form of currently unrealised income and a reduction in churn.

And if all this is true, it means there exists an alternative, parallel lens through which we may view the issue of unsupported software in an agency context, other than pure risk alone.

What is end-of-life software?

An agency typically manages dozens or hundreds of customers’ software applications, where each one performs some essential function which the customer’s business relies on. They comprise individual software components which the agency has selected based on their own expertise and their knowledge of the customers’ requirements.

An agency typically selects components from numerous available container images, language run-times, application frameworks, databases, web and application servers to serve specific use-cases. Each one is an independent product developed by a maintainer; a company, team, or independent contributor who delivers new features, bug-fixes, technical support, and documentation for it.

At some point in a software product’s lifespan, it becomes necessary for maintainers to drop support for one or more versions of it. That point in time is known as the end of life date and usually applies to a subset of its version(s). For larger, or more mature products, this work is usually done according to publicly available roadmaps, but it’s important to understand that the reasons for dropped support can vary:

• Cost: Reducing the overall time spent on an otherwise expanding product line

• Sales: Vendors may elect to promote one product version over another

• Deprecation: When support for software the product itself relies on, is dropped

• Key person risk: When key staff leave an organisation and take some IP with them

• Security: Old versions contain security vulnerabilities which are impossible to fix

• Compliance: Older versions don’t comply with certain business regulations

• Engagement: Falling product usage becomes a financial liability to support

The problem with end of life software

Any company is liable to suffer any number of problems derived from end-of-life software without proper management, but ultimately they’re beholden to a regulatory landscape which is mostly within their capability to adhere to.

The same cannot be said for agencies specifically, where the cost of inaction is proportional to the cost to both the agency and the customer.

Agencies are typically experts in a small set of available technologies and draw upon these expertise in most of their customer engagements. It follows then that an end-of-life software component such as an application-framework discovered in one customer’s project, is very likely to exist in other customers’ projects too.

But how should an agency know which of its managed applications contains unsupported software? Which tools should it use to get a list of software end-of-life dates for Python, or PHP, or for Dotnet? Moreover, exactly what is the problem faced by agencies and its customers should things be left as-is anyway?

Every day literally millions of automated malicious access attempts are made against hosted web-applications. If you’ve ever even glanced at the real-time logging data produced by a web-server or any internet facing appliance, you’ve seen the scale and sophistication involved.

The longer unsupported software continues as a building block of larger applications, the higher the likelihood that such attempts are ultimately successful and which may be traced back to the faulty component.

It’s useful to understand the reasons why such malicious access attempts occur in the first place. The reasons are varied, but by way of demonstration, here’s a non-exhaustive list which provides a flavour of what’s out there.

Scenario: The Data leak

What is it? Personal information belonging to website users is accessed via stolen or phished administrator credentials, or the website’s database is found separately to the website which is itself poorly secured. You can use the popular haveibeenpwned website to check if email addresses under your control have been found in major data leaks.

What’s the motivation? Usually financial gain, sometimes informational. The stolen data can be on-sold on dark-markets to scammers and spammers.

Scenario: Defacement

What is it? Offensive or controversial content is posted or uploaded to a website which replaces or is displayed more prominently, than the original content. In 2022, several Ukrainian government websites were attacked and defaced.

What’s the motivation? Usually political or ideological.

Scenario: Ransomware

What is it? Critical data such as application configuration or authentication credentials are accessed and rendered inaccessible by encryption. A ransomware attack happened in September 2023 to MGM Casinos, resulting in critical IT infrastructure having to be shut down.

What’s the motivation? Usually financial. Data is decrypted on receipt of a ransom payment.

Scenario: Distributed Denial of Service (DDoS)

What is it? A critical piece of a company or government’s digital infrastructure such as a banking website or identity platform is flooded with requests it wasn’t designed to receive. In September 2025 the largest DDoS attack seen by the cloud defence service Cloudflare was observed and stopped.

What’s the motivation? Financial, political or ideological. The affected applications are unable to operate normally. Coupled with announcements from hacking groups, the effect is a temporary perception of control which may increase awareness of a cause.

Scenario: Malware

What is it? There are numerous kinds, but in the most recent example we’re aware of, a software maintainer’s version control system account was compromised and malicious code added to their software. This occurred in September 2025 with the Shai-Hulud attack.

What’s the motivation? Financial. Informational. In the case of Shai-Hulud, the aim was to obtain cryptocurrency through wallet monitoring and mining.

By definition, a software version which has reached its end-of-life, has no support whatsoever and the original maintainer is henceforth unwilling and unable to fix any bug or issue found subsequently.

What this means practically is that all software applications ever built on the affected software version, automatically become vulnerable to the same exploits, should they be found.

Discovery is harder than you think

If remediation is the industry word used to describe the follow-up activities involved in resolving an issue identified in software such as reducing permissions on a cloud service or fixing a user-interface problem, then discovery is always the necessary precursor step.

Agencies first need to locate those customer projects that are affected by end-of-life software. However, they also need to understand the end-of-life dates of each of their commonly used technologies, before being able to reconcile them with their customers’ projects - a two step task.

There are several vendors whose products provide per code-base or per container-image insights into end-of-life data for open source and commercially licensed software. Some also provide a search facility for security vulnerabilities and dependency packages. But when delivering hosted applications using multiple cloud providers on a range of different technologies (or multiple versions of a single technology), agencies derive most benefit from both discovery and reconciliation.

Even better would be to present end-of-life discovery in the context of an agency’s own managed application portfolio, killing two birds with one stone.

There’s an argument which contends that customers themselves should inventory their own applications using their own tools. After all, it is they who shoulder the burden of any compliance risk. However, because the technical skill required for application development has already been contracted to a third party, it’s unlikely customers have skills necessary.

There’s also an opposing argument which suggests that agencies should advocate more for the benefits to customers of regular maintenance through paid support contracts to cover end-of-life scenarios. But experience shows that many agencies have great difficulty in explaining the benefits to customers of long-term and even routine maintenance work, given what little there is to show of the work done; no shiny UIs and no new features or integrations.

Stumbling block scenarios

In order for agencies and ultimately their customers to benefit from the opportunities we believe are present in this space, some things might need to change on both sides of the agency and customer divide.

We’ve seen that the provision of development services in an agency context are mere table stakes. The time is long past where all agencies needed was to demonstrate a capability to deliver. Customers and buyers are now allocating increasingly significant resources to understanding an agency’s capability to maintain their solutions in production.

What this means is that application security, application monitoring, end-of-life notifications, security composition analysis are all on the table for discussion from a customer’s perspective.

So the solution sounds simple enough; agencies propose, draft and sell maintenance contracts, perform regular end-of-life monitoring, and communicate with their stakeholders regularly.

But there are issues to be addressed which suggests things aren’t so easy. They broadly slot into three overlapping scenarios.

1. The Stalemate: Agency Initiated

An agency has developed three web-apps for a customer and wants to offer a support and maintenance contract. The contract includes provisions for pre-paid support hours, guaranteed security patching, and proactive end-of-life monitoring.

However, the customer declines, citing a lack of any cost/benefit analysis from the agency. The customers’ apps remain unsupported beyond their operating system’s end-of-life date.

There is little incentive on the agency’s part to perform anything more than a cursory check-in periodically with the customer, should either party discover a component approaching its end-of-life date.

2. The Stalemate: Customer Initiated

An agency’s customer - a government department - has requested specific maintenance activities from the agency in light of new procurement and security legislation.

The requested activities comprise application security patching with a three day turnaround for CVEs with a CVSS score greater than 0.7 and proactive end-of-life monitoring.

The agency lacks experience in proactive monitoring and patching of this kind. It does however review the available tooling and finds they require either a paid subscription, or manual configuration effort which amounts to more of either than the agency is willing to deploy on a single customer.

The agency concedes it’s in the best interests of both organisations that the customer approaches a larger, more security-mature agency and declines the request accordingly.

In the interim, the application itself remains essentially unsupported to the extent the customer has been mandated to procure.

3. The Poor Delivery

Agency and customer have both agreed a support and maintenance contract which does contain a provision for end-of-life date monitoring.

Over time, the quality of the agency’s contract performance is reduced due to unforeseen circumstances including staff and customer churn. In addition, come renewal time, the customers’ requirements have become more onerous than the agency is willing to support, which leaves the agency close to being in breach of contract, or losing yet another customer.

The net result is that the paid support service as it stands isn’t fit for purpose. And the application in question lies unsupported beyond the end-of-life date of one or more of its components.

Agency opportunity

These legitimate scenarios demonstrate that for entirely understandable reasons, both agency and customer can find themselves in the unenviable position of being in possession of a number of software applications that neither of them is able to satisfactorily support.

But if the agencies of those scenarios could have been better prepared in terms of an investment in tooling and process, then at least two scenarios are effectively rendered moot.

Things begin to look rosier too with the benefits to be had from predictable revenue through pre-paid hours, pipelines of locked-in upgrade work and a reduction in potential customer churn.

Future customers benefit too, assuming these new or improved maintenance capabilities are marketed well.

For agencies looking to maximise profit, and minimise losses derived from poorly managed (or completely unknown) end-of-life software components, there is more than one way to skin the proverbial cat, but first we should discuss software versioning.

A note on versioning

There are several “schemes” used to communicate a software version, the most popular of which for open source software products is Semantic Versioning known as “Semver” for short.

Semantic Versioning is an informal versioning scheme. As such, adherence to it (or any) scheme is entirely voluntary. However, the benefit to software maintainers is understood when inferring meaning from a version change.

Consider the following, typical software version which follows Semantic Versioning:

Major version: Breaking, backwards incompatible or significant functionality changes (e.g., 4.2.1 to 5.0.1)

Minor version: New features, backwards-compatible API additions, or enhancements (e.g., 4.2.1 to 4.3.1)

Patch version: Bug fixes, security fixes, or minor backwards-compatible changes only (e.g., 4.2.1 to 4.2.2)

The most expensive, time consuming, and potentially problematic upgrade for agencies and customers is usually considered to be a major version upgrade.

The following example illustrates the point: A maintainer drops support for version 4.x (where ”x” is any number), but still supports versions in the 5.x “range”. Should security vulnerabilities subsequently be found in 4.4.3 for example, they will not be fixed, leaving agencies needing to react quickly with a solution.

Because maintainers are unconstrained by any assumptions around their software’s use when incrementing a major version digit, they’re free to introduce so-called “breaking changes”. Applications using this software which have come to rely on features now earmarked for change or removal, now have the potential for significant rework to become compatible with the upgraded software’s new way of doing things - also known as its Application Programming Interface (API).

Agency and customer next steps

Upgrade Project

What it is: When a software component of a larger, “consuming” application needs to be upgraded to its next major version, the incumbent agency will usually review the complexity of the application and estimate the effort required to modify it to suit the new version’s API, as well as perform the upgrade itself.

Pros and cons: Locking-in a pipeline of upgrades is a great way for agencies to bring in additional income. Done proactively enough, it also assures customers that the agency is skilled enough for what can be a challenging task. Occasionally maintainers do disappear, become insolvent, or are bought out by other companies. Each of these scenarios has a bearing on the main application, its operation and expected lifespan which is worth taking into consideration.

Providers: Most agencies should welcome the opportunity to estimate the effort required to upgrade to the next major version of a key software component.

Never Ending Support (NES)

What it is: A never ending support contract (NES) undertaken between a customer or an agency, and a third-party company. The third-party is unaffiliated with the original maintainer of now end-of-life - usually open source - software, and commits to providing ongoing support and maintenance services for it.

Pros and cons: There’s no guarantee that the contracted support duration matches the intended lifetime of the affected application, but that’s really little different to the situation from official maintainers. There may also be significant costs associated with access to NES software. Research and cost comparisons are necessary with those quoted by any agency for major version upgrades.

Providers: Shop around as there are several companies offering NES services.

Long Term Support (LTS) or Extended Security Maintenance (ESM)

What it is: A long term support contract (LTS) undertaken between a customer or an agency, and the original maintainer of now end-of-life - usually open source - software. While the original maintainer has now ceased free support of one or more versions of their software, they do commit to priority bug-fixes and/or security fixes for a fixed subset of versions under a paid support contract.

Pros and cons: LTS contracts have a defined, limited duration. Depending on the affected application’s intended lifespan, customers may find that a major upgrade to a supported, open source version of the otherwise affected software is needed in time anyway. Research and cost comparisons are necessary with those quoted by an agency for major version upgrades.

Providers: Not all maintainers are guaranteed to offer an LTS or ESM license service. But for larger software components with commercial arms such as some popular Linux operating systems, many maintainers do offer LTS/ESM licensing options.

Decommission

What it is: The process by which an application is retired and its underlying infrastructure is decommissioned. When customers and stakeholders decide that the cost of application security, maintenance and feature development outweighs the business benefits of the app itself, one option available is to retire the application completely.

Pros and cons: If an application is no longer profitable, or has served its purpose, then depending on its size and complexity, significant amounts of money can be saved in maintenance, license, and cloud costs. On the flip side, careful consideration should be applied with consensus reached by customers and product owners, that a “decom” as it’s known, is the only viable option.

Providers: There is of course a cost to the time required for due diligence to occur with respect to assessing infrastructure, API endpoints and touch-points. However, as with major upgrades, most agencies as the incumbent should welcome the opportunity to estimate for the effort required.

There is of course nuance to everything, so there may be some overlaps, but the above represent the main approaches for what to do with applications containing end-of-life software, or software which is close to end-of-life.

Conclusion

If you didn’t feel qualified to comment on your own organisation’s policies towards end of life software prior to reading this article, you should certainly feel so now!

We’ve covered common definitions, scenarios, rationales, solutions and strategies for the existence, analysis, and mitigation of unsupported software from the perspective of agencies and their customers.

If you represent an agency, you know there’s of course always more you can do for your customers. But when was the last time you took time out to review your approach to maintenance and support contracts?

If you represent the customer in these scenarios - an organisation which outsources its software and web development to an agency - when was the last time you revisited the support contracts you have with them? Are they still fit for purpose with what you now understand of end-of-life software?

As we’ve mentioned, we’ve found several tools which will manage various aspects of an application’s security posture, but very few comprise an EOL software notification feature, and practically none presents it for use by an entire delivery team alongside traditional AppSec data points.

If you haven’t yet reviewed what Metaport can do for your team, we’re currently taking bookings for conversations with interested agencies and studios.

And don't forget about your awesome team off whom you bounce ideas, and spend late nights with, as you're on a roll getting shit done.

Startups are glam AF right?

If this is your understanding of a startup, then you're so off target that you can't even see it, or indeed what it would look like if you could.

What I've described is the Silicon Valley startup, popularised during and after the dot-com bubble and bust of the late 1990s and early 2000s. Young entrepreneurs made their way to Palo Alto, California with their half-baked ideas written on the back of a napkin * which outlined how their online grocery or pet store business would make millions on this burgeoning new platform called the World Wide Web. They would wave hands vigorously until the millions in VC funds they demanded landed right in their laps.

This was repeated to a lesser extent during the Blockchain not Bitcoin and ICO movement of 2016/2017, and it's being repeated again with AI, LLMs and MCPs as I write.

But it's not the world I inhabit, and I've never been quiet on my disdain for the "engineered scaling" approach to product and company building, conceived by accelerator programs first in the US with YC and others, and then globally.

No, I'm a bootstrapper. Bootstrapper's have the same aims for the ultimate success of their company and their product, but our goals are far less lofty than those who want to exit their company to the highest bidder. We operate from the same fundamental rules that came out of the Dot Com and ICO eras, and we gladly take the learnings from the hundreds of books, blogs and videos which came after, but we also differ in a couple of fundamental ways:

We don't seek VC funding

Every founder needs money to live on. Some of us run our companies as a side-hustle, some quit their jobs to focus on them, but founders still need to eat as well as to invest in the tools, subscriptions, and materials any tech company relies on in the internet age.

There are many ways to sustain one's self, and ones company, but only one of them means a deference to a company whose business model is to invest in such companies. And never mind the less-considered detriment to such a company's control, should founders choose this route.

In a way, those of us who do not seek such funding are the lucky ones. Either we already have savings enough to develop and scale in a cadence we're comfortable with given our current life situation (what's referred to as "runway") or we've asked for minimal investment, not from 3rd party commercial interests, but from friends and family (also known as "seed" funding - VC funds can also be a source of seed funding).

We don't need a team (until we do)

There's a rule of thumb I came across recently which flies in the face of the illusory startup heaven. It's very basic, and mandates that a company should not hire anyone until it becomes physically and mentally impossible for the incumbent(s) to continue with the business, without that additional hire.

Sounds logical doesn't it? But it wasn't to me until I'd heard it on a podcast. Until then, I had naively thought that founders surely needed support from co-founders and rock star employees as early as humanly possible. Well yes, they absolutely do, but we're bootstrapped, not VC funded. So we're going to have to suck it up and put in the hard yards until circumstances mandate that we're comfortably able to afford to hire into the company.

You can decide for yourself whether you think essentially working alone is a good or a bad thing, and it mostly hinges on personal circumstance.

We don't need that much money

I arbitrarily granted my company Dcentrica, a low 6 figure dollar amount which gave me a 12 month runway. So have I used those funds strategically to sign-up to SaaS services and to procure professional help when required? You bet your arse I have, and there's still something left in the kitty. But knowing there's an end to that funding, and not knowing how the whole project is going to end up in 6 months, next month, tomorrow? Now that can only be described as utter torture. For someone like me, who isn't made of the toughest stuff (I'll stand my ground when needed though, thank you) I ask myself the difficult questions, sometimes daily and while I continue to describe my own mental life to anyone who's interested as being "rich", lately I'd probably want to add "all over the show".

So why the hell do I continue, when my personality type seems hell bent on rug-pulling my ego any opportunity it gets?

Vision, determination (and circumstance)

I've always wanted to do this. I had the opportunity and funds to do it. I wasn't sans idea, given that first-hand experience has shown over and over that a particular problem I'd seen, existed everywhere I worked. Couple these with my having built 90% of a solution for it already ** (though it blows my mind that folks start on this path without any idea at all), then if any situation could be described as being a "hint" to YOLO into anything, then this was surely it.

I've seen first hand the plainly ridiculous situations which arise in an agency context when client facing teams don't have the information they need. But help a Project Manager, Delivery Lead or Account Manager understand that certain classes of information are indeed available to them, and further, that they promise to make their job infinitely easier, and engenders positive downstream effects for their clients, and their team's bottom line: Then the ability to proactively plan and effectively execute with them, should be very appealing indeed.

Dev and product teams have got the production of complex and secure software solutions down pat, but in my experience, they absolutely suck at keeping things that way post launch.

That's exactly what Metaport is designed to do.

I'm offering in-person demos for companies based in Wellington, NZ, and remote demos for everyone else, email us to kick things off. You can of course also have a play with the Metaport Demo yourself, just please tell us what you think

* My late father did this in 1998, his postcard features in the heading.

** Tradition has it, that you validate first, not build first. Cart/Horse, Chicken/Egg.

Start a Substack

Having built something which we reckon is ludicrously useful is one thing, but convincing our ICP about this really is quite another.

When launching and then running a SaaS (or any product for that matter), there’s only usually only one major hurdle to overcome and that is convincing people to use it.

Since introducing Metaport to the world in early 2025 however, it’s become quite apparent that we have in fact two such major hurdles, the other, primary one being:

Convincing people they actually have the problem, which the product solves for.

Amazingly, and quite unlike many founders we’ve encountered, we’ve actually worked in the same industry whose practitioners need the product. We’ve observed first-hand the problems Metaport solves, which is basically why we built it. No-engineer wants to be asked the same - seemingly menial - questions about a project they probably haven’t touched for months.

But, here’s the kicker: Metaport cuts across the traditional engineering/ops and project management/customer experience boundaries. So how how on earth do you position a product which isn’t AppSec but deals with security-related data (and stakeholder outcomes), isn’t an Observability tool, but observes an application stack from afar, and isn’t an Issue Tracker or Task Management tool, despite its bent towards project management?

Well what you don’t do is try and use words alone. We originally wrote about this in a LinkedIn piece last week, but as we summarised there too - a picture speaks a thousand words.

If you work in, or run a web-development agency, or an in-house development team, find out if Metaport is right for you at getmetaport.com.