This article has been updated on February 2023 by Content Specialist Dominika Kuraś-Moskwa.

Which sentence is true for you? You are looking for a way to upgrade or reduce physical infrastructure for your corporate systems. You want to reduce overhead and save money by moving all internal applications to the cloud platform or data center. You are willing to enable the IT team to focus on more ambitious projects than maintaining hardware. Or maybe you just discovered a bunch of game-changing features that had never existed in your legacy toolset. If at least one sentence is true for you, then application migration should be your choice. It is always a daunting task that requires patience, cross-functional collaboration, timely communication, and performance as fast and cheap as possible. In this article, we’ll go through planning and executing the whole software migration process step by step.

When we think of migrating applications and systems, we should start with a review of the existing toolset. Then evaluate various scenarios, and get a vision of the final result. To develop a solid migration plan and perform a change impact analysis, we have to understand what products we have in the stack. The way of hosting, connecting, and who’s using them and for what purpose.

This process will provide a comprehensive analysis of the company’s tech stack, including physical infrastructure and data movement. We should strategically consider growth and development plans. Optimize both tools and underlying processes during the application migration. Any conflicts between current and target tools require documented and informed decision-making.

Here’s a list of seven main areas where we should gather information during the migration check.

That’s a whole lot of information to gather and process! The bigger the project, the more. For example, our experts at Devinti split these seven aspects into 36 groups with a total of 150 checkpoints. So we’d recommend preparing a blueprint for future use or asking a technological partner for help.

Here’s a short checklist that can help you get a general overview.

When we have the outline, we should draft and present the case to get the buy-in from the company management. It may be an agenda point for a meeting or a formal proposal template if the company has one. Anyway, we should communicate why we need the migration to happen, what we’re trying to achieve, and how we’re going to do it.

Depending on our and the other stakeholders’ position, we should look for more business-related or technical points to back up the case. But most of the time, it should be a combination of both to fully cover the potential risks coming from maintaining the status quo. Let’s keep in mind that while application migration is quite a risky move, not migrating is sometimes even riskier. Especially if a given tool enables business-critical processes. In this early stage, even a rough estimate of migration project timelines, budgets, dependencies, etc., is extremely valuable.

We should be able to get the green light within a couple of hours of a board meeting – that would be the perfect situation. In practice, this takes a bit longer. In highly regulated companies, pushing the decision up and through the C-suite can take up to a couple of months. To help ourselves, we can search for an ally impacted by the change. And can be an influencer of this kind of decision, e.g., a group of users can bring social proof via their voices and support. 

When we’ve got the approval, the next step is to elicit business, technical, and security requirements from both the stakeholders and the end-users. The first group will give us a high-level view of the processes and governance while the second one will tell us more about the performance and user experience of the software. Documenting, structuring, and prioritizing the resulting list is critical to shaping our final decisions accordingly, from infrastructure recovery to tool configuration. The final requirements document must be accepted by all parties, so there must be room for compromise and cooperation in evaluating different alternatives.

For example, when considering updating the license with Data Center and staying at a single node, we should decide if we just pay for the license and remain on a single server, develop a clustered multi-node architecture inside the company, or host the instance on a public cloud provider like Amazon Web Services or Microsoft Azure. It depends on the company’s economy, technical suitability, and solution optimality. Moreover, the decision relies on the system’s high availability and performance at the same time, or stores sensitive customer data inside Jira that must remain behind the company firewall.

All in all, the requirements structure should give us the foundation for planning out what, and when we’re going to do. It should include people involved in the process as well. 

Now it’s time to exactly visualize what the final result of our work will look like. To do it, we should map our existing functionality along with the previously gathered requirements to the features that the target tools have. Most often, we do it just to make sure that all the requirements are met before we start. Even if we already know what the target tool is. But in addition, we can imagine the migration process itself by doing it. It will help us to spot potential conflicts and complications. In turn, noticed problems will enable us to indicate the application readiness to move and calculate the resources we’ll need to do it.

As a rule of thumb, we should consider setting up dedicated cross-functional project squads for migrations. There’s no definite approach about how many people should be included on the team. However, depending on the infrastructure and architecture complexity, we might need the following roles involved:

Looking at this, we should assess if we have skilled people on the board to perform the migration. If we’re unsure, we should consult. Most enterprise software providers have technical support teams to help with product and licensing inquiries. The largest vendors frequently have a partner network. It allows them to contact regionally authorized partners with experience in migrating the precise software they use. Having better results in mind, they should reach them. 

