How to read a sunset date
An end-of-life announcement usually contains three dates and people plan against the wrong one.
- End of sale — you can't buy new licences or add capacity. Often the first constraint to bite, particularly if you're growing.
- End of mainstream support — no new features, and increasingly reluctant support for anything unusual. In practice, the point where you're on your own for real problems.
- End of life — no security patches. This is the date that matters for insurance, audit and compliance, and the one most often used for planning when it shouldn't be.
Plan against end of mainstream support, not end of life. By the time patches stop, you've already spent a year unsupported in every way that matters operationally.
What we're watching
This list covers platforms we see regularly in manufacturing, distribution, logistics, construction and trades. It is not exhaustive and vendor plans change — always confirm directly before acting.
Platform area
Status
What it means in practice
Legacy on-premise ERP
Ongoing migration pressure
Most major vendors are steering customers to cloud editions. On-premise editions remain supported but receive progressively less investment.
Older desktop accounting
Recurring annual sunsets
Desktop accounting products commonly retire older versions on a rolling schedule, frequently removing payroll and e-services first.
Legacy e-commerce platforms
Several past EOL
Running an unsupported commerce platform is a PCI and insurance exposure, not just a feature one.
Older server operating systems
Staggered
Usually the constraint that forces an application migration rather than the application itself.
Discontinued vertical products
Case by case
Industry-specific systems whose vendor was acquired or dissolved. The most common category in our own work and the least publicised.
Specific dates are deliberately not listed here because they change and a stale date is worse than none. If you tell us what you run, we'll confirm the current position for your versions.
How much time you actually have
Take the end of mainstream support date and work backwards. For a business of 30 to 200 people, a realistic sequence is:
- Assessment and options: 3 to 6 weeks
- Decision and budget approval: 4 to 12 weeks, and frequently the longest stage
- Selection, if replacing: 6 to 16 weeks
- Implementation and parallel running: 3 to 12 months depending on scope
- Stabilisation before you'd want to be unsupported: 2 to 3 months
That's twelve to twenty-four months from a standing start. Which means an announcement eighteen months out is not comfortable — it's roughly on time.
What to do when yours is listed
- Establish your actual version and edition before anything else. People are frequently wrong about this, and it changes the date.
- Ask whether staying is genuinely an option. Sometimes it is, with compensating controls, and it buys a year. Your insurer and auditor get a say.
- Separate the upgrade from the replacement question. Upgrading within the same vendor is usually far cheaper and is often dismissed too quickly because a sales conversation started instead.
- Get the customisation picture documented first. Most upgrade anxiety is documentation anxiety, and the assessment resolves it for a fraction of a migration.
- Don't let the date choose the successor. Deadline pressure is how businesses end up on platforms they'd never have selected calmly.
