Two deadlines and three routes
Umbraco 13 loses support on December 14, 2026 – 90 days from the date this was published.
This is for whoever owns that decision on an Umbraco 13 site: the technical lead, or the person who signs off the budget. It assumes you already know what End of Life means. If you do not, that part is covered here.
What follows is the two dates that bound the decision, three questions to open an assessment with, and three routes – separated by whether the work fits the time you have left.
The two deadlines
Most of the discussion around this treats December 14 as the deadline. There are two deadlines, and they have different consequences.
November 10, 2026 – .NET 8 support ends. Umbraco 13 runs on .NET 8. When Microsoft support ends, the runtime underneath the CMS stops receiving fixes, a month before Umbraco's own date.
December 14, 2026 – Umbraco 13 support ends. No further security patches for the CMS itself.
How much time you actually have
90 calendar days is roughly 13 working weeks. Three things take weeks off the front and back before any code is written.
Deployment headroom. "Live before the deadline" and "deployed on the deadline" are different plans. The latter leaves no space for serious incidents that could surface after go-live.
Budget approval. If this work is unplanned, budget needs to be approved, but the clock is already ticking.
Your own release calendar. If your organization runs a year-end change freeze, it brings your last possible deployment date earlier by however long the freeze lasts.
Subtract those from thirteen weeks and you have the window. That number, not ninety days, is what the rest of the decision runs against.
Write down which deadline the window ends at, and why. It is the single most useful line in the whole plan, because every route below is chosen by comparing the assessed work against it.
Three questions to open the assessment
These questions will tell you what needs assessing properly and surface the obvious blockers early – the difference between a meeting and a real inventory, which takes about an afternoon.
Answer them against the solution itself rather than from memory.
Which third-party packages are in the solution, and which have a v17 release? Every package without one forces a decision – replace it, fork it, or drop the feature – and those decisions carry their own scope.
Are there custom backoffice extensions? Property editors, dashboards, custom trees, content apps. Anything built in AngularJS does not carry forward: the backoffice was rebuilt in v14 and there is no compatibility layer for the old extension model, so that work is a rewrite.
How much legacy content architecture is in the content types? Nested Content, the old Grid, macros, XPath-based pickers, the legacy Media Picker. Each has a migration path, and the cost depends on how much content sits behind it and how that content is rendered and verified afterward.
The full audit checklist is in Upgrading Umbraco 13 to 17: What Actually Breaks.
What comes out of this is an estimate of the work. Set against the window you calculated, that estimate is what selects the route.
A rebuild does not have to start from zero
I’ve built KindbergCo Platform as a reusable foundation for Umbraco projects, bringing together content blocks, editorial tools, and built-in support for performance, accessibility, SEO, and multilingual content. It is built with best practices from real project experience and powers my own website.
Where it fits your requirements, that foundation reduces the work needed to rebuild. More of the budget can go toward your content, integrations, and specific business needs.
That is worth including in the comparison: assess the upgrade against a rebuild using an existing foundation, with content migration and project-specific development accounted for in both estimates.
Route 1: upgrade before support ends
Criterion: the assessed work fits the delivery window, including testing and contingency.
Stage the upgrade rather than jumping – 13 to 14 to 15 to 16 to 17, with a working, tested build at each step. It takes longer than a single jump and it turns "something broke somewhere across five major versions" into a defect you can locate.
When you check the fit, include the lead time on whoever does the work. If the upgrade is going to an external team, their availability is part of the window, not separate from it.
Route 2: schedule the upgrade, buy temporary support
Criterion: the upgrade is viable, but it does not fit the window.
Set the upgrade date first, then buy support to cover the gap – in that order, so the coverage is sized by a plan rather than the plan being shaped by the coverage you bought.
What XLTS covers. Umbraco publishes 6, 12 and 24-month periods, security patches only, starting the day after December 14, with periods required to run continuously.
What is not published. Pricing and any purchase deadline. Confirm both with Umbraco directly, and do it early enough that the answer can still change your plan.
What it does not solve. The .NET 8 runtime will remain without updates, hence remains a potential security gap.
The cost comparison between covering and upgrading is in Umbraco 13 XLTS vs upgrading.
Route 3: compare a rebuild against the upgrade
Criterion: the changes required are substantial enough that comparing migration with rebuilding is worth the assessment effort.
This route is a comparison, not a decision. You cost the upgrade and the rebuild against the same requirements and evaluate the costs and benefits. Three things commonly justify running that comparison:
Backoffice extensions that need rewriting anyway. If AngularJS editors are being rebuilt regardless, the question of what else could change opens with them.
A content model already being restructured. If the content types are changing for editorial reasons as well as technical ones, the migration and the redesign compete for the same work.
Packages with no v17 path and no drop-in replacement. Replacing a core piece of functionality is a build either way.
One thing that does not by itself justify a rebuild: a large integration surface. An ERP, a PIM and a commerce platform hanging off the CMS usually mean more coordination, more environments and more regression testing – which lengthens the upgrade rather than invalidating it.
A rebuild will not finish before December, so this route needs temporary support as well. The comparison itself is worth doing early: it is the input to the 2027 budget either way.
Umbraco 18 is out, but 17 is the target
Umbraco 18 was released on June 25, 2026, so it is the newest version on the list when you go looking. It is a Standard-term Support release: security-only phase from March 25, 2027, support ending June 25, 2027.
Umbraco 17 is the Long-term Support release. Security-only phase from November 27, 2027, support ending November 27, 2028 – seventeen months later than 18.
Moving from 13 to 18 therefore buys roughly nine months before the same decision comes back. If the reason for moving is that support ran out, move to the version with the most support ahead of it. Umbraco 18 is the right target if you specifically need something in it that 17 does not have; otherwise the destination is 17.
What to put on record this week
The package inventory, with the v17 status of every entry.
The delivery window: the date it is calculated back from, which of the two deadlines it targets, and what was subtracted to get there.
The route, agreed in writing with whoever owns the budget as well as whoever owns the code.
If route 2 or 3: the pricing and purchase-deadline questions put to Umbraco.
A line in the 2027 budget. Deferring the decision moves the cost; it does not remove it.
Running unsupported software can be a defensible position when it is documented, risk-assessed and has a date attached to the fix. The position that is hard to defend in a security review or a supplier assessment is not having an answer. The difference between the two is a decision someone made on purpose.
If you want the assessment run against your actual solution, that is what an upgrade assessment is: a package-by-package inventory, the customizations and blockers found in the backoffice and content model, and a recommended route with an estimate of the work involved – in writing, so it can go straight to whoever holds the budget.
Version and support dates checked against Umbraco's LTS and End-of-Life documentation and Microsoft's .NET support policy on September 15, 2026. XLTS pricing and purchase terms are not published in full and change over time – confirm current terms with Umbraco before relying on them.