Now that we are a few years into .NET Core I am seeing more organizations start to look at the big picture and decide if they want to migrate to .NET Core, or are evaluating .NET Core for consideration on new projects. Over the past few years, I've given multiple talks at conferences with the title "Should I Transition to .NET Core? Will It Hurt?" This talk has been very popular so I thought I'd share a bit of context that you cannot get with the slides to help you better understand what might make the best sense for your organization/project.
A Bit of Background
Unlike some of the other posts that I make, this conversation is 100% opinion & experience-based. Microsoft has a set of help documentation on Migrating from ASP.NET to ASP.NET Core However if you review that documentation you might not have a solid understanding of exactly the level of effort would be to make the transition.
At this point in time, I have personally worked to migrate more than a dozen projects myself from either ASP.NET WebForms or ASP.NET MVC to ASP.NET Core. I've also done this migration across various versions of ASP.NET Core starting with 1.0. Having completed multiple projects, and now maintained those projects through a number of releases of .NET Core I have a much better understanding of the long-term impacts of the transition in addition to the upfront migration costs.
Why Migrate
I think it is important to understand WHY you might want to migrate to ASP.NET Core before we talk about the specifics of the cost, or approach to doing so. In my experience, the developer experience with .NET Core is easier than prior editions, but overall we can group things into a few small buckets for key advantages.
- Performance - Overall performance of the platform is far superior to that of the older frameworks. However, issues have been logged about static file performance for heavily trafficked sites that you might want to be aware of
- Cross-Platform - This becomes a possibility, it isn't a requirement
- Deployment Processes - I find that the ability to publish a .NET Core application self-contained with everything that you need results in a much nicer experience when deploying
- Dependency Injection - Native support for Dependency Injection makes development patterns much easier to implement. I've found it has been much easier to train my team, and customer teams on the concepts of Dependency Injection and unit testing in the .NET Core world.
There are many other differences and improvements that exist and each organization will have different things that are of value to their organization. Microsoft has a detailed set of overview documentation for .NET Core.
Why Might you Not Migrate
As much as I love working with .NET Core I cannot say that we are at a perfect state by any means. Things are changing rapidly in .NET Core land, and as part of that rapid change as developers embracing this new platform, it is important that you keep up with the change. In fact, I recently blogged about .NET Core 2.1 Upgrade You Must after Microsoft adjusted the support lifecycle for .NET Core 2.0 making an upgrade to 2.1 mandatory for everyone by October of this year to stay on a supported platform.
Based on my experience the following situations or thoughts might cause someone to give pause to upgrading.
- Not All Libraries are .NET Core - When migrating to .NET Core I strongly recommend just running full .NET Core, however, doing this might result in certain libraries being unavailable to you so this could restrict a migration
- Upgrade Cycles & Commitment - .NET Core is changing fast, Microsoft is doing a great job providing documentation on what needs to change with upgrades but there are changes necessary in most of the upgrades and keeping current is going to be important. This will place a developer burden on a team and could be a detractor to upgrading
- Sheer Level of Effort - If you are a Web Forms developer there is no automated, systematic, or fast way to migrate. This level of effort is something that can easily keep developers back.
There are mitigations and workarounds for many of these concerns. However, the bottom line at least as of today, Microsoft is still supporting the existing .NET Platform and the end of support for the .NET Framework is tied to the OS that it runs on. This means at a minimum on Windows Server 2016 we are stable until 1/11/2027!
How to Migrate
Every project will be different than another to migrate, however, the process is similar depending on the type of project that you started with.
Migrate From ASP.NET MVC
This migration is really the easiest migration to complete. The Microsoft documentation has a detailed guide as to how you complete the migration. But at a high level, we can break it down into a simple and systematic process.
- Create a new .NET Core project
- Migrate/convert startup & initialization
- Migrate static content & bundle configurations
- Migrate views & actions
This process is most easily accomplished by having two instances of Visual Studio open with mostly simple copy-paste operations to migrate much of the content, changing the needed items as you go file-by-file. Some people try to automate this process, I find that the benefits of manual review as you go, outweigh the small time savings of an automated solution due to the amount of review needed after the fact.
I followed this process to migrate our SaaS solution FlightFiles to .NET Core and was 100% completed in less than 80 hours, on a project that at the time had more than 1,100 hours of development effort to date. It is a very tedious process, and your adherence to standards will make things easier.
Migrate from WebForms
If you look at all of the amazing documentation provided by Microsoft you might be surprised to see that there is no migration path provided for WebForms developers. This isn't a typo or an oversight, it is an important fact to remember as a developer. The System.Web namespace dependencies that contain all of the WebForms functionality isn't there in .NET Core and at this point, there haven't been any public suggestions.
What this means for a developer with WebForms is that this isn't a "Migration" but a "Port." In fact, there is a blog from a Microsoft Team Member talking about the porting process. The scope and level of effort to make this change is massive and should be considered a true re-implementation as the development paradigms are just not the same.
Mitigate Risk
If you are a web forms developer today, how might you limit the future pain if you are unable to migrate to .NET Core today, but want to try and make it easier to get there in the future? Well there are a number of ways that you can change development paradigms to help make the transition easier.
- Implement MVVM/Model Binding - New features in .NET Framework support model binding for web forms. This is closer related to the MVC way of doing things and can help lower the burden of migration in the future.
- Leveraging APIs & Client-Side Development - Applications built using more API's and rich-client development such as Angular or React will have fewer dependencies on WebForms and be easier to transition
- Consider Creating .NET Standard Libraries - A .NET Standard Library can be used by both Full Framework & .NET Core. This allows developers to know that the code written inside of that library can work on both frameworks, helping to move logic to re-usable components
It should be noted though that even with the best planning, there is NOT an automatic method to get from WebForms => .NET Core. There WILL be breaking changes and things that must be re-written. This is an absolute at the current time.
Should You Migrate or Use .NET Core
This is the loaded question of the day. It is my opinion that .NET core is the way of the future. I'll break it down by project type.
New Projects
This is the easiest one to answer. My opinion, if possible, all new projects should just start out on .NET Core, unless you have a very compelling reason to not do it there. Such as library restriction etc. The benefits to code quality, efficiency, and future growth are there.
Just be sure to validate your project dependencies as early as possible to ensure that you are not limited by the supported features.
Existing MVC Projects
For these, we are working to migrate them when we have time available in the project lifecycle to take a quick step back. We are treating this migration as a time to complete detailed regression testing and often link the migration effort up with a facelift or other bigger feature addition to ensure that all individuals benefit from the upgrade.
Existing WebForms Projects
At this stage of the game, it really depends on how big and complex your application is. If it is a simple ASP.NET WebForms solution that you can migrate without a ton of effort it would be great to migrate as soon as practical. However, if you are working on a very large project we just don't see the full value in moving yet.
Rather than moving the large projects, we focus on cleaning the infrastructure. Working to make as much of the code .NET Standard compatible in an effort to make the eventual transition.
Summary
.NET Core is an amazing technology, but it is more of a cutting/leading-edge solution at this time. It takes dedication and time to migrate, and stay current, but can have great gains in the end. I hope this has been helpful. Through my consulting business IowaComputerGurus we do a large amount of consulting in this area as well and can be available for more detailed questions that might not be easily answered with a comment to this post.