---
title: "S09E01 - You Are Not Behind: Why You Are Still On .NET Framework"
url: https://dotnetcore.show/season-9/you-are-not-behind-why-you-are-still-on-net-framework/
date: 2026-09-11
author: "Jamie Taylor"
summary: "Jamie opens season 9 with the first episode of Bridging the Gap. The series is for .NET developers who are still on .NET Framework and expect to stay there. Being on Framework in 2026 is a constraint, not a character flaw. People confuse the two constantly. Richard Campbell explains ontological humility. You do not look at working code and declare that it needs a rewrite. Nick Craver describes an ISO 9001 job with so much red tape that he had spare time. He used it to become one of Stack Overflow's top users. Jamie also checks seven years of tapes to attribute an aphorism properly. The episode sets the contract for the series and introduces a recurring segment called Taking It Upstairs."
audio: "https://traffic.libsyn.com/thedotnetcorepodcast/S09E01-Bridging-the-gap-1.mp3"
episode_id: 197
duration: "PT32M15S"
---

# S09E01 - You Are Not Behind: Why You Are Still On .NET Framework


## Episode Summary

Season 9 opens with the first episode of a series called Bridging the Gap. The six episodes are for .NET developers who are still on .NET Framework. Most of them expect to stay there for a while, and most are tired of the cautionary-tale treatment.

The premise of the series is a single distinction. Being on .NET Framework in 2026 is a constraint, not a character flaw. Procurement cycles, compliance sign-off, an on-premises estate, a vendor support matrix, a no-open-source policy. The developer made none of those decisions. Almost everyone reads them as though the developer did.

This opening episode sets the contract for the season. It also hands the frame to three guests from the archive. All three made the point better, and earlier, than Jamie ever acted on.

Topics covered in this episode include:

- Why the word "still" in "still on Framework?" does more damage than any technical argument
- The destination for this series, which is not the latest .NET but a version you can stand still on
- An up-front commercial disclosure about who produces this show and what they sell
- Three moments from 2019 and 2020 when Jamie reached for the no-shame framing and then did nothing with it
- Richard Campbell on ontological humility, and the case for extending it to yourself
- Seven years of tapes, and the proper attribution of an aphorism about existing code
- Nick Craver's ISO 9001 job, and what its red tape did to one of the best infrastructure engineers in the business
- Why "nobody wants to feel left behind" remains the most accurate sentence on this subject
- Taking It Upstairs, the segment that will close every episode in the series

## Taking It Upstairs

*A written version of this episode's segment, in business language. Forward it to whoever needs to read it.*

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.

