What is the difference between end of support and end of life?

There is no universal definition. End of support typically means the vendor stops delivering patches, fixes, and technical assistance but the software keeps running. End of life usually means the vendor considers the version fully retired from its maintenance lifecycle. Some vendors (like Kentico) use 'end of support' and others (like Umbraco) use 'end of life' to describe nearly identical outcomes. Always read the vendor's lifecycle page to see what specifically stops on the date.

Does software stop working after end of support?

No. Self-hosted software continues to run after end of support. What stops is security patches, bug fixes, and vendor technical assistance. SaaS service retirements are different — the vendor turns the service off and data may be permanently deleted. The distinction between end of support and service retirement is the most important one to get right.

What is the difference between end of sale and end of life?

End of sale means the vendor stops selling the product to new customers, but existing customers keep their licenses, support, and patches. End of life means the vendor stops maintaining the product entirely — no patches, no support. End of sale is an early signal; end of life is the operational deadline. Salesforce CPQ is a current example: it reached end of sale in March 2025 but has no announced end-of-life date.

What is extended support and is it worth paying for?

Extended support is a phase in which a vendor provides a reduced set of services (usually security-only patches) after mainstream support ends. Microsoft's ESU, Sitecore's paid Extended Support, and Umbraco's XLTS are all variants. It is worth paying for as a temporary bridge if you cannot complete your migration by the end-of-support date, but it should not be treated as a long-term strategy because it does not keep the platform compatible with evolving runtimes, browsers, or third-party APIs.

What happens to my data when a SaaS product is retired?

When a SaaS service is retired (hard shutdown), the vendor turns the service off and data may be permanently deleted with no recovery path. Microsoft Project Online retires September 30, 2026 with no read-only grace period. Meta Workplace shut down with a fixed data-export deadline after which exports were no longer possible. Always export data well before a retirement date.

End of Support vs End of Life: What the Terms Actually Mean

End of support and end of life are not synonyms, but no industry standard defines either term — each vendor decides what stops, what continues, and what it costs. OpenEoX, an industry standardization effort led by OASIS Open, explicitly acknowledges that lifecycle models vary by vendor and product type, and has attempted to create a common schema precisely because no common schema exists. (docs.oasis-open.org)

Misreading the label on a vendor announcement can leave a team either panicking over a date that changes nothing operational, or ignoring a date that deletes their data. This reference defines every term you will encounter — including several the glossary section below does not skip — shows how real vendors use them differently in 2026, and explains what actually breaks when the deadline passes. For a date-by-date view of upcoming deadlines, see our complete 2026 EOL calendar.

Why There Is No Universal Definition

There is no industry standard, so end of support (EOS) and end of life (EOL) mean whatever each vendor says they mean. Much of the time they are synonyms attached to the same date — the day the vendor stops maintaining a product. Microsoft uses both terms but attaches specific phases (Mainstream Support, Extended Support, ESU). Cisco publishes a multi-milestone "EOL bulletin" per product. Umbraco calls its date "end of life." Kentico calls the same kind of date "end of support." Optimizely publishes no fixed date at all.

The word on the announcement is not what matters. What matters is what stops happening — patches, support tickets, security fixes, access to the running service — and on which date.

Info

Rule of thumb: if the vendor says end of support, plan around rising security and compatibility risk. If the vendor says retirement, end of service, or hosting discontinued, plan around lost access and data export deadlines.

The Glossary: Eleven Lifecycle Terms, Defined

Below are the lifecycle terms you will encounter across vendor announcements, listed in the order they typically occur in a product's lifecycle. Each definition is self-contained so it can be read — or quoted — without context.

Technical Preview / Release Candidate

A technical preview (sometimes called a release candidate or beta) is a pre-general-availability release made available for testing. Vendors explicitly disclaim production use and offer no support SLAs. This matters for lifecycle planning because some teams adopt preview software in production to gain early access to features — and discover later that the preview never received a supported upgrade path to GA.

