Application migration: a step-by-step guide

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.

Focusing on the background

Technical application audit

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.

A quote: Sometimes, the audit might look like garage cleanup: we may find instances that aren't in use anymore or installed apps we’re unaware of.

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.

Performing application audits we are focused on: infrastructure, main application, plugins & integrations, security & compliance, performance & scalability, business impact

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.

A quick checklist for legacy application migration

  • What values does the tool/migration add to your company?
  • How big is the migration project going to be?
  • How long will it take?
  • How much will it cost?
  • What’s the estimated return on the investment?
  • How much data are we going to move?
  • How will the systems be integrated?
  • How will the user management work?
  • What resources and tools do we have at our disposal to help us migrate successfully?
  • Should we move all our apps to the same hosting option to preserve the process flow?
  • How can we secure the application data?

Convincing the stakeholders

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.

A quote: Our legacy task management system is no longer supported by its manufacturer and operates on an outdated engine, while the source code remains proprietary. This puts our company at risk of a critical security breach and significantly increases technical debt, while the possibility of further development or bug fixing is disabled. Therefore, we highly advise that we perform a migration to a new platform within the next year, especially given that 80% of the company's work is still being tracked in the abovementioned legacy tool.

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. 

Application migration assessment and planning

Gathering the project requirements

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. 

Want to learn more on how to do this part right?

Here is a great piece to start

Setting up a migration project plan

Designing the target solution

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.

Mapping out the required skills

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:

  • Project Lead – the process owner who describes the business case, distributes and tracks the individual tasks, and acts as the main point of contact for the stakeholders.
  • Executive Sponsor – the person from the C-level management who approves the business case and handles the project budget. Most often, it’s the CTO or the CIO.
  • App & System Admin – the person who configures our systems and handles the day-to-day administration. Should have some experience with the process itself, as well as the applications and hosting options involved. 
  • Technical Staff – the team that actually performs the migration – from cleanup and backups, through testing and staging, up to the production instance. It’s great when the squad members come from different teams and use systems in different ways. This section can be fulfilled with external staff, i.e. a technical partner or an IT outsourcing company.
  • Security & Compliance Officer – the person who is involved in the planning stage to make sure the migration meets all security and compliance standards, like VPN, firewall, or data residency.
  • Power User –the person who knows the products inside out and will help the organization get used to the new toolset. Duties include training, troubleshooting, and possibly workflow brainstorming support.

For data center or large database migrations, these are a couple of additional roles that we might consider having on the team:

  • Network Engineer –the person who reviews the technical specs and rebuilds your infrastructure.
  • Database Admin – the person who confirms database integrity and smooth operations.
  • Site Reliability Engineer (SRE) – the technical person who takes care of instance uptime, performance, and disaster recovery operations.
 app migration table of contest: optional expertise roles, minimum valuable team

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. 

Choosing the migration strategy

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

  • A full migration means that we’re moving the whole stack or all the instances of a certain application all at once. It is known better as the lift and shift approach. It gives us a shorter timeline and often lower costs, but may increase downtime in case of a large dataset.
  • A partial migration assumes that we move only a part of the data, selected processes, or a couple of instances. A hybrid cloud environment is a great example here. In the case of migration to the cloud, we might need to preserve some data on the server instances for reference in the read-only mode as well. To help users get used to the cloud environment later on.
  • A phased migration allows us to move applications and/or data step by step. After completing each step, we onboard affected users, get feedback, fix problems, and move on to the next section. This approach is useful when we can’t afford the downtime of all the instances at once. Also, with projects of higher complexity. However, often it will result in a longer timeframe to complete, more deployments to manage, and higher costs.

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). 

Creating the timeline

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.

Communicating the changes to the company

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.

Performing the migration

Current toolset cleanup

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.

Testing & Staging

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.

 image: Your network, load balancer, cluster nodes, node 1, node 2, node + n, shared database, shared file system

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.

After test-run checklist

  1. Review our previous assessment, make amends if needed. Then communicate with the stakeholders again to confirm that everything is going as planned. 
  2. Proceed with the staging phase when we freeze the app’s configuration and perform stress tests. 
  3. Periodically updating our staging environment with production data, or test the process will ensure that backup files are corruption-free and usable. During this period, we should communicate that the settings mustn’t be changed. The app may be periodically restarted, and report errors.

Production launch

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.

Post-migration activities

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

  1. Collecting the statistics for the post-migration report (e.g., in the case of an application merger, we need to include the before-and-after configuration impact chart to check if we haven’t created clutter somewhere in the system).
  2. Shutting down the previously used applications. It’s best to leave it in the read-only mode for some time after the migration and gradually reduce access for certain user groups. Once it’s no longer needed, we should redirect users to the new one. We should disable signing in, and ultimately turn it off.
  3. It is a good practice not to switch off the test environment that we set up for migration purposes. We can use it later on for testing customizations and improvements. It is a good idea to synchronize configurations with the production environment so that all the settings are the same.
  4. Ask Power Users to perform some training. For most cases, a side-by-side demo of the old and the new solutions is more effective as it helps to better understand the terminology and use of the new tools. Additional training for the app and project admins is useful as well. This way, we make sure that the app isn’t going to break after some time down the road. 

What’s your approach to application migration?

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.

Make the right business decision

Get in touch to consult and recommendations!

Dzmitry Hryb

Dzmitry is a Marketing Manager at Deviniti. For the last couple of years, he's been on the mission to help people make the best use of Jira Software and Jira Service Management at work by creating guides and tutorials for Atlassian users all around the globe. He received the Atlassian Community Content Awards three times in 2018. He spends the rest of his time winning pool tournaments, producing music, biking around, and playing with his two cats.

More from this author