Chasing .NET: the platform upgrade treadmill

A .NET-based commerce platform inherits Microsoft's runtime calendar. Each Long Term Support release is supported for three years, but a new one ships every two, so roughly every 24 months you owe a mandatory major-version migration: dependency audits, a full regression pass, and coordinated module updates across your customizations. That cadence is set by runtime end-of-life, not your product roadmap. The platform vendor tracks it; you pay for it.

Why does a .NET platform hand you Microsoft's calendar?

The runtime under a commerce platform is not decorative. When a platform pins its target framework to a .NET release, it also pins itself to that release's end-of-life. Microsoft ships a new .NET every November and designates the even-numbered ones Long Term Support: supported for three years from general availability. .NET 6 arrived in November 2021, .NET 8 in November 2023, and .NET 10 on 11 November 2025 — a fresh LTS every two years.

Do the arithmetic and the trap is plain. Each LTS is superseded by the next one two years in, and loses support one year after that. .NET 6 reached end of support on 12 November 2024; .NET 8 is scheduled to follow on 10 November 2026; .NET 10 runs through 14 November 2028. Once a runtime hits that date, security patches stop — which, for anything touching payment, stock, or customer data, converts an optional upgrade into a compliance deadline.

This is not a vendor defect; it is the deal you accept when your platform is a .NET application. The platform team can choose which LTS to sit on and when to jump. The jump itself is non-negotiable, and its timing is dictated by a support table published in Redmond.

What does one runtime jump actually cost?

Vendors describe these upgrades as routine, and structurally they are. Per Virto Commerce's release notes, the platform's move to .NET 8 shipped as release 3.800, which retargeted the framework and pulled in the latest LTS versions of its third-party libraries while leaving the public API untouched. The core changed as little as possible. That is the good case, and it still is not free.

The cost lands downstream, on everything you built on top. A framework major-version bump means your custom modules recompile against a new runtime and, usually, new major versions of shared libraries; every extra NuGet package you pulled in needs a version that supports the new target net8.0; and the tooling moves too — release 3.800 expects Visual Studio 2022 (17.8 or later) and the .NET 8 SDK on every developer's machine, per the same notes. None of it is exotic, but all of it is coordinated work with a hard sequence: audit dependencies, resolve version conflicts, rebuild, then run a full regression pass, because an unchanged public API is a promise about the core, not about your code.

This is where a platform's flexibility turns into a standing liability. The more you have customized — bespoke pricing, a returnables workflow, a trade-promo integration — the more surface has to be revalidated on every jump. If those extensions are the sort that only the original consultants can safely touch, the runtime calendar quietly becomes their retainer schedule. And the people doing the audit-and-regression work are exactly the .NET specialists that running this platform already demands: as we have argued elsewhere, you pretty much need an IT department to keep it in production. The upgrade is where that headcount earns its keep, or where its absence shows.

Framed honestly, this is a recurring, involuntary cost on a cadence someone else sets — the same shape as paying a five-figure annual fee to read your own data. It rarely appears as a line item. It shows up as two or three engineers disappearing into a migration branch every couple of years while the roadmap waits.

Where does .NET 8 leave a platform right now?

Concretely, as of late 2025: a platform whose current runtime is .NET 8 is sitting on a release that loses support on 10 November 2026 — under twelve months away. .NET 10 became available on 11 November 2025. So the next jump is not hypothetical; it is already on the board, with a named target and a fixed deadline. Any 2026 capacity plan that fails to reserve room for it is, in effect, planning to miss the deadline.

That is the treadmill in a single frame. You finish the .NET 6-to-8 migration, bank the performance gains, and the .NET 10 clock is already running. The work is never done because the runtime is never done — and each cycle you defer compresses the window before support runs out.

So how do you get off it?

You do not, entirely: anything built on a runtime inherits that runtime's end-of-life, and that includes whatever we build. What you can change is who absorbs the shock and when. Keep third-party dependencies few and current, isolate customizations behind stable seams so a framework bump recompiles them without rewriting them, and own the source so the upgrade is a sprint you schedule rather than a vendor release you wait on. We run our suites on a single event bus partly for this reason: a bounded, well-understood surface is cheap to move forward.

Microsoft's rhythm is not going to change: a new LTS every other November, each with a three-year fuse. .NET 8's fuse burns out in 2026, and by the same even-year cadence the LTS after .NET 10 lands roughly two years past that. Treat that calendar as a fixed input to your planning, the way you treat a lease renewal, and the treadmill stops being a surprise you absorb and becomes a maintenance line you budget. The platforms that age well this decade will not be the ones that dodge the runtime calendar — none can — but the ones whose owners decided, in advance, exactly how much of their business the next jump is allowed to touch.