Application Migration: Definition, types and best practices

Application migration or more generally - Software migration - is a pretty common term nowadays. Actually, the first thing that comes to mind when people talk about application migration is cloud migration. Everyone’s moving their legacy systems to the cloud nowadays in pursuit of scalability, cost reduction, security and more. However, application migration is far more than that. Actually, you can move to a higher framework version, to a new architecture or to an open-source database - the list of options is quite impressive. 

In this article we will share with you some software migration basics. Here we’ll consider the definition, the migration types and the scenarios for the most common types of application migrations. As a result, after reading this blog post, even if now the application migration doesn’t ring a bell to you and you haven’t moved a thing in your career, you’ll be equipped with the right knowledge to make a good start.

What is Application Migration?

Application migration is the process of moving an application from its original computing environment to a new one. The migration often provides new technical capabilities for the application (such as greater scalability options, higher performance, etc.) and cost reduction due to the usage of the fresh advanced technologies. 

Ok, what can be migrated? What types of applications generally move from one environment to another? Literally anything can be migrated. Any piece of software programmed to perform some function. It can be some basic stuff (like a calculator or an alarm clock) or a huge enterprise-wide application which thousands of people use daily.

Now that we know what we migrate and why we do this, let’s have a look at the types of the software migrations.

What types of application migrations are out there?

Nowadays a lot of different types of application migrations exist. In this article we’ll focus on the most common ones. Those will be 

• cloud application migration, 
• migration to microservices/microfrontends, 
• migration to open-source databases, 
• desktop to web application migration, 
• migration to a higher framework version.

Let’s consider them in more detail. 

Cloud application migration

What’s cloud migration? First and foremost, it refers to moving your application data located on premises to the cloud. Cloud, in its turn, is a huge number of the same physical computers located elsewhere. The reason behind such a transition is that those multiple computers allow for higher scalability, performance, and what not at a lower cost compared to the on-prem data center (plus cloud native features).

Cloud migration also refers to moving your workloads from one cloud platform to another (AWS → Google Cloud or Google Cloud → Microsoft Azure or vice versa or whatever cloud services provider may come to your mind).

Furthermore, cloud migration may also mean moving from a private cloud into a public cloud (which many consider a super cost-effective solution) or vice versa.

Migration to microservices (or microfrontends)

Migration to micro-anything is a new word in the application migration area, but, man, it speaks out loud!

Migration to microservices or microfrontends - also known as decoupling - is reorganizing your current system built as a monolith to end up with a new modular structure. Each independent module of the new system runs autonomously and represents some system feature. The modules are separated from each other or very loosely coupled.

Microservices mostly refer to backend systems, while microfronteds are applied to decouple frontend.

Migration to open-source databases 

This option is a lucrative alternative for those companies who previously ran their private databases and paid some maintenance fees (monthly/yearly, etc.). Migration to an open-source database will cut some of your operational costs and give access to the top-notch technologies. 

Open-source databases are mighty things nowadays. Just have a look at the list of the best options, they definitely ring a bell to you - PostgreSQL, CockroachDB, ClickHouse, MongoDB, Redis. Why stick to the old-school fee-based DBs if you can enjoy those stunning open-source options already now? The only thing left to do is to move your stuff carefully. 

Great news - apart from a whole lot of open-source databases, nowadays we have a bunch of great data migration tools that will help automate your DB migration process to reduce the amount of manual work to just a few clicks.

Desktop to web application migration

Basically what you do to migrate from desktop to web is

 re-architect your whole application and refactor it to fit into the web standards. This will require a whole lot of new technologies, languages and frameworks. Moreover, UI/UX design should be rethought, too. 

With all that done, after moving your desktop application to web you’ll be able to

• eliminate entry barriers for many potential users who opt for web apps rather than desktop apps, 
• use more advanced technologies 
• stop being overdependent on the tech capabilities of the customer’s PC
• be more user friendly for your existing customer base.

Application migration to a higher framework version

Migrations within one and the same framework may seem like no big deal, yet each case is unique. Take Angular and AngularJS, for example. The first framework version appeared in 2009 and is referred to as AngularJS or Angular 1. The second (and later versions) which entered the market starting from 2014 differ from it dramatically and aren’t compatible.

To make matters worse, Angular is known for its steep curve, so to migrat

e from AngularJS to Angular requires deep expertise and tons of practice. Yet, if yours is a large-scale enterprise created using the AngularJS framework, this is the road ahead of you.

The same thing refers to other framework migrations, such as .NET, PHP, etc. The software created using earlier versions sooner or later should migrate to the new ones.

Well, these are the basic types of application migrations. 

By the way, at Qulix Systems we perform all of those. So, if you’re interested, why not check out our software migration page?

Application migration: best practices

As there are various types of software migrations, it’s only logical that there are distinct best practices and strategies for each of them. In this article, we'll briefly consider only a few scenarios, as each software migration path is a topic for a full-length article.

Let's start from the migration strategy for cloud projects, proceed with a migration plan for those willing to move to the microservices architecture and end up with the microfrontends migration project.

Cloud migration strategy

Prior to starting any migration project every team goes through the migration planning phase. It is probably the longest one, as you have gazillion of things to be considered to land safely in your new computing environment. So, the steps 1-3 in the checklist below will be dedicated exactly to this. As long as you're done with that, we'll proceed to the Successful migration step.

