At the beginning of our series of .NET5+ migration articles, we outlined a five-step migration planning process. Now that we are in the lifecycle for .NET5+ (.NET 5 to .NET 8), more organizations may be looking to seriously start this process for themselves. We figured now would be an appropriate time to cover that process in more detail.

In this article, we share our recommended five steps for planning a .NET5 + migration:

1. Inventory your existing applications
2. Assess depreciated components
3. Prioritize with stakeholders
4. Prepare a rough migration schedule
5. Increase your release velocity

1. Inventory Your Existing Applications

This should be the easiest step of the process, but the results will greatly affect your migration. To begin your migration process, simply investigate what .NET technologies make up your applications.

Specifically, pay attention to the .NET Framework technologies that make up your applications. There are five main technologies to look out for:

• Windows Presentation Framework: WPF was brought into .NET5+. The difficulty of migrating your own WPF application into .NET5+ ranges from trivially easy to exceedingly difficult.
• WinForms: WinForms was brought into .NET5+ as well. But like WPF, WinForms applications may be difficult to migrate anyway.
• Windows Communication Framework: WCF was not brought into .NET5+ and will require a rewrite for any .NET5+ migration. Compared to other .NET Framework technologies though, WCF has viable alternative platforms and an easier rewrite.
• ASP.NET Web Forms: Web Forms was not brought into .NET5+ and will require a rewrite for any .NET 5+ migration. The most popular target platforms for Web Forms rewrites are MVC and Blazor.
• Windows Workflow Foundation: WF was not brought into .NET5+ and any application built with WF will require an extensive rewrite for .NET5+ migration. Finding the right alternative is not an easy task and the result will vary for each organization.

A quick chat with your development teams will reveal the .NET platforms in use at your organization. Make sure to know the major .NET platforms for your application so you can discuss the project in depth with stakeholders.

2. Assess Depreciated Components

You probably don’t know every component of your application. But a single depreciated component can make a migration complicated. Finding and reviewing each component is integral for judging your migration’s feasibility.

By “component,” we mean any depreciated platforms, NuGet library, or other API used in the application. It is possible that your team doesn’t know the status of every component. That can be solved by looking through the code by hand and doing research on each component. Or you can use some tools to aid you. Either way, at the end of this process:

• You should know every depreciated component. Ideally, have a list or spreadsheet that clearly names each component and its priority for the application. Ranking them by priority can help in making decisions later in the process.
• You should know the target platform for most of the depreciated components. It may be simply updating the component to a .NET5+ compatible version, or you may need to find a new solution entirely. But for your most important components, make sure you have target replacements in mind in case you need to discuss them with stakeholders in the next step.
• You should know the tools used to develop the application. IDEs, log viewers, and other software used to develop applications are not considered components but should be audited during this step as well. Not only will it let you know if you need to replace any tool, but it can also help guide which new platforms you target.

Once you have audited your depreciated components carefully, you will have the knowledge necessary for an effective discussion with other stakeholders.

3. Prioritize with Stakeholders

At this point in the process, you and other project stakeholders need to decide whether migrating to .NET5+ will be worth the challenge. Thanks to the information you collected during the previous two steps, you can appropriately discuss how difficult the migration may be for your organization.

When presenting your research to other stakeholders, try to keep these things in mind:

• Be honest about the difficulty. It can be tempting to downplay the difficulty because you trust your team. Or you may be tempted to oversell the difficulty to give your team more time. But now is not the time to appeal to ego or try and set the schedule. The goal of this conversation is to try and make the best decision for the business’s future. To do so, you must accurately present your research.
• Consider non-technical challenges. The research you completed in the previous steps only judged the technical difficulty, not the organizational difficulty. Other projects, budget constraints, and staff size also need to be discussed.
• This doesn’t need to be the only conversation on migration. This process may require more than one conversation and take place over several years. That’s okay. Revisiting this conversation in a year or so might be the best decision you can make. There are reasons you would want to wait, such as a different version of .NET. Just be sure to reassess the difficulty when preparing for future conversations as new tools or technologies may change the migration process drastically.
• Migration is not the only possibility to discuss. It’s possible that stakeholders have a different idea of the future of the application. If the current application does not align with the goals of the business, it is possible the best solution is a full redesign rather than a migration. Or maybe the effort involved in migration is too much to take on at the time and it would make more sense to start planning to stay on .NET Framework long term.

Remember that the goal is not to migrate to .NET5+. The real goal is to prepare your organization for the best future possible. If that means delaying migration or preparing applications that will never migrate at all, remember that .NET Framework will continue to receive security updates and bug fixes for as long as it is part of the Windows operating system.

Whether you decide to migrate to .NET5+ or to prepare your non-migrating applications for the long haul, it is time to set up a schedule.

4. Prepare a Rough Migration Schedule

The research you have done on your applications and the discussion(s) you have had with stakeholders should prepare you to make a rough schedule.

How you schedule the migration for each application will depend on the migration difficulty and many other factors decided by the stakeholders. A more challenging migration will generally take more time than a relatively easy one.

But there are other factors to consider:

• Do you know your target platforms yet? It’s possible you still haven’t decided on the best target platforms for each component in your application yet. That’s fine, but add time to your schedule to research new platforms and discuss the options with the other stakeholders.
• Are you familiar with the technologies? Depending on your familiarity with either the .NET Framework technology you currently use or the new target platform, you may want to be more conservative on rough deadlines or even set up a dedicated time for training and prototyping.
• How far did you get in the previous steps? If you already used tools like Try-convert and Visual ReCode, you may have already made considerable progress on your project migration. Let that be a factor in how you set the schedule.
• Are there non-technical reasons to delay the process? Balancing the migration with other high-priority projects should be kept in mind while creating the schedule. Consider other factors, such as how many people can dedicate time to the project or budgetary concerns.

Even a rough schedule is challenging, but there is no technical or business reason to rush. Unless you’ve been on an out-of-support .NET platform for years already, the application as-is will work for a long time on .NET Framework, so prioritize a smooth migration over a fast one.

There may be a lot of time between steps four and five, but step five is essential to keeping up with the speed of business in the 2020s.

5. Increase Your Release Velocity

No, you can’t just “go faster.” But you can make your updates smaller and automate parts of the release process—even for legacy applications that you never migrate to .NET5+. Fast release velocity and automated deployments decrease migration difficulty and are good practices for .NET5+ because they:

• Focus on smaller releases. Breaking the project into smaller releases helps teams focus by providing more specific goals. For example, small releases can focus on updating a few dependencies at a time instead of porting a whole .NET Framework technology. This way, you both make progress on your migration while making your product better for current users.
• Automate more to worry less. Any part of your release process that is automated is one less step you need to worry about during the migration. This ensures that you can focus more on solving problems during migration and less on configuring a release.
• Can help with team morale. There’s a psychological advantage to an increased release velocity. Releasing new versions of your application will come with a sense of accomplishment, and that can go a long way for a team in the middle of a difficult migration process.

It’s important to consider release velocity when trying to make a project less difficult. Don’t make the project harder by forcing it into one giant release.

Set Yourself Up for Success with a Strong Plan

The .NET5+ migration is challenging. We have written extensively about the challenges you will face, from the situation with Web Forms, to considering new deployment options, and even the new opportunities for supported platforms like WPF. But the best way to overcome these challenges is to know which ones apply to your organization, know your options for how to approach those challenges, and discuss those options honestly with your organization. By taking ample time to plan, you significantly increase your odds of success.

We’ve built a guide to help you successfully navigate the migration to .NET 8 and beyond. Get your copy today!