Depending on our migration goals, the audit results, and the available resources, we may choose one of the possible strategies.

We can also make a decision to consolidate a couple of instances together. Or start from scratch with a clean application without moving any data. These are specific migration cases that we should decide upon according to business or technical needs (e.g. unused instances, or an extremely tight deadline to complete the project). 

First, we need to know what exactly we’re going to migrate, who’s going to do it, and when we need to complete the project. Then we can confidently outline a roadmap putting our effort into a timeframe. On average, the preparation phase takes 2-4 weeks. The dry run and staging environments along with all the fixing and optimization might take from a week to 6 months. The same applies to going to production and preparing the operational users.

While estimating, we should take into account the chosen migration strategy, the number of users affected, the amount of cleanup required during the prep phase, the amount of customization we need to replicate in the target solution, our internal approval processes, and the size of the team actually working on the project.

After stakeholders approved the plan, timely communication is crucial to complete the project within budget. We must inform stakeholders and end-users of the upcoming changes, consequences, necessary actions, and new procedures for login, training, troubleshooting, and contacts. During production migration, we may ask app and project admins to refrain from making changes until completion. Communication regarding the fate of the existing app and its data is often critical.

Ideally, we should bring in someone from the communications department to help plan the reminders and all the important milestones of our process, including post-migration training, etc. After this, we’re ready to successfully migrate.

We’re starting out with preparing the current applications for migration. By documenting the configuration, we better understand which configurations, plugins, and other important elements we should migrate. This is also the stage where we optimize performance, get rid of unused configurations, and ensure data integrity.

One of the best practices is to create app backups databases, and file directories that we’re currently using. We should do it also after each migration phase as well). If we do it, we should also practice the procedure to make sure we’re prepared in case of an emergency when we have to stop the process and roll back for a moment.

After we’ve cleaned up, a good move is to perform health checks of both the current and the target applications. Most decent software providers include appropriate tools in the installation package. It helps automate this process and eliminate errors instead of migrating them. Then the underlying processes and the amount of data that we need to process, a stress test of the target application we might need.

When we’re done, we should test the migration to get familiar with the process. Moreover, we should make sure everything works as expected. By doing so, we’ll be able to better predict the expected downtime and fix potential issues. We test the migration with all phases in the test environments, provided by our customer.

An example of infrastructure requirements for Jira Data Center deployment. Source: Atlassian Documentation

In order to confidently deploy to production, the migration team should run through an iterative set of functional, integration, and performance tests. This will decrease the production deployment time and allow us to prepare for unforeseen circumstances. 

The testers should first validate the application data. After that, a good tip is to let the actual end-users in to receive feedback and spot potential problems. During the User Acceptance Testing, the end-users should be able to replicate their day-to-day tasks on the test environment and approve that their requirements for improvement have been met. While testing, we should make sure that the test dataset is integral and similar in size to what we’re going to move in production. The best option is to try moving the actual project data. This way, we make sure that we have accurate estimates for procedures like backups. It may impact the duration of the whole process a lot.

When everything’s ready for the launch, the most important thing is to wisely choose the migration date. It shouldn’t impact the users and processes inside the company. Moreover, the key team members have to be available. Unfortunately for us, it often means an all-nighter or a weekend gig. Experienced admins are already familiar with such a schedule. If these options aren’t available, we should choose a time outside the peak usage hours. What is crucial – we should take into consideration all the time zones. The release shouldn’t collide with important events like automatic software releases. Of course, we should communicate the launch in advance so that everyone’s informed and prepared.

But the work barely ends after the target instance goes live. The next steps are:

App migration is a tedious task in many ways – too many things can go wrong while performing it. A solid plan and an execution strategy are imperative. They can vary in each case depending on numerous factors. Timely communication and preparing everyone for the change are even more essential. After all, we want to make sure that the process fits into the planned timeline and budget. We can certainly make the teams’ work a bit better and open a new space of possibilities for the whole organization. The condition here is to gather the requirements we should meet. Include improvements to the migration plan, and ultimately set up a bulletproof change management process.

At Deviniti, we’ve been helping companies around the globe improve their business results with the help of technology for the last 18 years. As a technological partner for your business, we will help you choose the best possible solution according to business analysis and complete the IT skills you need to implement it.