Bridging the Gap
Taking It Upstairs: the business case from every episode of Bridging the Gap, a series for teams still running on .NET Framework. Written to be forwarded.
What this page is
Bridging the Gap is a six-part series on The Modern .NET Show for developers who work on .NET Framework and expect to keep working on it.
Every episode ends with a segment called Taking It Upstairs. Most developers cannot authorise modernisation work. They can only make the case for it to somebody who can. So each episode ends with one specific, practical piece of that case, written in business language rather than developer language.
This page collects all of them in one place.
If somebody has sent you this link, they are probably asking you to read one section of it. You do not need to listen to the podcast, and nothing below assumes you write software.
If you are the developer, this is the page to send. It updates as each episode airs.
A disclosure, because the series carries one and this page should too. The Modern .NET Show is produced by RJJ Software, which is also who I work for, and some of what RJJ does is application modernisation. That means I have a commercial interest in you deciding to modernise. You should know that before you read a page full of my advice about it. There is no pitch here, and there is not one in any episode of the series either.
The premise, in one paragraph
Running on .NET Framework in 2026 is usually a constraint rather than a failure. Procurement cycles, compliance sign-off, an on-premises estate, a vendor support matrix, a licensing dependency on some other product entirely. The engineers maintaining the application did not choose most of those, and cannot remove them.
The series is not a migration guide, and its destination is not the newest version of .NET. It is a version the organisation can stand still on.
Part 1. What your manager is actually worried about
From You Are Not Behind, 11 September 2026.
Before you make any case for modernising a .NET application, work out which risk the decision-maker carries. In most organisations it is one of four. None of them is technical.
Operational risk sits with the manager, not the engineer. If a change to a working revenue system causes an outage, the engineer explains it to their manager. The manager then explains it to the business. That asymmetry is what a “no” usually protects against. Doubt about the technology rarely is.
Modernisation produces no customer-visible outcome. The work consumes budget and delivery capacity. At the end of it, the software does exactly what it did before. That is a hard thing to defend at a quarterly review.
A partially completed migration is worse than one never started. It leaves two technology stacks to maintain and two sets of skills to recruit for. It also leaves an ongoing cost with no completion date.
The largest costs usually sit outside the code. Re-certification, re-accreditation, a fresh penetration test, and vendor support matrices that no longer cover the new version. Engineering estimates routinely exclude all four.
The ask for this episode is small. Do not build a case yet. Identify which of these four risks you are actually discussing. That costs nothing and changes no code. It also makes every later conversation possible.
Part 2. Write the decision down
From You Might Not Need to Upgrade, 9 October 2026.
Some organisations should not modernise a working application this year. The problem is that almost none of them have said so on paper, which leaves the decision looking like neglect rather than judgement.
The request is not permission to stay on the current platform. It is permission to record the decision. That distinction matters, because it is a much smaller thing to approve. It needs one meeting and no budget.
A recorded decision has six parts. The platform version currently in use. The options the team considered. The cost of moving, in people and in weeks. The benefit of moving, stated honestly, including where there is none. The support end dates for every option, including the current one. And the conditions that would change the answer.
It must carry a review date. Twelve or eighteen months. A decision with no review date is not a decision. It is a delay in formal clothing, and it will be read that way later.
It must be signed by the budget holder, not the engineer. A decision an engineer records alone remains that engineer’s decision. A decision the business signs becomes the organisation’s decision. Those two documents behave very differently when somebody asks questions eighteen months from now.
The honest caveat. This exercise can return the opposite answer. If the arithmetic says the work should happen, the resulting document says so, in writing, with a signature on it. Anybody who only wants the exercise when it agrees with them is not running a decision process. They are looking for permission.
Still to come
This page is updated as each episode airs.
- Part 3. Onboarding and hiring, framed as retention rather than recruitment.
- Part 4. Supply chain and audit. What happens when a package the product depends on stops shipping a compatible version.
- Part 5. The blocker inventory, which turns a vague “we cannot” into a costed list.
- Part 6. Hosting cost, and the honest admission that cross-platform support is worth nothing to an organisation that will never leave Windows.
One promise the series makes
At least twice across these six episodes, this segment concludes that the manager is right and the answer is no.
That is deliberate. A series that always concluded “yes, approve the work” would not be worth reading, and neither would this page.
Get in touch
If the series describes your situation badly, or misses a constraint you actually have, the contact page is here and there is a Discord.
I am also looking for people to talk to on air: somebody in an NHS trust, a local council, an insurer, a manufacturer. People with a .NET Framework application and a real set of constraints, rather than people with something to sell. Anonymised, if your employer needs it to be.