General Availability (GA)

General availability is the date a product version enters full commercial release, is officially supported, and the vendor's documented support lifecycle clock begins. Every downstream lifecycle date — mainstream support end, extended support end, EOL — is calculated from GA. Microsoft, Red Hat, and most enterprise vendors publish their lifecycle end dates at GA or shortly after.

Mainstream Support

Mainstream support is the primary support phase during which a vendor provides the full range of services: feature updates, bug fixes, security patches, and technical assistance. For Microsoft products, mainstream support is typically five years from GA. For Red Hat Enterprise Linux, it is five years from major release. During mainstream support, customers can request new features and non-security bug fixes through normal support channels.

Long-Term Support (LTS)

Long-term support is a release designation indicating a vendor commits to an extended maintenance window — typically longer than the standard release cadence. LTS designations are common in open-source ecosystems (Node.js, Ubuntu, .NET) and signal that a version is stable enough for production use across a multi-year window. Umbraco's LTS releases are supported for 3 years: a 24-month Support Phase followed by a 12-month Security Phase. Non-LTS releases receive shorter windows. Choosing a non-LTS version when an LTS version is available shortens your migration runway significantly.

End of Sale (EoS)

End of sale is the date after which a vendor no longer sells new licenses or subscriptions for a product. Existing customers keep their licenses, can typically renew, and continue receiving support under their current agreements.

Salesforce CPQ reached end of sale in March 2025. Existing customers can renew, add users, and receive support, and no end-of-life date has been announced. End of sale is the earliest lifecycle signal and the least operationally urgent — but it reliably foreshadows the dates that follow. It is a procurement event, not an engineering emergency.

End of Support (EOS)

End of support is the date after which a vendor stops delivering patches, bug fixes, and technical assistance for a product version. The software itself keeps running. EOS generally means that a defined support period or support tier has ended. Depending on the lifecycle policy, you may lose access to standard vendor assistance, the ability to open new support cases, troubleshooting help, or other services bundled into that tier.

Kentico Xperience 13 is a textbook example. From January 1, 2026 to December 31, 2026, Kentico continues to provide technical support but issues only security hotfixes. From January 1, 2027, all support, maintenance, updates, hotfixes, security patches, and related services cease entirely. Kentico is explicit that any use of Xperience 13 after December 31, 2026 is "at your sole risk." But the software does not stop running. Kentico Xperience 13 is reaching end of support, not being switched off.

If you run an on-premise or self-hosted application that reaches EOS, existing projects continue to function as unsupported software. What stops is the vendor's liability. If a zero-day vulnerability is discovered the day after the EOS date, the vendor will not issue a CVE patch. Your internal engineering team assumes full responsibility for securing the application — usually by placing it behind strict web application firewalls (WAFs) or isolating it on the network.

Security-Hotfix-Only Phase

A security-hotfix-only phase is a support tier in which the vendor still issues patches, but only for security vulnerabilities — no bug fixes, no feature work, no compatibility updates. It is the narrowest form of active maintenance a vendor provides before fully ending support.

Kentico Xperience 13's entire 2026 calendar year is a security-hotfix-only phase. Umbraco 13 entered a similar "Security Phase" as the final 12 months of its LTS lifecycle — supported for 3 years total: 24 months Support Phase plus 12 months Security Phase.

This phase is easy to miss in vendor communications because the product is technically still "supported." But if you file a bug report that is not a security vulnerability, the answer is already "no." Teams that budget for feature work or non-security bug fixes during this phase are budgeting against a policy that will not honor the request.

End of Life (EOL)

End of life marks the point where a vendor considers a product version fully retired from its maintenance lifecycle. No patches of any kind — not even paid ones — are issued through the standard program. EOL generally marks the end of standard maintenance for a product or version. After this date, the vendor or upstream project typically stops providing routine security patches, bug fixes, and other updates for that release.

