Vendors announce retirement dates in jargon that hides a simple fact: after a certain day, security fixes stop and the risk is yours. Here is how to decode the terms — and what they mean for insurance, compliance, and budget.
When an end-of-support notice lands, the honest first question in the room is usually this: "The software still works after that date, doesn't it?" And the answer is yes — it keeps running. Nothing breaks on day one. No alarm sounds, no screen goes dark, no invoice arrives.
That is exactly what makes the date easy to ignore, and exactly why it is dangerous. Until that day, when a security flaw is found, the vendor's engineers fix it — quietly, routinely, hundreds of times a year. After that day, the same flaws are found at the same rate. Nobody fixes them.
Nothing breaks on the day support ends. The risk simply transfers — quietly — from the vendor's engineers to your balance sheet. It's like driving past the end of a warranty: the car runs fine, until the day it doesn't.
The confusion is compounded by vocabulary. Vendors describe the same handful of milestones with a rotating cast of acronyms — EOL, EOS, EOSL, ESU — and they do not use them consistently with each other. The table below is the decoder we use with clients.
Seven terms cover nearly every retirement notice you will receive. One of them matters far more than the rest.
Four consequences land outside the IT budget line — which is why the date belongs on a risk register, not just a patch schedule.
Breach activity concentrates on unpatched systems — end-of-support dates are published, so unsupported software is a standing invitation with a known address.
Renewal questionnaires ask directly about unsupported software. Answer wrong and premiums rise; misrepresent it and a claim can be denied when you need it most.
PCI-DSS, HIPAA, CMMC and ISO 27001 all treat unsupported software as a control failure — one that surfaces in the audit whether or not anything has gone wrong yet.
A migration started on time is budgeted, phased, and negotiated. One started after the deadline happens at the vendor's price, on the vendor's schedule.
The Platform EOL Radar maps end-of-support dates for common business platforms against a realistic replacement schedule — no signup, saved in your browser.
Replacing a business platform is not a weekend project. Selection, contracting, and implementation for a midmarket organization typically take six months to two years, depending on the category. That is why a "start-by" date exists: count backwards from end of support, and the last responsible day to begin is earlier than most calendars assume.
Typical midmarket planning ranges, not guarantees — bars show the upper end of each range. Planning methodology: Global Digital.
The math has a second, quieter term: leverage. Start inside the window and you run a competitive selection — the incumbent has to bid against alternatives. Wait past it, and every vendor at the table can see you have no time to switch. Waiting doesn't just compress the schedule; it hands the negotiation to the other side.
You don't need a project or a budget line to act on this article — you need three answers. Ask your IT leader this quarter:
Which of our platforms passes end of support in the next 24 months — and who owns each date?
Where are we already past a support date, and what compensating controls are in place today?
Which budget cycle is the natural moment to start selection — and does that still fit the runway?
We're fiercely vendor-neutral. This guide pushes no product and endorses no migration path — it exists so the timing decision is made by you, not made for you.
The Platform EOL Radar maps end-of-support dates against a realistic start-by schedule for the platforms behind most midmarket businesses — free, no signup.
No SDR layer. We sell expertise, not products.