In this article, we share our thoughts on moving from .NET Framework to .NET, based on our experience of helping businesses in MedTech and other industries to handle such migrations.
Briefly, let’s get the terminology clear: .NET Framework is the typical system that businesses might be using now running on their legacy Windows environments. The new system they might migrate to is named .NET (formerly known as .NET Core) which can run anywhere on any OS (yes, even Mac).
Which businesses use .NET Framework?
.NET Framework is most commonly used by businesses and organisations that tend to be focused on compliance, that are heavily regulated or that may otherwise be restricted in terms of their flexibility, such as when there are very slow release cycles. They may have had their current systems running on Windows for many years and hence .NET Framework is the only choice, or a legacy of choices made over a decade ago.
Healthcare, banking and government agencies are often where .NET Framework systems are found.
Such organisations are increasingly making the move from .NET Framework to .NET. So, why is that?
Common reasons why businesses migrate from .NET Framework to .NET
Unsurprisingly, the biggest reason why a .NET migration might take place is either to help a business make direct cost savings or to boost revenue by helping the business become more competitive.
A recent migration for a MedTech client is a case in point. Their current release cycle on .NET Framework allowed them to do at most one release per year. But with a move to .NET they could adopt a containerised architecture that makes it easy to do multiple releases per year, thereby making them more competitive and flexible.
The client would adopt a leaner infrastructure with no reliance on large hardware purchases, saving them significant amounts each year.
With up to 100 deployment sites in their estate, and a potential saving of several hundred thousand pounds per site per year on the new platform, the client stood to save tens of millions of pounds each year directly due to this migration.
Cost savings alone aren’t the only drivers for a .NET migration to take place. Here are some others:
Modernisation: Many businesses want to move to .NET due to a need for modernisation. Often, this will be part of a wider-scale revamp of their systems. For example, a business may have several legacy frameworks, some or all of which are reaching end of life for support. This represents an opportunity for the business to switch to a modern platform rather than trying to maintain an outdated and unsupported setup.
Platform agnostic: While .NET Framework ties businesses to using Microsoft Windows, a move to .NET would break these ties, providing a flexible setup that could run on just about any other system and that could scale to meet demand. .NET isn’t the only system that can offer this, but it represents a significant move forward when compared with .NET Framework. If your code is built on .NET Framework, .NET is the simplest migration path.
New approach: An organisation might get a new CTO or CIO who wants to shake things up by overhauling their teams’ skillsets and their tech stack. This could be due to their approach to tech in general or it might be motivated by the need to achieve corporate goals related to streamlining or cost savings.
Maintenance: Newer technology such as .NET tends to be easier to maintain, and in a workforce that keeps its skills up to date, it should be easier to find the people to do the maintenance rather than relying on those with legacy skills.
When should you NOT migrate to .NET?
Migrating from .NET Framework to .NET isn’t always right for a business, though it’s usually a case of “not right now” rather than “never”, as a move generally offers a host of benefits.
No need to change the status quo: Your existing platform may be fit for purpose and have no end of support issues looming, in which case nothing needs to change. (Given that you’re reading this article, you’re probably not in that boat.)
Dependencies: External libraries might not have been ported to their new .NET equivalents yet, so you might need to stick with .NET Framework rather than making a move and (at least temporarily) losing some functionality you used to rely on.
Compliance: Internal compliance issues may prevent a move, such as if you have no robust processes to support new technologies or platforms.
Complexity: Your existing codebase might well be old and hard to port, or perhaps your code may be in such a mess that it’s difficult to understand and rewrite. In this case, it might not make financial sense to invest in a migration now. It may be easier to take time to redefine your requirements and build from these rather than just moving your existing code.
Fuzzy requirements: Migration for migration’s sake tends to be a costly waste of time, so it’s important that you hold off any plans to move forward until you have a clear set of requirements for what you want and need.
Alternatives: .NET isn’t the only game in town, and you might be better suited to moving to an alternative option in the cloud. The flexibility of .NET is excellent but may not be needed if you already have a clear long-term strategy that’s based on Microsoft Azure (that could still be .NET anyway) or some other serverless technologies.
Skills: A migration doesn’t end with the flick of a switch: you still need to be able to maintain and support the new system (as well as keeping the old one going for a while). If you don’t have access to the skills needed to do this maintenance, you may not be ready to do the migration yet. Yes, the skills could be brought aboard by hiring the right people or outsourcing the tasks, but this needs to be part of the plan rather than an afterthought.
Migration milestones
Let’s say you’re committed to making a move from .NET Framework to .NET. What should you look out for as the key indicators of progress?
These will depend on the project at hand but for bigger migrations, we tend to look for 3 main milestones:
- Deploying a new infrastructure: Whether on premises or in cloud, the creation of a new platform with a reproducible, scalable environment on which everything else will be built is the first milestone.
- Deploying first logic: With the new infrastructure in place, the first time that new logic is deployed such that old and new systems are running side by side is the next milestone.
- Final switchover: After what might be a long series of piecemeal additions, only the new system will be required and the old system can be turned off. In large projects, this could be a long way into the future.
What requirements are there for making a .NET migration work?
It’s easy to assume that you need to have the right technical skills and nothing else to manage a migration from .NET Framework to .NET. In fact, the technical delivery side of things isn’t the major factor in success.
Given that many people in IT are good at keeping their skills up to date, finding the right skill sets for a migration team isn’t the greatest challenge. (Migration support is something we offer if you’re in need!)
A bigger issue is making sure that those who “receive” the migration – often non-technical people, or the people who have to support the application – have adequately defined what they were expecting to get and then to have their buy-in to allow the technical team to make the migration happen.
When we’ve worked on migrations, it’s these softer skills of clarity, communication and collaboration that have led to success.
For example, the best technical migration team in the world isn’t going to be effective if they are trying to serve a customer whose requirements are poorly defined and where there’s a lot of resistance to the idea of change.
Getting it right means forging close ties between people in the business and those who are working to make their migrated systems a success. And that goes way beyond simply technical skills.
As with most projects of any kind, the key to success is understanding what’s really required and then building relationships so that everyone involved works towards the same goal. The same is true for successful .NET migrations.
What are the risks in a .NET migration?
No one wants to say they’ve worked on a failed migration project, but whenever we’ve heard of that happening, it’s invariably been down to there being poorly defined requirements from the customer.
Put another way, bad requirements in = bad migration out.
This isn’t always surprising, as sometimes you’ll know that something is wrong or not what you want only when you see it, and it’s often not possible to think about every scenario ahead of time so you can map out exactly what’s needed.
That said, the more that can be done to work out the true requirements of the business, the better. To give our customers the best chance of success, we come up with a list of high-level requirements that we can prioritise and agree with them, and then turn that into an agreed plan of action.
Even when requirements are clear, we sometimes find that new and useful software updates come along after we’ve started a migration project, such as new versions of frameworks that give better functionality that would have been helpful earlier in the project.
In such cases, we make sure this is fed into the product cycle whenever possible and we constantly look at revisiting our options and evolving the product to create a better outcome. Where possible, we look down the line to see when future versions of frameworks might be on the way, so we can plan for opportunities to optimise the way the migration will be able to proceed.
Occasionally, there are ways of speeding up migration projects by making strategic compromises. But rather than outright cutting of corners, any such decisions should be recorded as “technical debts” and should be treated as opportunities for improvement in future releases. Such shortcuts are probably acceptable so long as they’re treated as short-term workarounds to short-term problems.
Sweeping issues under the carpet in the hope that no one will notice a failure to meet all the requirements is probably a recipe for disaster. And that wouldn’t be us: our whole thing is about doing the right thing and doing it well.
You can read more about how we apply our values to our work here.