You may have decided to skip .NET 5. You may realize you have deprecated .NET applications like Web Forms that you’ll just maintain until their end of life. Even if you’ve decided that your inevitable .NET 5+ migration can wait (which it can!), now is the right time to start the research process.
Doing the research and planning your .NET 5+ migration ahead of time will save significant headaches down the road.
Jump to the Research Roadmap Checklist
Hurry the Planning, Not the Migration
Microsoft has declared that .NET 5+ is the only path forward, where before there were at least four different types of .NET. Microsoft plans to release a major version every November, with only even-numbered .NET versions after 5 (6, 8, etc.) containing long-term support, AND some popular .NET Framework features (Web Forms, WF, and WCF) are deprecated.
The good thing is that these aren’t immediate changes that have an instant impact on your code. Your deprecated apps, for example, will stay “alive” until their Operating System reaches end-of-life.
But don’t delay the planning process. .NET 5 is significantly different from .NET Framework and rushing to migrate when your Framework applications are about to reach EOL is the wrong time to be making decisions. Starting now means less work over a longer time and avoiding the mad rush of last-minute plans.
Tips for Researching Your .NET 5 Roadmap
There are certainly more, but we here offer four tips for researching your .NET 5+ roadmap.
1. Embrace your unique situation.
If you’re like us, you have a mix of different .NET platforms at work in your organization. This is not only fine, but it’s also normal. But that does mean that, unfortunately, there is no single correct, effective way to migrate to .NET 5+. The best migration for your organization depends entirely on the innards of your organization.
For example, .NET Framework provided a lot of great stuff to teams in their lifetime. The biggest problem is that .NET Framework applications tend to run their roots entirely through the .NET Framework itself. In most cases, this makes it impossible to make an easy switch. Even two organizations with a lot of .NET Framework applications will have different journeys from each other because of:
- staffing considerations
- application size
- application age
- application importance to daily business
- whether that application has tools to help you port
- and more!
Reading about other people’s migrations can be helpful, but remember that each migration will be unique.
2. Know what NOT to read.
This tip is a two-parter.
Part 1: Be suspicious of one-size-fits-all. As I explained in Tip 1, every organization and every application within that organization is unique. Anyone offering an easy transition that will work for everyone warrants a side-eye.
Part 2: Take care with “the Source.” Something I’ve learned being a non-developer writing about development stuff is what NOT to read. Unless you are a total .NET nerd, going straight to the Microsoft documentation may hurt you more than help. It’s really, really technical stuff. I wasted an hour trying to understand the transition from Web Forms to Blazor before concluding that “plain English” is easier than “developer English.” Thankfully, we got you covered. I wrote most of our guide, and if I myself couldn’t understand what our developers were trying to say, it didn’t go to press.
3. Assess your migration difficulty NOW.
If I ask you to help me move to my new home, you might be too polite to ask your first question: How tough will this be? Moving me from one studio apartment to another just a street away will be much easier than moving me from one mansion to another one in a totally different state.
This is the same question (“How tough will this be?”) you should ask of your code and applications affected by .NET 5. Every organization will be different (see Tip 1), but it makes sense that more applications with more deprecated technologies will require more care and planning than smaller situations already on .NET Core (for example).
We created a migration difficulty scorecard to help you with this tip. Doing this now will help you decide how early you need to begin the planning process and how detailed that process will be.
4. This won’t be “one and done.”
This .NET 5 migration process—and indeed the entire planning process—may take place over several years. This definitely requires multiple conversations, status checks, and reassessments.
Help your future self out by setting the intervals of these check-ins now with other decision-makers. And when preparing for these future conversations, consider how new tools or technologies or changes in staff or existing applications may have changed your migration plans.
Research Roadmap Checklist
We recommend five stages of planning for .NET 5+ migrations, so we created this research roadmap checklist to help you along the way.
|Inventory Your Existing Applications|
☐ What .NET platform(s) does each application use?
☐ Are these .NET platforms LTS, STS, or already out-of-support?
☐ How business-critical is each application?
☐ Take note .NET Framework technologies in use: WCF, Web Forms, WF, WPF, and WinForms
Assess Deprecated Components
☐ Rank deprecated components by priority
☐ Does the deprecated component have a direct-port tool to the new .NET or will it be a total rewrite?
Prioritize with Stakeholders
☐ Discuss difficulties honestly, including non-technical challenges
☐ Plan for follow-up conversations
☐ Discuss alternatives to migration to .NET 5+
Prepare a Rough Migration Schedule
☐ Research new platforms
☐ Discuss options with colleagues and stakeholders
☐ Consider reasons to delay or lengthen migration times
Increase Your Release Velocity
☐ Assess how you’re currently releasing, especially .NET Framework apps
☐ Experiment with breaking large projects into smaller releases
☐ Download free CI/CD tools like BuildMaster to practice using automation
The .NET 5+ Migration Guide: Your Research Guide
We’ve built a guide specifically to help you organize your thoughts, plan your migration, and execute your plan when the time comes—and how to keep your non-migrating applications healthy for longer.