What to Keep in Mind When Migrating Systems?

In the past few years, I have spent most of my time either migrating systems or facilitating their migration by creating applications for this purpose. Today, we're going to talk about migrating applications.

1 - Migrating from a Monolith to Microservices

In this post I'm not going to discuss whether we should migrate to microservices or not, or the additional costs involved, I've covered that in other posts. Here, we're going to focus on what to keep in mind during the migration process. 

For this scenario, let's imagine we have a huge monolithic application, just to make it simple, let's say it's a store.

1.1 - Choosing Elements to Migrate

Now we have two options: either we migrate to microservices or we leave the existing system as it is and build all new developments in microservices. 

Ideally, a mix is best: everything new is built as microservices, but for the legacy parts, you need to select what to migrate. The most logical approach is to choose elements that are heavily used but not crucial if they fail. 

For example, in a store, migrating the payment system can be more dangerous than migrating the email system. Even if both systems are used similarly, if the payment system fails, the consequences are much worse than if an email goes unsent. 

Each system has its own characteristics and needs an analysis before making this choice. 

1.2 - Using Infrastructure and Automation

Before you start coding business logic, you must have the system ready to support continuous integration and automatic deployment. CICD is an absolute necessity for your system to work. When you only have a monolith and deploy once every six months, it can be done manually, but if you're going to have dozens of services, it's not feasible.

1.3 - Observability and Monitoring

Instrumenting observability is also a very important point that we can include in the infrastructure section. Before deploying anything, you must ensure that monitoring and logs are sent to a centralized location where you can easily view them. 

Otherwise, you will most likely end up with huge headaches trying to find bugs without any visibility. 

1.3 - Cross Cutting Concerns

Now that you've decided to migrate to microservices, you'll have noticed that there's code that is repeated in almost every microservice. Repeating something once or twice is fine, but when you know you'll need it across many places, you should abstract it and put it in a common location. 

We usually call these abstractions crosscutting concerns, although every company may have a different name for them. In some companies, anyone can modify these abstractions and in others, only a particular team can. In my opinion, it's best if anyone can modify the abstraction, but a dedicated team should be in charge of maintenance and be responsible for things like fixing the code. 

Common examples of these kinds of abstractions are authentication configuration. In large companies, if you use AWS/Azure services, your buckets/storage or even your database tables may need to have certain names for consistency. All this is configured through an abstraction, giving developers as few options as possible. 

The same goes for monitoring, logs, etc. On this website, we created a course on distributed systems where we looked at some of the most common abstractions in companies. 

1.4 - Migrate Gradually

The final point is to migrate gradually. Simply put, migrate step by step, you don't have to migrate the entire system at once; you can even migrate without editing the monolith at all. 

Nowadays there are techniques that let you check the url and redirect to the new system instead of the monolith itself.

This means you can leave the monolith untouched, without changing anything, and just by configuring your service provider or API gateway, redirect to the new system. From the user's perspective, nothing changes, as the URL remains the same, and if anything doesn't work properly, you can always switch back to the monolith with no trouble. 

When migrating from a monolith to a microservice, don't delete the monolith's code until you can guarantee everything works as expected.

And always have a plan B to return to the microservice, which is very easy if you use a feature flag service.

2 - Migrating Between Versions or Languages

Another common type of migration is moving from one language to another or between versions of the same language, mainly for performance improvements, since these changes don't usually affect users directly.

In my case, most of these migrations have been within .NET, specifically migrating from .NET Framework and .NET.

Every language or version has its own characteristics, so we're going to focus on the framework/core.

2.1 - Migrating from .NET Framework to .NET

Nowadays, we're already on C# 12 as the LTS version or on C# 13 if you use short versions.

The latest .NET Framework version uses C# 7.3, which is six versions behind the current version, and as you can imagine, that comes with many changes. 

Assuming all your code is running correctly on .NET Framework, the first thing you have to do if you want to migrate to .NET is make sure the clients and libraries you use are compatible with .NET (core).

For example, your service calls another service, and for that you use an HTTP client generated from the app you call. If that client was created along with the app, it's very likely it's a .NET Framework client. If you're migrating your app to .NET you'll have to create a new client or update the existing one, ideally using .NET Standard so it's compatible both with your new service and with .NET Framework. That way, if you need to change anything, you only have to update that package. 

Once you've identified your direct dependencies, you need to ensure all packages work with .NET, but not just that, make sure they work for Linux* as well.

* Personally, whenever I have migrated from .NET Framework to .NET, we also moved from Windows to Linux, since maintaining the application costs a fraction of the price. That means for some libraries, we had to look for alternatives that actually work on Linux. 

If other teams in your company have already migrated, don't hesitate to reach out, they may have run into and already solved the unexpected problems you might encounter.  

These kinds of migrations often have issues with dependencies, where one dependency depends on another and so on... It's not the best experience, but hang in there.

3 - Refactor and Migrate at the Same Time

One question you might ask yourself is whether it's worth migrating and taking the opportunity to improve the code. 

The answer is no, usually migration is already tedious enough and comes with plenty of problems, especially if the old projects haven't been maintained and patches have been stacked on top of each other. 

The recommended approach is to migrate, copying as much code as possible, and then, once you finish, create a separate ticket for refactoring if necessary. Having both unit and integration tests is crucial for being able to refactor.