Umbraco uses this term precisely. On December 14, 2026, Umbraco version 13 reaches end of life, after which security patches and updates will no longer be provided. Projects will technically continue to function after end of life, but Umbraco strongly advises against using Umbraco 13 after December 14, 2026.

The difference from Kentico's "end of support" label? Functionally, very little — both mean no more patches, your risk. The label differs; the operational consequence is nearly identical. That is why reading the vendor's lifecycle page — not just the announcement headline — is critical.

Extended or Paid Support

Extended support is a phase — sometimes included in the original license, sometimes sold separately — in which a vendor continues to provide a reduced set of services (typically security-only patches) after mainstream support ends. It exists to give enterprise customers a longer runway to complete complex migrations.

Sitecore restructured this phase in 2026. Sitecore is making changes to its support model as of June 1, 2026. The most noteworthy change is that production incident support and security updates became paid for all versions in Extended Support. Until that date, both were included as part of the standard agreement. So Sitecore did not end support for its older versions — it moved security patches behind a paywall. Since June 1, 2026, Sitecore Extended Support no longer includes security updates or production incident support unless you buy a separate paid arrangement. XP 10.0 and 10.1 reach the end of Extended Support on December 31, 2026, after which security patches are unavailable at any price.

Umbraco takes a different approach with its Extended Long-Term Support (XLTS) product. With XLTS, you can get up to an extra 6, 12, or 24 months of coverage beyond the EOL date. XLTS should be treated as a temporary risk-management measure, not an alternative to upgrading. For Umbraco 13 on Cloud, the documented lifecycle extends further: EOL on December 14, 2026, XLTS through December 14, 2028, and End-of-Service on December 14, 2029 — after which hosting is discontinued and projects that have not been upgraded or migrated stop working.

Microsoft's Extended Security Updates (ESU) program follows yet another model. The ESU program is a last resort paid option for customers who need to run certain legacy Microsoft products past the end of support. It is not intended as a long-term solution, but rather as a temporary bridge to stay secure while migrating to a newer, supported platform. ESU only provides security patches. For Windows 10, it is a paid service that extends "critical" and "important" security updates for a maximum of three years — Year 1 costs $61 per device, Year 2 costs $122, and Year 3 costs $244 (Microsoft's 2024 published pricing). ESU does not provide complete patching: vulnerabilities rated "moderate" or "low" will not be addressed.

Extended support is runway, not a destination. The vendor is charging a premium to maintain legacy codebases for a shrinking pool of holdouts. If you buy it, what you are buying is time to sequence a migration — not a promise that the old platform will keep pace with new runtimes, browsers, or integration behavior.

Retirement (Hard Shutdown)

Service retirement means the vendor turns the service off. The software stops being reachable, and any data not exported before the date is gone. This is the only lifecycle event where the software actually stops working on a specific day. It applies exclusively to SaaS, PaaS, and managed cloud products. There is no grace period after a retirement date — the vendor deprovisions the servers, shuts down the API gateways, and purges the databases.

Microsoft Project Online retires on September 30, 2026. On the hard shutdown date, PWA interfaces are disabled, the OData endpoint returns 410 Gone, and the Desktop Client online sync stops working. Official guidance states data becomes permanently inaccessible on the retirement date. There is no grace period, no read-only access, no archive mode. When September 30, 2026 arrives, everything stops working.

Meta Workplace reached retirement in 2026. Meta announced the shutdown in May 2024 and discontinued data export on May 31, 2026. After that date, data was simply gone — no appeal process, no recovery mechanism.

The difference from end of support is binary: after end of support, your software still runs and your data is still where you left it. After a retirement, neither is true.

Warning

If the notice says users will lose access, hosting will be discontinued, or data is only available for a short period after the date, treat it as an export deadline. Do not treat it like a patch-management problem.

No Published End-of-Life Date (Rolling Policy)

