Sitefinity Upgrade: Four versions will reach end-of-life simultaneously in November

In November 2026, support for Sitefinity versions 15.0, 15.1, 15.2, and 15.3 will end. This information can be found in Progress’s Sitefinity Life Cycle Policy Guide (as of October 29, 2026).
This post explains the applicable deadlines, the differences between “Active,” “Sunset,” and “Retired” statuses, how the release model changes with version 15.4 LTS, and what factors influence the effort required for a version upgrade.

For a publicly accessible website, the difference between “Sunset” and “Retired” is therefore anything but academic. During the Sunset phase, at least the most serious vulnerabilities are still covered; after that, there is no longer any guarantee.

One sentence in the policy tends to get overlooked, but it has direct consequences: “Releases and versions not included in the table below should be considered retired.” Anyone working on a version that no longer appears in the vendor overview doesn’t even need to ask about support.

This results in two groups with different levels of urgency. Those running versions 15.0 through 15.3 have a clear timeframe until November 2026, and the path to 15.4 LTS is technically the shortest because it remains within the same major version. On the other hand, for versions 13.x or 14.0 through 14.3, there are already no longer any guaranteed security updates. Here, it’s no longer a matter of planning, but of catching up.

The most common objection to an upgrade is that the site is already working fine. That’s true, but it doesn’t help much, because a risk doesn’t become apparent during normal operation—it only becomes evident in an emergency.

Three points are regularly overlooked in this context. The first: Sitefinity relies on third-party components, most notably the .NET framework. Progress itself points out that support for a third-party library may end sooner than support for the Sitefinity version, and recommends upgrading in such cases. So Sitefinity’s own lifecycle isn’t the only clock ticking.

Second: With retirement, additional options are no longer available. Retired versions are not supported in Sitefinity Cloud, and Progress recommends updating to a supported version before deploying to the cloud. So anyone considering a move to the cloud later on will have no choice but to upgrade anyway—only with more time pressure.

Third: The gap is growing. Upgrading across two major versions isn’t simply twice as much work as upgrading across one, because customizations, third-party modules, and dependencies have diverged further in the meantime. The longer an upgrade is put off, the bigger the project becomes.

From a technical standpoint, a version upgrade is often less complicated than expected. Things get tricky when customizations from previous years are tied to models that are no longer recommended as a base.

For new projects, we recommend Progress’s ASP.NET Core Approach, optionally with a front end built on Next.js. Existing MVC-based implementations will continue to run: According to Progress Supported in all supported versions, but Progress recommends an upgrade here as well. For WebForms front ends, which are still found in older installations, however, there is no longer a choice. Progress discontinued WebForms support in the front end with version 14.1; 13.3 LTS was the last officially supported version for this. Anyone using WebForms pages, templates, or widgets must convert them when upgrading to ASP.NET Core or Next.js. Migration to MVC is only possible if there are very few WebForms elements in an otherwise MVC-based project.

That’s why it’s worth treating an upgrade as two separate decisions. The first concerns the version and is dictated by deadlines. The second concerns the front-end model and—provided WebForms isn’t involved—is a genuine choice: stick with what’s working, or take this opportunity to migrate templates and widgets to the recommended approach. Both approaches are valid; it should just be a conscious decision and not a byproduct that simply happens as the project progresses.

Progress provides tools to facilitate the process, including the Migration Analyzer and CLI support, as well as documented upgrade guides for each source version. This process has proven effective for us in our projects:

It’s impossible to give a reliable figure without looking at the installation, and generalizations can be particularly misleading when it comes to upgrades. Four drivers account for almost all of the effort involved.

The extent of customizations is the most significant factor: How many custom widgets, templates, and extensions are there, and to what extent do they affect the core? An installation that’s close to the standard is a completely different project than one that has been extensively customized over the years.

Then there’s the version gap: A jump from 15.3 to 15.4 behaves differently than one from 13.3 to 15.4.

A third factor is third-party modules and integrations, because they don’t fit into our own schedule. A module without a compatible version quickly becomes a bottleneck.

And finally, test coverage. When there is documentation of what needs to work, the acceptance process goes smoothly. If this foundation is missing, it is developed during the project which is time well spent, but needs to be factored into the schedule.

For some Sitefinity installations, the deadline has been set: November 2026 for versions 15.0 through 15.3 and April 2027 for 14.4 LTS. For versions 13.x and 14.0 through 14.3, the deadline has long since passed.Anyone upgrading to 15.4 LTS now will likely be making the last major version jump for quite some time, because Progress will switch to cumulative product updates afterward. Two things pay off here: making a conscious decision about the front-end model and writing the test plan before the upgrade rather than after.

We are a certified Progress Sitefinity partner and hold the following badges Technical Accredited Sitefinity and Digital Agency Partner. When it comes to upgrades, however, there’s something else that matters: We have a background in .NET development and bring more than 25 years of experience with software and its interfaces to the table. The stumbling blocks of an upgrade rarely lie in the CMS core; more often than not, they stem from customizations and integrated systems.

Not sure which version your website is running on or how urgent the upgrade is?
That’s a good place to start. Get in touch with us we’ll review the version, customizations, and integrations and let you know what needs to be done and by when.