End of Life Software Best Practices for Agencies (and Customers)
The Practice
Agencies deal in multiples: Multiple apps for multiple customers, paid potentially in multiples of a thousand dollars annually - when they’ve got their ducks in a row.
When production applications and websites comprise end of life components, agency best practice reduces security, compliance, and operational risk, as well as locking-in new revenue.
But in practice, “EOL management” is less about one big migration - though legacy applications without a robust upgrade history will necessarily start this way - it’s more about a repeatable checklist:
Discover: What’s out of support or EOL in your portfolio?
Assess Risk: What’s the downstream effect of an EOL or unsupported software component?
Plan: For each affected application, plan and estimate for the upgrade effort.
Communicate: Discuss impact, effort, timelines, and budgets with customers ahead of time (no-one likes scrambling for budget).
Implement: Follow application or platform specific upgrade guidance and documentation.
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).
Done well, best practices prevent avoidable security breaches and downtime.
Done consistently, agencies reduce churn because customers believe in a process which agencies can be relied upon to adhere to.
Done poorly however and customers notice: agencies see an increase in customer churn, reactive maintenance activities and manual effort.
The carrot here is that there are thousands of dollars left on the table each year in un-planned, or improperly planned upgrade projects. The stick however is illustrated in any number of statistics, e.g. when in 2024, IBM reported the global average cost of a data breach reached $4.88M.
What is meant by “support” anyway?
Most websites and applications are built from individual software packages and components; frameworks, libraries, operating systems, databases, webservers and programming languages: Pre-built collections of code which agencies assemble to provide bespoke solutions to their customers. But at some point, changes are required which introduce new features or fix security bugs. At this point software components become too onerous to maintain multiple versions of, so maintenance for older versions is discontinued.
Agencies that are doing well, commonly track three related milestones:
End-of-life (EOL) Typically means that a maintainer has ended standard support for a package either at a specific version, or a range of versions (e.g. v1.2 to v1.9).
End of Support (EOS) Standard support ends (new features and bug-fixes are no longer introduced and support is reduced to just security related fixes).
End of Long Term Support Paid extended support ends (no more vendor-provided fixes, even with a premium contract).
The key risk is pretty simple at this point: Once security fixes stop at the end of EOS (End of support), then the software is de-facto EOL. This means known and any new security vulnerabilities become permanent.
Verizon is a major US communications company, and in its 2024 Data Breach Investigation Report, it highlighted that security vulnerability exploitation as an initial access method nearly tripled and accounted for 14% of breaches.
Best Practice
What “best practice” actually covers:
Security reducing agency and customer exposure to un-patched security vulnerabilities and supply-chain compromises
Compliance agencies meeting contract requirements with respect to security, business continuity, and supportability (and proactively recommending support contracts to customers)
Operations predictable changes, fewer incidents, and documented ownership
Cost using an annual EOL fund, project-based remediation, or risk-based allocations all lead to better planning which avoids last-minute upgrades and expensive “special” maintenance contracts
Impact fewer outages, more reliable performance, and increased trust between agency and customer
Most EOL upgrade project planning begins when something forces the issue: vendor or maintainer notices, penetration-test findings, media publicized security vulnerabilities, or cloud/platform changes.
But with a little bit of up-front discovery effort, it’s relatively easy for agencies to predict and therefore plan for EOL date mitigation entirely.
Agencies can’t (and typically don’t) manage what they can’t see. Agencies should therefore make a start by building a list of software, components, and activities which spans the following: 1
Agency Portfolio List all managed websites and applications, their framework and O/S versions as well as EOL dates 2.
Libraries and frameworks List each sites’ and apps’ direct, and indirect dependencies, security vulnerabilities, and their respective EOL dates.
Monitored Systems Enumerate all security vulnerability exposure analysis and Software Composition Analysis (SCA) occurring in code repositories and container image scans.
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 3
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. 4
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
A baseline inventory, define policy, identify top 10 high and critical EOL apps and sites
Build your first end of life software list, define what “unsupported” means internally, and identify the top 10 applications and sites comprising EOL, or soon to be EOL software. Establish an exception template and require time-bound expiration.
Next 60 days
Prioritize and remediate high-risk applications and sites, implement compensating controls
Remediate the highest-risk items first. Where upgrades aren’t possible, review the seven “Action” bullets or apply compensating controls (E.g. additional WAF and CDN controls to mitigate common attack vectors) and document evidence).
By 90 days
Finalize ownership, publish dashboards, and set a monthly remediation cadence. At this point, end-of-life software best practices become a routine operational process and never a once-a-year emergency.
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.
Agencies which choose Metaport, already have excellent EOL visibility. However, EOL dates are also available via vendors’ websites and by using tools like endoflife.date (albeit manually).
Common advice suggests “having an inventory” as being the first step. However from an agency perspective, it’s easier said than done given the range of tech stacks, cloud hosting, and version control systems in place. No solution yet exists which maintains a living list of managed applications. Agencies can spend developer time manually maintaining spreadsheets and wikis, or they can use systems like Metaport which act as the canonical source of application data.
Companies like HeroDevs can take over as de-facto maintainer of entire EOL software projects, via a paid NES (Never Ending Support) license.