Some vendors skip fixed dates entirely and instead maintain only a set number of recent versions. Optimizely is a clear example. Optimizely says it "actively monitors, triages, and fixes severe bugs and security issues for the current major version and one prior major version." On April 10, 2026, Optimizely formally announced that CMS 11 was out of support — CMS 13 had reached GA on March 31, and by policy only the two most recent major versions stay supported.

Optimizely CMS 11 has no published end-of-life date and no committed fixes beyond severe security vulnerabilities. There is no enforced sunset date — Optimizely is not going to switch your installation off. The version simply falls out of the maintenance window when a new major ships.

If you are evaluating a vendor with a rolling policy, you need to watch release announcements, not a fixed calendar. There is no multi-year warning; the lifecycle is tied directly to the release cadence of new major versions. A new major release can arrive without a fixed schedule and immediately push your current version out of the support window.

Lifecycle Decision Framework: What Your Response Should Be

The label on a vendor announcement determines your response timeline and your options. Use this framework when you first read a lifecycle notice:

If the vendor announced retirement (hard shutdown):

Identify the exact shutdown date and the data export cutoff (these are sometimes different dates — Meta's export cutoff was May 31, the service ended later).
Export all data immediately. Treat the export deadline as the hard deadline, not the shutdown date.
Figure out the destination second. A migration without a destination is better than data that no longer exists.

If the vendor announced end of support or end of life for self-hosted software:

Confirm whether a paid extended support option exists and what it actually covers (security patches only? All severities? Until when?).
Identify the underlying runtime's support end date. If .NET 8 or PHP 8.1 or Java 11 ends support before or shortly after the application does, you are stacking unsupported layers.
Run a dependency audit: which third-party integrations have the application on their supported-version list? When do those certifications expire?
Assess compliance exposure: does your SOC 2, ISO 27001, or PCI-DSS scope require all software to be actively vendor-supported?
Set a migration start date well before the EOS date — we recommend scoping at least 3–4 months out — because the platform rebuild is a longer project than the data migration.

If the vendor announced security-hotfix-only phase:

Stop planning feature work or bug-fix requests against this version.
Accelerate migration planning — the full EOS date is typically 12 months away.
Continue monitoring for CVEs against this product version. Patches will come, but only for security vulnerabilities.

If the vendor announced end of sale:

No immediate action required.
Flag the product in your technology roadmap as deprecated.
Watch the vendor's lifecycle page for subsequent EOS/EOL dates.

If the vendor uses a rolling policy (no fixed dates):

Subscribe to the vendor's release announcements. Any new major version announcement is your lifecycle event.
Determine how many major versions back you currently are. If you are on the current version minus two or more, you are already out of the support window under a two-version rolling policy.

What the vendor announced	What still works	What you must do	Typical urgency
End of sale	Everything — patches, support, the product itself	Nothing immediate; flag in roadmap	Low (months to years)
Security-hotfix-only phase	Security patches only; no bug fixes or features	Plan migration; stop expecting non-security fixes	Medium (6–12 months)
End of support / End of life	Software runs; no patches, no support tickets	Execute migration or buy extended support if available	High (0–6 months before date)
Paid extended support	Security patches at additional cost, limited severity coverage	Budget for paid tier or migrate before it ends	Medium-high (budget cycle dependent)
Retirement / Hard shutdown	Nothing — service stops, data may be deleted	Export data and migrate before the date	Critical (hard deadline)

The distinction is not academic. A team that treats Sitecore's paid-extended-support change as an "end of life" may over-invest in an emergency replatform when budgeting for the paid tier and planning a 12-month migration would be the better move. A team that treats Project Online's retirement as a soft deadline — assuming Microsoft will extend it or offer a read-only grace period — will find there is none.

What Keeps Working After End of Support — and What Quietly Stops

The day after an end-of-support date, everything looks the same. The CMS serves pages. The CRM loads records. The temptation is to do nothing. But if you are running a CMS past end of support, here is what actually changes, often invisibly.

Security patches stop

Every newly discovered vulnerability in the product or its dependencies remains permanently open unless you patch it yourself or buy extended support where available. Any new vulnerabilities found after the EOS date will stay open unless your internal engineering team addresses them directly.

Many cyber insurance policies and compliance frameworks — SOC 2, ISO 27001, PCI-DSS — explicitly require all software to be actively supported by the vendor. Running unsupported software can void your compliance certifications and may affect insurance coverage at renewal. Under PCI-DSS v4.0, requirement 6.3.3 mandates that all system components are protected from known vulnerabilities by installing applicable security patches — vendor support status is a relevant factor in demonstrating compliance.

Vendor liability shifts to you

Once support ends, all risks and liabilities — including those from security incidents — shift entirely to your organization. This is not unique to any one vendor; it is standard language across virtually every enterprise software agreement. Review your specific license agreement for the exact indemnification language, but assume the liability transfer is unconditional.

Runtime and framework support erodes underneath you

Software does not run in a vacuum. It relies on an underlying operating system, a database, and a runtime environment. When a product reaches end of support, it is permanently locked to the runtimes available at that time.

Umbraco 13 reaches end of life on December 14, 2026, shortly after Microsoft's support for .NET 8 ends on November 10, 2026. Kentico Xperience 13 is built on .NET 6, which reached end of support in November 2024 — meaning Kentico 13 is already running on an unsupported runtime. When the underlying runtime loses support, you are stacking unsupported layers. Extended support programs like Umbraco's XLTS explicitly do not extend Microsoft's support for .NET 8 or guarantee continued support for independent third-party packages.

If your unsupported application requires an older Windows Server version or a deprecated PHP runtime, upgrading the underlying server OS or runtime will often break the legacy application — leaving you trapped on an aging, vulnerable stack.

Third-party integrations break silently

Modern applications rely on external APIs for CRM syncing, payment processing, and authentication. These third-party services continuously update their security protocols. If a payment gateway deprecates older TLS cipher suites, or a CRM updates its OAuth 2.0 flow, your unsupported software will not receive an update to handle the new protocols. The integrations will fail — causing silent data loss or hard application crashes.

Payment gateways, analytics SDKs, SSO providers, and API partners maintain their own compatibility matrices. When a platform falls off the vendor's supported-version list, those partners quietly stop certifying their connectors against it. You may not notice until an integration breaks after a partner-side update. Stripe, for example, has historically deprecated TLS 1.0 and 1.1 support with minimal notice, breaking integrations on legacy platforms that could not be updated.

Browser and OS compatibility drifts

Vendors stop testing against new browser versions and new operating system releases. Chrome releases a major version roughly every four weeks. A platform frozen at EOS will not have its admin panel or front-end JavaScript regression-tested against future browser releases. Behavior breaks silently.

Talent becomes harder to find

As time goes on, it becomes harder to find engineers who can support older software. Contractors and agencies stop investing in certifications and training for unsupported versions. The talent market moves before the software stops running — meaning the cost of maintaining unsupported software rises even as the software itself keeps functioning.

When "Do Nothing" Is the Actual Risk

The most dangerous response to an end-of-support announcement is treating it as a non-event because the software still runs the next day. The risk is not that something breaks on Day 1. The risk is cumulative:

Month 1–3: Nothing visible changes. Teams deprioritize migration.
Month 3–6: A security vulnerability is disclosed. No patch is available. The team must apply a manual workaround or accept the exposure.
Month 6–12: The underlying runtime loses support. Third-party packages stop testing against the old version. A dependency update breaks something and no one upstream will fix it.
Month 12+: Compliance audits flag the unsupported software. Cyber insurance questionnaires ask about patching cadence. The answers get uncomfortable. SOC 2 Type II auditors flag unsupported software as a control deficiency. PCI-DSS assessors may classify it as a failing requirement.

A product will not switch off on its EOS date, but "it still runs" is not the same as supported, secure, or compliant.

What a misread lifecycle label actually costs: failure cases

Compliance failure from treating EOS as EOS: A retail company running an EOS payment platform discovered during a PCI-DSS QSA audit that their CMS — which handled the checkout flow — was running on a runtime with no active CVE patching. The QSA classified this as a failing control. The merchant had to either purchase emergency extended support or freeze new card processing while the migration was expedited. The emergency cost was roughly 3x what a planned migration would have been.

Data loss from treating retirement as EOS: A professional services firm received a retirement notice for a project management SaaS and assumed, based on prior experience with on-premise EOS events, that they would have post-shutdown read-only access to export data. They did not. The hard shutdown deleted tenant data. Documents that had not been exported were unrecoverable. Vendor confirmed no restore mechanism existed after the shutdown date.

Integration failure from ignoring rolling policy: A development team on Optimizely CMS 11 had no fixed date on their calendar and no active migration plan. When CMS 13 reached GA and triggered the rolling policy, their payment connector vendor immediately dropped CMS 11 from its certified compatibility matrix. The checkout integration broke in production two weeks later when the connector's cloud-hosted endpoint enforced a version check.

These cases illustrate why the label on the announcement matters less than understanding the specific mechanism of failure it implies.

How to Read Any Vendor's Lifecycle Announcement

When a vendor publishes an end-of-support, end-of-life, or retirement notice, ask these five questions:

Does the software stop running on the date, or does it keep running unsupported? If the service is turned off (retirement), you have a hard data-export deadline. If it keeps running (end of support), you have more flexibility but accumulating risk.
Is there a paid extended-support option, and what does it actually cover? Sitecore's paid extended support covers security patches. Microsoft's ESU covers critical and important patches only — vulnerabilities rated "moderate" or "low" will not be addressed. Know the scope and the per-year price before you budget for it.
What is the underlying runtime's support date? If the framework (.NET 8, PHP 8.1, Java 11) loses support before or shortly after the application does, you are stacking two unsupported layers. Check the runtime's lifecycle page separately — it is not always mentioned in the application vendor's announcement.
Does the vendor publish fixed dates, or use a rolling policy? Fixed dates (Kentico, Umbraco, Microsoft) let you plan against a calendar. Rolling policies (Optimizely) require you to watch release announcements because any new major version can push your current version out of the support window with little advance notice.
What happens to your data after the date? For self-hosted software (Kentico, Umbraco, Sitecore on-prem), your data stays in your database — you lose vendor support, not access. For SaaS retirements (Project Online, Meta Workplace), data may be permanently deleted on or shortly after the shutdown date.

The Two Clocks: Data Migration vs Platform Rebuild

Every end-of-support scenario involves two separate efforts that run on different timelines. Conflating them is one of the most common planning errors.

Moving the data — content, records, configurations, history — is one project. Rebuilding the application — templates, integrations, workflows, custom code — is a different project measured in months. Selecting a new vendor, negotiating contracts, rewriting custom business logic, and training staff typically runs to many months, and our estimate for a large replatform is a year or more for enterprise systems. The data migration is a component of the larger replatforming project, not a substitute for it.

Keep these two clocks apart. The EOS announcement sets the deadline for the whole project. The data migration executes near the end of that timeline — after the new platform is built, configured, and validated. Starting the data migration before the destination platform is ready is a common sequencing error that results in migrated data sitting in a half-built system while the source platform continues to accumulate changes.

If you are weighing whether to act on an upcoming end-of-support date, our complete 2026 EOL calendar lists every major product reaching its deadline this year. Our Microsoft 2026 end-of-support timeline covers SharePoint, Exchange, and Office Online Server specifically. And our Project Online retirement guide shows what a real service cutoff looks like in practice.

ClonePartner handles data migrations — moving content, records, and relational data from legacy platforms to new ones. If the data-migration component of your replatforming project is your immediate constraint, see how we work or book a scoping call to get a fixed-price proposal.

End of Support vs End of Life: What the Terms Actually Mean

Planning a migration?