The platform that quietly moved on without you

A great many business applications were built on Microsoft’s .NET Framework. If one of yours was, you are in an unusual position: the platform is not dead, but it has stopped moving. Microsoft rebuilt .NET from the ground up as a modern, cross-platform technology, and that new .NET is where all the investment, the new features and the wider ecosystem now live. The old .NET Framework still runs and is still supported alongside Windows — but it is frozen in place, and the gap between it and the current platform widens every year.

That makes this a quieter, more insidious version of the stranding problem. There is no loud end-of-life date forcing your hand. There is just a platform that the rest of the world has left behind, and an application that gets harder to maintain, hire for and extend with every passing year.

Why moving across is a re-platform, not an upgrade

The current .NET is a modernised rewrite of the old Framework, not a continuation of it. You cannot mix the two in the same application, so moving across means porting the application to the new platform — and for some technologies, porting means rebuilding.

Two cases matter most for business applications. If your application uses Web Forms — a very common way of building older .NET web applications — there is no equivalent in modern .NET at all. Those applications have to be rebuilt on a different approach, not ported. And if your application relies on WCF for its services, the server side of that technology was never carried into modern .NET, so those parts must be re-implemented on a newer approach. Add the third-party components that have no modern equivalent or have been replaced, and a “migration” becomes, in places, a rebuild.

The trap of “it still works and it’s still supported”

Because .NET Framework remains supported with the operating system, it is easy to conclude there is no problem. The application runs, the platform is patched, nothing is on fire. But “supported” here does not mean “thriving.” No new features are coming. The libraries and tools you would want to use are being built for modern .NET. The developers entering the field are learning the new platform, not the old one. You are running a viable application on a foundation that is slowly becoming a specialist concern — and specialist concerns get expensive.

The risk is not a sudden cliff. It is a slow narrowing of your options: harder to hire, harder to integrate with anything modern, harder to justify building anything new on top. One day you need to add a capability and discover the foundation will not support it without the move you have been deferring.

How to approach it

The first step is discovery, and in .NET migrations this is where the real problem lives. Most organisations do not have an accurate picture of what their application depends on — which components have a modern equivalent, which do not, where Web Forms or WCF are in play, and which third-party libraries will block the move. That picture, not the code conversion, is what determines the size and shape of the work.

From there, the move is often best done in phases — migrating the parts that port cleanly, rebuilding the parts that cannot, and doing it in a sequence that keeps the application running throughout. The wrong approach is an all-or-nothing rewrite begun without that discovery, which is how .NET migration timelines blow out.

If a business application of yours is built on .NET Framework, it is not in crisis — but it is on a foundation the world is steadily leaving, and the move only gets larger the longer it waits. We will establish what your application actually depends on and what moving it would take.

Start a Conversation