Step 1. Define the starting point of your migration journey

You’re probably the owner of a small business with very clearly defined business needs. So, it should be fairly easy for you to define point A and point B of your migration path. 

However, if yours is a large scale business with data located in a wide array of locations, you are probably going to have a hard time defining which one to move. 

• Are you going to migrate those on-prem legacy systems where you manage the entire infrastructure and the application?
• Or your systems should be moved from a private cloud where you’re responsible for virtualization and resources, while the service provider is in charge with the rest?
• Maybe you’re going to move the resources from one cloud to another?

In reality, your system can also use all the options above by being partly located on your premises, partly in a private cloud and partly in a public cloud. Thus, your first step will be to decide which part of your system is going to migrate, and going to migrate first (if you decide to move all of them).

Step 2. See what type of workloads you are going to migrate

These can be legacy workloads and cloud native workloads. 

Naturally, legacy workloads are those designed and deployed without consideration of the cloud capabilities. They are the hardest to move and accommodate in the cloud.

Cloud-native workloads are designed to meet the cloud development needs and enjoy cloud capabilities (scalability, performance, security).

Step 3. Pick up your best data migration strategy

The fastest method to move from a source to a target environment is lift and shift. This means you basically take your application located anywhere (on-prem, in a private or a public cloud) and squeeze it into the dedicated cloud space. Yeah, that’s the word - squeeze into - as too often migrants simply don’t fit into a new cloud environment.

However, cloud-native applications can very well be moved in this manner, with little modifications before, during or after migration is complete.

Find more about the cloud migration strategies in our dedicated blog posts on the topic.

Step 4. Successful migration

Do the portfolio assessment --> Plan thoroughly  --> Deploy your system--> Optimize it. This will be your migration path on this closing Step 4.

In more detail, during the Assessment you should look through all your app inventory, dependencies and requirements, make some detailed cost calculations and end up with performance benchmarks.

Planning means coming up with the basic cloud infrastructure for your project (including environments, folders, resources, networks, etc.).

Deployment implies executing your planned actions.

Optimize and test. This means getting accustomed to a new cloud environment, finding the ways for your system to perform better in a cloud-based environment and employing new cloud capabilities (scalability, disaster recovery, AI/ML, etc.).

Well, this is a very rough cloud migration plan for you, and we're moving along to see some more migration strategies.

Migration to the microservices architecture

Step 1. Revision and planning

Likewise migration to the cloud, migration to the microservices architecture requires careful migration planning. To create a stunning migration plan, first run the system audit and revise your existing architecture.

Step 2. New architecture

Create a new architecture with the microservice paradigm in mind. It is not the modules development that will pose the biggest challenges for you when deploying a microservices-based system. It is how they are going to talk to each other, what will be the communication patterns, how to keep them reasonably isolated to leverage the power of microservices. Thus, the new architecture should reflect how you are going to deal with these communication issues. See the one below as an example.

Step 3. Project infrastructure

This means virtualization, container orchestration system, CI/CD tooling, etc.

Step 4. Put the first migrants into the new infrastructure

Start from leaf services that do not affect the business logic. Furthermore you can also try decoupling stateless components first, as they do not have brittle dependencies with the rest of the system either.

Step 5. Continue with the rest of the system

That’s it! You’ve landed safely in your new operational environment.

Ah, last but not least.

Remember to get yourself well familiarized with a wide range of migration software and migration tools well beforehand. The key factor of the migration project success is in the competence of your talents and their ability to move, test and support the system in the new environment using cloud services (MS Azure, AWS (Amazon Web Services), GCP (Google Cloud Platform)), containers and orchestration tools, API gateways, DevOps and CI/CD tools as well  as system health monitoring and logging tools.

Migration to microfrontends

This algorithm is very similar to the one above.

Once again, we start from the system audit and proceed with architecture. In microfrontend-based architecture the focus is again on the right communication patterns (see below).

Infrastructure and CI/CD steps follow.

The last phase will be getting into the target architecture.

The reason why micro-migration strategies are so similar, is that they both deal with the same problem - breaking up the monolith into smaller loosely coupled modules. Sure, during the realization process different technologies are used, but the approach is one and the same - monolith decoupling.

Final thoughts

As you know now, application migration is the process of moving a piece of software from one environment to another. Yet, migration is not limited to the cloud industry only. It can be moving to microservices, to a higher system version, desktop to web, etc.

The reasons behind the change in location of your system may be poor system backup, low performance, lack of efficient management tools or something unique that your current environment lacks. Due to the usage of new top-notch technologies after application migration, the system's behavior as a rule improves dramatically.

To fully leverage the power of new technologies in your new environment, determine your weak points and how the new environment is going to help you deal with them. To do this, carry out a thorough system audit, regardless of the type of migration you are planning. Next act according to the strategy that suits your needs best.

P.S. 

Remember to check out those links above for cloud migration scenarios! The two articles on the topic contain all the basic info you may need to decide on your cloud migration type.

In case you’re interested in microservices/microfrontends, we have great whitepapers on the topic with the migration roadmaps (available upon request).

Stay on our blog to read more on the best practices in the software development industry. We cover all the SDLC stages - from requirements, to development to testing.