*Every episode in this series adds one of these. They are collected on a single page at [dotnetcore.show/bridging-the-gap](https://dotnetcore.show/bridging-the-gap/), which is the one link to send if you would rather not forward a podcast episode.*

## Episode Transcription

Hey everyone, and welcome back to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. I'm your host Jamie Taylor, bringing you conversations with the brightest minds in the .NET ecosystem.

Today's episode is a little different from the norm. There's no guest; it's just me. And it's the first episode of season nine, and the first episode of a series that I have apparently been meaning to make for about seven years without ever noticing that I was meaning to make it.

So let's sit back, open up a terminal, type in `dotnet new podcast` and we'll dive into the core of Modern .NET.

### The Half-Second Pause

I want to start with a moment that I think a lot of you will recognise.

You're at a conference, or a user group, or you're on a call with a vendor. Somebody asks what you're working on. And there's this half-second where you decide how to answer.

Because the honest answer is something like: "a fairly large ASP.NET MVC application, on .NET Framework 4.8, that has been running since 2014 and makes the company most of its money."

And you know, from experience, what tends to happen when you say that out loud. There's a pause. Sometimes a small change in tone. Sometimes it's sympathy, which is honestly worse than anything else on the list. And very often, somewhere in the reply, there's a single word.

"Oh, you're *still* on Framework?"

Still.

That word does an enormous amount of work, and almost none of it is technical. "Still" takes a fact about a piece of software and quietly converts it into a fact about you. It implies a race that everybody else finished. It implies that the only variable was effort, and that yours ran out.

I've been hosting this show since 2018. In that time I've recorded close to two hundred episodes, most of them conversations with .NET developers, and I have heard some version of that half-second pause more times than I can count. Usually off-mic. Usually from people who are extremely good at their jobs.

So here's the sentence this whole season is built on, and I want to say it before I've earned it, and then spend the rest of the episode earning it.

You are not behind. You are constrained.

Those are different things. They feel identical from the inside, they look identical from the outside, and almost nobody in this industry talks about the difference.

### What This Series Is

This is the first of six episodes I'm calling Bridging the Gap. They'll be spread across season nine, roughly one a month, with the usual interview episodes in between.

The series is for a specific person. You work on .NET Framework. You expect to be working on .NET Framework for a while yet, possibly a long while. And that isn't because you haven't read the release notes.

I want to be very precise about what these episodes are for, because there is already an enormous amount of content about migrating to modern .NET, and most of it assumes you have both the authority and the runway to do it.

This series is not a migration guide. I'm not going to teach you to port an application, because in most cases you already know roughly how you'd do it and that has never been the blocker. What I want to give you instead is enough understanding of what modern .NET actually is, and how it actually differs, that you can make a credible internal case for change to people who control budgets. And, just as importantly, so that you can tell when the honest answer is that you shouldn't.

And there's one reframe underneath all of it that I want to plant now, because it's the thing that makes this achievable for somebody with a day job and no authority.

The destination is not the latest .NET.

The destination is a version you can stand still on.

That's it. That's the whole shift. Everything about the modern release cadence, and everything about the way this stuff gets written about, assumes that the goal is to arrive somewhere current and then keep moving forever. For a great many of the organisations you work in, that assumption is simply wrong, and pretending otherwise is why so much of this advice bounces straight off.

Every episode in this series will also finish with a segment called Taking It Upstairs. I'll explain it properly at the end of this one.

### Something You Should Know First

Before I go any further, there's something you're entitled to know, and I'd rather you heard it from me in the first ten minutes than worked it out in episode four.

This show is produced by RJJ Software. RJJ Software is also who I work for.

RJJ does technology consulting. Some of that work is application modernisation. Which means that in this series, specifically, on this subject, I have a commercial interest in you deciding to modernise.

So I'm telling you that now, at the start, before I've made a single argument. And then I'm going to spend six episodes arguing that a good number of you should not.

There's no pitch attached to that. No offer, no URL, no "book a call". There won't be one in any episode of this series. This is the only reason I'm mentioning the company at all: because I think you should be able to weigh what I say against what I stand to gain from you believing it, and you can't do that if I don't tell you.

I'll repeat a shorter version of this at the top of every episode in the series, because people drop into a season halfway through and they deserve the same information.

### Constraint, Not Character

Right. Let's talk about why you're actually on Framework. Not the reason people assume. The real one.

Maybe your organisation runs on a procurement cycle where any new software dependency takes eleven months and three sign-offs. Maybe you're in a regulated sector and every change goes through a validation process that treats a runtime upgrade exactly the same as a change to clinical logic. Maybe your entire estate is on-premises, on Windows Server, in a data centre with a refresh cycle measured in half-decades.

Maybe there's a vendor in the mix. Some line-of-business product, right in the middle of everything, whose support matrix says .NET Framework 4.8 and whose support contract becomes void the moment you deviate from it. Maybe that vendor was acquired in 2021 and nobody has answered an email since.

Maybe your company policy is no open source code. That's a real policy. I'll come back to that one later, because somebody said something about it on this show in 2019 that has stuck with me ever since.

Or maybe, and this is the most common one in my experience, there's simply a manager who has been asked to sanction a piece of work with real risk, no customer-visible outcome, and a completion date that nobody can honestly commit to. And they said no. And they weren't being unreasonable.

Now. Look at that list.

Look at how many of those are engineering problems.

Procurement isn't an engineering problem. Compliance sign-off isn't an engineering problem. A vendor's support matrix isn't an engineering problem. A licensing renewal cycle isn't an engineering problem. A data centre refresh isn't an engineering problem.

Almost every one of them is somebody else's decision, taken for reasons that were probably sound at the time, in a part of the business you have never been invited into. And then the consequence of that decision lands on your desk, and gets described as technical debt, and the person sitting at that desk gets described as being behind.

I'll go further, and this is the thing I most want you to take away from this episode: in a lot of organisations, what's actually happening is that a developer is being handed somebody else's budget problem and then judged for not having solved it with code.

You cannot refactor a procurement cycle. Nobody has ever fixed a licensing dispute with a well-placed interface.

### The Thing I've Said Three Times and Never Acted On

Now I need to tell you something slightly embarrassing, because it's the honest origin of this series and because I think it makes the rest of it more credible rather than less.

When I started planning these episodes, I went back through the archive looking for material. And I found something I wasn't expecting: I have been circling this exact idea, on this exact show, for seven years, and I never once did anything with it.

Here's the first one. April 2019, episode twenty four, talking with Iris Classon about migrating from ASP.NET to ASP.NET Core. We'd got onto the subject of how much time developers spend keeping up to date, and this is me:

> Because there's nothing wrong with being a 9-5 developer: Someone who turns up at nine works until it's time to go home.
>
> — Jamie Taylor, *[Episode 24 - Migrating from ASP.NET to ASP.NET Core with Iris Classon](https://dotnetcore.show/episode-24-migrating-from-asp-net-to-asp-net-core-with-iris-classon/)*



And Iris, to her enormous credit, immediately made it concrete rather than letting it stay a platitude. She told me about a colleague called Tobias, and her version of the point is a good deal better than mine was. Here she is:

> I had a colleague like that, Tobias... like one of the best developers I've worked with. And at five PM, he closes the lid on his laptop and he goes home... he probably would not open his laptop again, and I have tremendous respect for that.
>
> — Iris Classon, *[Episode 24 - Migrating from ASP.NET to ASP.NET Core with Iris Classon](https://dotnetcore.show/episode-24-migrating-from-asp-net-to-asp-net-core-with-iris-classon/)*



One of the best developers she had ever worked with. Lid down at five.

Right. Second one. February 2020, episode forty five, talking to Nick Craver about migrating Stack Overflow to .NET Core:

> I know a lot of .NET developers who are Windows and Microsoft stack all the way - and there's nothing wrong with that.
>
> — Jamie Taylor, *[Episode 45 - Migrating Stack Overflow to .NET Core with Nick Craver](https://dotnetcore.show/episode-45-migrating-stack-overflow-to-net-core-with-nick-craver/)*



Third one. Two weeks later. March 2020, episode forty six, this time with Bjarke Berg about migrating Umbraco:

> There's nothing wrong with that at all - if you've only worked with Windows, and that's fine.
>
> — Jamie Taylor, *[Episode 46 - Migrating Umbraco to .NET Core with Bjarke Berg](https://dotnetcore.show/episode-46-migrating-umbraco-to-net-core-with-bjarke-berg/)*



Three times. Fourteen months. Three completely different conversations, with three guests who had nothing to do with each other. And every single time, I reached for the same reassurance, unprompted, without anybody having asked me for it.

And then I did precisely nothing with it. For seven years.

I never built an episode on it. I never followed the thought anywhere. I said the comforting thing, and then I went straight back to talking about the new stuff, which is what this show is for and what I enjoy and what most of you come here for.

So I want to be straight with you about what this series actually is. It is not a new idea I've had. It's an old instinct I kept having and kept failing to act on, and I only noticed the pattern because I went looking through my own back catalogue for something else entirely.

### So Here's the Question

Which brings me to the question this episode exists to answer, and I'm going to answer it immediately rather than making you wait until the end, because I think you've been made to wait for this particular answer quite long enough.

The question is: is being on .NET Framework in 2026 a failure?

The answer is: No.

Now let me tell you why, using an idea that I did not come up with, from a guest who explained it better than I could.

### Ontological Humility

In January 2019, in episode eighteen, I spoke to Richard Campbell. If you don't know Richard, he's one of the two voices behind .NET Rocks, and he has forgotten more about the history of this platform than most of us will ever learn. That episode was about the history of .NET, and somewhere in the middle of it he said this:

> I lean heavily on this concept called ontological humility, which is: don't presume that the way you're thinking is the only way or the right way of thinking, and that new people who are going to look at your code in the future are going to think differently. If you can help them to understand what you've done, and if they have the humility to acknowledge that you did the best you could with the skills and knowledge you had at the time, knowing that later on there will always be new knowledge and you'll perceive things differently, then we respect the code that we wrote before and we sustain it, we find ways to maintain it. You just don't automatically look at any piece of code and say, this needs to be rewritten. If it works, even with its rough edges, it's still worthwhile.
>
> — Richard Campbell, *[Episode 18 - The History of .NET with Richard Campbell](https://dotnetcore.show/episode-18-the-history-of-net-with-richard-campbell/)*



Ontological humility. The term comes from a book called Conscious Business, and the short version is: don't assume you have a special claim on reality. Other people's perspectives are equally valid and deserve consideration. There are many ways to look at the world, and each one has bright spots and blind spots.

Richard said something else in that same episode that I think about a lot:

> Consistently, in all of my research, in everything I've seen, all of these people went to work each day trying to make a better product, trying to make a better world, and fought what they believed was a good fight. Their decisions were rational, even if it wasn't apparent that they were rational to the rest of the world.
>
> — Richard Campbell, *[Episode 18 - The History of .NET with Richard Campbell](https://dotnetcore.show/episode-18-the-history-of-net-with-richard-campbell/)*



Their decisions were rational, even if the rationality wasn't visible from outside.

Now. Every time I have heard ontological humility discussed since, including by me, it has been framed the same way: as generosity you extend to the developers who came before you. Be kind about the legacy code. Assume the person who wrote that class had reasons. Don't sneer at the past.

Which is good advice, and I stand by it.

But I think we've been aiming it in the wrong direction, and I want to try aiming it somewhere else.

Extend it to yourself.

The decision to build on .NET Framework in 2014 was, in 2014, correct. It was the mature, supported, well-documented, well-understood choice, with the biggest hiring pool and the best tooling, and the alternative was a beta with a shifting API surface and a project.json file that was about to be deleted from history. Anybody who chose Framework then was doing the best they could with the skills and knowledge and the information available at the time.

That's the standard Richard is describing. And the person it applies to is not some anonymous predecessor. Quite often, that person is you. It's you, five or eight or twelve years ago, making a good decision on good information, and then being asked to feel bad about it now by people applying knowledge that did not exist yet.

If you would extend that grace to a stranger whose code you inherited, you're allowed to extend it to yourself.

### Going Back Through the Tapes

Now I want to tell you about an aphorism, and about being wrong in public, which regular listeners will know is something of a recurring feature around here.

There's a line I've been using for years. It goes:

Existing code has infinitely more value than code which doesn't exist.

I like it a great deal. It's compact, it's true, and it does a lot of useful work in an argument about whether to rewrite something. I had every intention of making it the recurring line of this series.

The trouble is that I have credited it to two different people, on two different episodes, several years apart. So before I built a whole season on it, I went back through the transcripts to find out where it actually came from.

Here's what I found.

In February 2020, in episode forty five, I said it to Nick Craver. And the exact words I used were "like you said, existing code has infinitely more value than code which doesn't exist."

Like you said.

Nick had not said it. I checked the transcript twice. What Nick had actually said, about a minute earlier, was this:

> And you don't change a working thing unless there's a benefit to doing so, right? You know, what works. You know, you're the state you're in, you move to an unknown, it's an unknown: you could break things.
>
> — Nick Craver, *[Episode 45 - Migrating Stack Overflow to .NET Core with Nick Craver](https://dotnetcore.show/episode-45-migrating-stack-overflow-to-net-core-with-nick-craver/)*



Which is the same idea, and a very good statement of it, but it isn't the line.

Then, years later, in season eight, episode seven, talking to Hayden Barnes, I used the line again and this time credited it to Richard Campbell.

So which is it?

It's Richard. Thirteen months before that conversation with Nick, in episode eighteen, immediately after that ontological humility passage you heard a few minutes ago, Richard said this:

> Well, code that already exists is automatically more valuable than code in your head, because the code that already exists does something. The code in your head is really just noise.
>
> — Richard Campbell, *[Episode 18 - The History of .NET with Richard Campbell](https://dotnetcore.show/episode-18-the-history-of-net-with-richard-campbell/)*



The code in your head is really just noise.

So there it is. The idea is Richard Campbell's, from January 2019. What I did was compress it into something shorter and sharper, and then carry that compression around for seven years while attributing it to whoever I happened to be talking to.

I'm telling you this for two reasons.

The first is straightforward: it's Richard's idea, he should get the credit, and I'd rather correct it here at the start of a series than have it quietly propagate through six more episodes.

The second reason matters more. This entire season is going to ask you to do something quite demanding. It's going to ask you to look at a codebase somebody else wrote, under constraints you weren't there for, and assume good faith and sound reasoning before you assume incompetence. To go and find out why, before deciding what.

I could hardly ask you to do that with a decade-old codebase if I wasn't willing to do it with my own back catalogue.

So: the idea is Richard's. The compression is mine. And I went and checked before I built a season on it.

### The ISO 9001 Story

Let me give you a concrete example of constraint being structural rather than personal, because I've been fairly abstract for a while now and this one is a genuine favourite of mine.

Back in episode forty five, Nick Craver and I got talking about Jon Skeet. If you've ever searched for a C# question, you've read a Jon Skeet answer; he has sat at or near the top of the Stack Overflow reputation leaderboard for most of that site's existence.

There's a widely held assumption that Stack Overflow made Jon Skeet famous. Nick's position was that this has it exactly backwards: Skeet was answering questions on message boards and forums long before Stack Overflow existed, and the site simply gave him a bigger surface.

And then, almost in passing, Nick mentioned that he himself had been one of the top users on the site before Stack Overflow hired him. Which raises an obvious question: how does anybody find the time?

> I was in a job that was ISO 9001. If anyone's not familiar with that, it's red tape, a lot of it to do any changes, everything is validated. And so you have a lot of spare time as a developer, because you can't fix or refactor anything without a whole bunch of BS happening. So Jon's and I were like the top users on the site for about a year there.
>
> — Nick Craver, *[Episode 45 - Migrating Stack Overflow to .NET Core with Nick Craver](https://dotnetcore.show/episode-45-migrating-stack-overflow-to-net-core-with-nick-craver/)*



I love this story, and I want to be clear about why.

Nick Craver is, by any reasonable measure, one of the finest infrastructure engineers of his generation. He went on to run the systems behind one of the busiest websites on the planet. And at one point in his career, a quality-management process left him with so little to do that he filled the gap by becoming one of the most prolific contributors on Stack Overflow, alongside Jon Skeet.

Not because he lacked drive. Not because he wasn't curious. Because he could not fix or refactor anything without a whole bunch of paperwork happening first.

That's what a structural constraint looks like. It doesn't announce itself. It doesn't show up in a performance review as "the process prevented this person from doing their job." From the outside it just looks like output, or the absence of it.

And if it can happen to Nick Craver, I'd gently suggest that when it happens to you, the explanation probably isn't that you personally didn't try hard enough.

### Nobody Wants to Feel Left Behind

Two more from Richard Campbell, and then I'll bring this in to land.

The first is about that no-open-source policy I mentioned earlier. This is January 2019, and remember that at this point .NET Core is three years old and Richard is out there talking to companies constantly:

> I'm still meeting companies on a routine basis where their company policy is no open source code. That's not an option, so they have not looked at Core at all.
>
> — Richard Campbell, *[Episode 18 - The History of .NET with Richard Campbell](https://dotnetcore.show/episode-18-the-history-of-net-with-richard-campbell/)*



They have not looked at Core at all. Not because they evaluated it and found it wanting. Because a policy written by somebody in legal or risk, quite possibly years before, closed the door before any engineer got near it.

And then, a little later in the same conversation, this:

> I don't think anybody wants to feel, quote unquote, left behind.
>
> — Richard Campbell, *[Episode 18 - The History of .NET with Richard Campbell](https://dotnetcore.show/episode-18-the-history-of-net-with-richard-campbell/)*



That was said in January 2019, about .NET Core, by a person who had every commercial and community incentive in the world to be a wholehearted advocate for the new thing.

Seven and a half years later, I think it's still the most accurate sentence anybody has said on this show about why this whole conversation is so difficult.

Because that's the actual barrier. It was never really the runtime, or the tooling, or the breaking changes. It's that a very large number of skilled, experienced developers have spent the best part of a decade being made to feel like they're standing on the wrong side of a line that somebody else drew, using criteria they never agreed to, measuring something they were never in a position to control.

### The Contract

So let me set out what this series is going to do, and what it isn't. Four commitments, and I'd like you to hold me to all of them.

1. Nothing in this series will tell you that you should have upgraded by now. That ship has sailed, the question is uninteresting, and the answer would change nothing about your Monday morning.
1. Nothing in this series is selling you anything. No course, no book, no consultancy pitch, no sponsor whose product happens to be the answer. Which is why I told you at the top who signs my payslip.
1. At least twice this season, the segment at the end of the episode is going to conclude that your manager is right and the answer is no. I'm committing to that now, in public, because if it never happened you'd be entitled to assume the other four segments were rigged.
1. The destination is a version of .NET you can stand still on. Not the newest one. If the right answer for your organisation is a supported version that you then leave alone for five years, this series will help you get there and will not sneer at you for stopping.

And one thing I'd ask in return.

If I get your constraints wrong, tell me. The entire premise here is that the reasons you're on Framework are real, specific, and largely invisible from outside your organisation, which means that by definition I can't guess all of them from a microphone in West Yorkshire. If I describe a situation that isn't yours, or miss one that is, get in touch. There's a contact page, there's a Discord, and both are linked in the show notes.

### Taking It Upstairs

Right. Before I let you go, it's time for the part of the show that's going to close out every episode in this series. I'm calling it Taking It Upstairs.

The idea is simple. Most of you can't authorise this work. You can only make the case for it to somebody who can. So every episode is going to end with one specific, practical piece of that case, tied to whatever that episode was about, and there'll be a short written version in the show notes in business language so you can forward it to somebody without having to translate it first.

But we're going to start by doing it backwards.

Because before you make a case to anybody, you need to know what they're actually worried about. And in my experience, developers consistently answer the wrong objection, at length, with great technical precision, to somebody who was never asking a technical question.

So here are four things I'd suggest your manager is genuinely worried about.

The first is that the operational risk lands on them, not on you. If a change to a working revenue system takes production down at three in the afternoon, you explain it to your manager, and then your manager explains it to their director, and possibly to a customer. You carry the technical work. They carry the incident. That asymmetry is usually the whole objection, and it is very rarely stated out loud.

The second one is harder to argue with. This work produces nothing anybody outside engineering can see. At the end of a successful migration, the software does exactly what it did before. Your manager has to go into a quarterly review, having spent budget and delivery capacity, and show a slide that says "it still works." Try to imagine giving that presentation and you'll understand the hesitation.

Third is the fear of a half-finished migration. Almost every experienced manager has seen one. Two stacks in production, two sets of skills to hire for, twice the maintenance, no completion date, and the enthusiastic person who started it has since moved to another company. In their head, that outcome is worse than never starting, and honestly, they're right.

And the last one is the set of costs you can't see from where you sit. Re-certification. Re-accreditation. A fresh penetration test. An insurance question. A vendor support matrix that no longer covers the version you want to move to. You are costing the code. Your manager is costing all the paperwork wrapped around the code, and in a regulated environment that paperwork can be the larger number by some margin.

Now look at those four again.

Not one of them is a technical objection.

So when your manager says no and you respond with benchmark figures, or the performance improvements in the new runtime, or how much cleaner the dependency injection story is, you're answering a question nobody asked. And the reason the conversation goes nowhere isn't that your argument was weak. It's that you were arguing with somebody else's argument.

So here's the ask for this episode, and it's deliberately tiny.

Don't make the case. Not yet.

Just find out which of those four you're actually talking to. One conversation, no slide deck, no proposal. Ask what would have to be true for this to be worth the risk, and then listen to which of the four fears comes out.

That needs no budget and no approval, and it changes nothing in the codebase. Without it, though, you cannot build a useful argument in any of the next five episodes.

The honest caveat: this will not get you a yes. It isn't supposed to. What it gets you is the ability to stop wasting your credibility answering questions nobody asked, which is a limited resource and one you'll want later.

### Call to Action and Close

So. Where does that leave us.

You are not behind. You are constrained. The constraints are real, most of them were decided by other people, and quite a lot of them are not engineering problems at all.

And the line this season is going to keep coming back to, which belongs to Richard Campbell and which I have finally got round to attributing properly, is that code which already exists is automatically more valuable than code in your head. Because the code that already exists does something.

That application you maintain does something. It has done it every working day for years. That is not nothing, and it is not a failure, and I'd quite like this to be the season where somebody says so on a .NET podcast.

Next time in this series, we're going to look at the case for not upgrading at all, which I've deliberately put second rather than last, and which includes the story of one of the most respected engineering organisations on the planet looking at a newer version of .NET Framework and deciding, on purpose, not to move to it.

If this episode landed, share it with the person on your team who's gone quiet in the modernisation conversations. Chances are they went quiet for a reason.

And one specific ask. Later in this series I want to talk to people who are actually living this: somebody in an NHS trust, a local council, an insurer, a manufacturer. Not people with something to sell, just people with a Framework application and a set of constraints. Anonymised, if your employer needs it to be. If that's you, the contact page is in the show notes and I would genuinely love to hear from you.

Thank you for listening. Be kind to yourselves, be kind to each other. I'll see you in the next one.

## Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. Let me know if you found this monologue interesting or useful. I'd love to know if you did, and whether you'd like me to create more of them.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at [the podcast's website](https://dotnetcore.show/), and there will be a link directly to them in your podcatcher.

And don't forget to spread the word, leave a rating or review on your podcatcher of choice—head over to [dotnetcore.show/review](https://dotnetcore.show/review) for ways to do that—reach out via our [contact page](https://dotnetcore.show/contact), or join our discord server at [dotnetcore.show/discord](https://dotnetcore.show/discord)—all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I'll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

## Useful Links

- This series
  - [Bridging the Gap: Taking It Upstairs](https://dotnetcore.show/bridging-the-gap/), every episode's business case on one page
- Episodes referenced in this one
  - [Episode 18 - The History of .NET with Richard Campbell](https://dotnetcore.show/episode-18-the-history-of-net-with-richard-campbell/)
  - [Episode 24 - Migrating from ASP.NET to ASP.NET Core with Iris Classon](https://dotnetcore.show/episode-24-migrating-from-asp-net-to-asp-net-core-with-iris-classon/)
  - [Episode 45 - Migrating Stack Overflow to .NET Core with Nick Craver](https://dotnetcore.show/episode-45-migrating-stack-overflow-to-net-core-with-nick-craver/)
  - [Episode 46 - Migrating Umbraco to .NET Core with Bjarke Berg](https://dotnetcore.show/episode-46-migrating-umbraco-to-net-core-with-bjarke-berg/)
  - [S08E07 - Hayden Barnes on .NET NES: Why We Need a New Approach to Open Source Maintenance](https://dotnetcore.show/season-8/hayden-barnes-on-net-nes-why-we-need-a-new-approach-to-open-source-maintenance/)
- Referenced in the episode
  - [Conscious Business: How to Build Value Through Values](https://www.goodreads.com/book/show/1169674.Conscious_Business), the source of the ontological humility definition
  - [.NET Rocks](https://www.dotnetrocks.com/)
  - [.NET Framework lifecycle policy](https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework)
- Supporting the show:
  - [Leave a rating or review](https://dotnetcore.show/review/)
  - [Buy the show a coffee](https://www.buymeacoffee.com/dotnetcoreshow)
  - [Become a patron](https://www.patreon.com/bePatron?u=13876270)
- Getting in touch:
  - [via the contact page](https://dotnetcore.show/contact)
  - [joining the Discord](https://dotnetcore.show/discord)
- Music created by [Mono Memory Music](https://monomemory.bandcamp.com/), licensed to RJJ Software for use in The Modern .NET Show
- Editing and post-production services for this episode were provided by [MB Podcast Services](https://www.mbpod.com/?utm_source=mdns&utm_medium=podcast&utm_campaign=MDNS-s09e01)