• Umbraco

Planned Obsolescence in the Umbraco Lifecycle

Happy upgrading from Umbraco 13 to 17. Then 17 to 21. The treadmill continues; value delivered to the client often does not. The bill, however, does.

The Core Problem

Planned obsolescence means designing products to become outdated or need replacement on a schedule that benefits the vendor, not the user. Umbraco’s release model fits this idea.

Umbraco pre-announces breaking changes on a calendar. Version 18 will contain breaking changes and ship on a specific date. So will 19. So will 20. This is declared before the features requiring those breaking changes exist.

The Inverted Causality

Normal engineering causality works like this: a technical prerequisite emerges, no non-breaking path exists, and a breaking change becomes the last resort. The breakage is a consequence of the work.

Umbraco does the opposite. The schedule sets the expectation for breakage, and reasons are found afterward. This turns breakage into a policy result, not a technical obligation.

This raises an uncomfortable question with only two answers:

  1. The scope flexes to fit the date — meaning the breaking changes that ship are whatever happened to be ready, not what was strictly necessary; or

  2. The breakage itself is the deliverable — and features are secondary to supporting the cadence.

Neither answer looks good. A team cannot know months in advance that a certain feature will require a breaking change and be finished by a set date, unless the schedule is driving the work rather than the feature.

The Side-by-Side Question

Breaking changes are not the only tool for evolving an API. The platform Umbraco is built on proves it:

.NET itself runs multi-year deprecation cycles. APIs are marked [Obsolete], warnings are issued over several versions, and removal occurs only after developers have had years of runway.

Side-by-side APIs, adapter layers, and compatibility shims are standard practice across the ecosystem.

Umbraco is built on a platform known for backward compatibility, yet it regularly does the opposite. Some of this change is inherited because Umbraco follows Microsoft’s yearly .NET updates, so some breakage is real. But that only explains part of the story. It doesn’t account for things like content pipeline rewrites, backoffice redesigns, or management API changes that aren’t tied to the framework version.

The “Just Ride LTS” Rebuttal — And Why It Fails

The standard defense: “Real breaking changes only matter LTS-to-LTS. Ignore the STS versions in between.”

This fails for three reasons:

  1. STS is not a sandbox — it’s the mainline. Version 20 is the accumulation of 16, 17, 18, and 19. The STS versions are not prototypes or throwaway experiments; they are the actively developed trunk that the next LTS is built from.

  2. The knowledge burden doesn’t skip versions. Even if your projects stay on LTS, you as a practitioner must track what’s changing in every STS release, because that’s where the future is being written. The cognitive load is continuous regardless of your upgrade cadence.

  3. Skipping versions batches the debt — it doesn’t erase it. Deferring migrations means paying a lump sum with interest: a larger, riskier, more expensive upgrade project that must then be justified to a client whose site does exactly what it did before the invoice arrived.

The Business Impact

For agencies selling and supporting Umbraco:

  • Cognitive burden: Continuous tracking of changes across versions, whether or not any client project adopts them.

  • Upgrade cost without upgrade value: Migration projects where the foundation (the actual capability delivered to the client) has not significantly changed.

  • Trust erosion: Explaining to clients why they must fund an upgrade that delivers no visible improvement is a recurring tax on the agency-client relationship.

Planning uncertainty: Pre-announced breakage without pre-announced content means budgeting for unknowns on a known schedule.

The Steelman (In Fairness)

Microsoft’s annual .NET release cycle imposes real constraints; some breakage is inherited, not invented.

  • Having a predictable schedule is arguably better than random breakage, since at least you know the dates in advance.

  • Long-lived compatibility layers carry their own maintenance cost, and Umbraco’s team is not infinitely resourced.

These points are valid, but they don’t go far enough. A predictable schedule of unpredictable breakage isn’t real stability. It’s just planned obsolescence on a set timeline.

Happy upgrading from Umbraco 13 to 17. Then 17 to 21. The treadmill continues; value delivered to the client often does not. The bill, however, does.

I’m not against change itself. My issue is with a model that plans for breakage before it’s needed, skips gradual improvements, and passes the cost on to agencies and clients who rely on the product, even though the CMS’s everyday value remains largely the same. There are real alternatives, like using deprecation cycles, side-by-side APIs, and multi-version support. That’s already how the platform under Umbraco works.

Article by

Mark has more than a decade of experience architecting enterprise web, mobile, and XR platforms. He helps organizations turn complex requirements into scalable, maintainable solutions that balance technical rigor with real-world constraints.