Application migration: a step-by-step guide
Looking for a way to upgrade or get rid of physical infrastructure for your corporate systems? Want to reduce overhead and save money by moving all internal applications to the cloud or data center? Would like 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 never existed in your legacy toolset? No matter what the reason is, application migration is always a daunting task that requires patience, cross-functional collaboration, and timely communication to be performed as fast and cheap as possible. In this article, we’ll go through planning and executing the whole migration process step by step.
Laying down the background
Technical application audit
When we think of migrating apps and systems, the first thing we should do is to review the existing toolset, evaluate various scenarios, and get a vision of the final result. To develop a solid migration plan and perform change impact analysis, we have to understand what products we have in the stack, how they are hosted and connected, and who’s using them for what purpose.
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 procedure will give us a more thorough look at the whole company’s tech stack complexity, including the physical infrastructure and the amount of data that we’ll need to move. At this stage, we should take a strategic look at the situation and include our growth and development plans into the calculations. Quite often, we can improve not only the tools’ functionality or configuration but also the underlying processes while moving the application. Also, if we find conflicts between the current and the target tool, we should make and document informed decisions about how to handle them.
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 Devintiti 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 get a first quick look from the bird’s eye view.
A quick checklist for legacy application migration
- How does the tool in question affect business continuity?
- How big the migration project is 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?
- Will the systems be integrated the same way as before migration?
- What resources and tools do we have at our disposal that can 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. It’s good to remember (and remind everyone else) that while application migration is quite a risky move, not migrating is even riskier sometimes, especially if a given tool enables business-critical processes. At this early stage, even a rough estimation of the migration project timelines, budgets, dependencies, risks, and available resources can be extremely helpful.
We can use something like this: ‘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.’
In a perfect situation, we should be able to get the ‘green light’ within a couple of hours of a board meeting. 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 who is also impacted by the change and can be an influencer of this kind of decision. If we have a large group of application users who would also love to replace or move it, we should involve them in the process as well. This might add us some social proof and additional voices supporting our case, as well as helps us prepare the communications regarding the changes way before we start off.
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 crucial so we could shape our final decisions accordingly, from rebuilding the infrastructure to configuring the tools. For the testers, such a list means many hints about what they should focus on. The final requirements document should be approved by all sides, so there should be some room for compromise and collaboration in assessing different options.
For example, when considering moving from Jira Server to Data Center, 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 all depends on whether the company wants (and can afford to) build a new architecture, 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, who, and when we’re going to do.
We write more about how to do this part right in this article about requirements management.
Setting up a migration project plan
Designing the target solution
Now it’s time to exactly visualize how the final result of our work will look like. To do it, we 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 will be met before we start, even if we already know what the target tool is. But in addition, we can already imagine the migration process itself by doing it, which will help us spot the potential conflicts and complications. In turn, this 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 definitive advice about how many people should be included on the team. However, depending on 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 is the main point of contact for the stakeholders.
- Executive Sponsor: Someone 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: Someone who configures our systems and handles the day-to-day administration. Should have at least 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 our systems in different ways. This section can be fulfilled with external staff, i.e. from a technical partner or an IT outsourcing company.
- Security & Compliance Officer: Someone involved in the planning stage to make sure the migration meets all security and compliance standards, like VPN, firewall, or data residency.
- Power User: Someone who knows the products inside and out and will help the organization get used to the new toolset. This includes training, troubleshooting, and possibly workflow brainstorming help.
For data center or large database migrations, these are a couple of additional roles that we might consider having on the team:
- Network Engineer: Someone who reviews the technical spec and rebuilds your infrastructure.
- Database Admin: Someone who confirms database integrity and smooth operations.
- Site Reliability Engineer (SRE): A technical person who takes care of instance uptime, performance, and disaster recovery operations.
Looking at this, we should assess if we have all the needed competencies inside our org to perform the migration. If we’re unsure, we should look around for help. Most enterprise software makers have some kind of a technical support team to assist with product and licensing questions, as well as help us assess the available options when planning. In addition, the biggest vendors often have a partner network so that we can reach out to local authorized partners who have expertise in migrating the exact software we use.
Choosing the migration strategy
Depending on our migration goals, the audit results, and the available resources, we will 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 — this is known better under the “lift and shift” approach. This will give us a much shorter timeline and often also lower costs but may increase downtime in case of a large dataset and require simultaneous onboarding of all the users, which may be difficult in case of large-scale migrations.
- A partial migration assumes that we move only a part of the data, the selected processes, or a couple of instances. For example, we may choose a hybrid cloud environment, where some instances are on-premises and the other part is moving to the cloud. In the case of cloud migrations, we might need to preserve some data on the server instances for reference in the read-only mode as well, which helps the users get familiar with the cloud environment and makes room for optimizations later on.
- A phased migration allows us to move applications and/or the data step by step. After we complete each step, we onboard the affected users, get first-hand feedback, solve the problems, and then move on with the next chunk. This approach is useful when we can’t afford the downtime of all the instances at once, or the project is of higher complexity. However, often it will cause a longer timeframe to complete, more deployments to manage, and higher costs as a result.
We can also make a decision to consolidate a couple of instances together or start from scratch with a clean application and not move any data. These are specific migration cases that should be decided upon according to business or technical needs (e.g. unused instances, too much cleanup to migrate as is, heaps of obsolete project data that we don’t need anymore, or an extremely tight deadline to complete the project).
Creating the timeline
When we know what exactly we’re going to migrate, who’s going to do it, and when we need the project to complete, we can confidently outline a roadmap that will put our effort in a timeframe. Quite logically as it sounds, the time required to migrate increases as complexity is added to the project. On average, the preparation phase takes 2–4 weeks, the ‘dry run’ through test and staging environments along with all the fixing and optimization might take anything from a week to 6 months, and 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
When we’re done with the plan and have it approved by the stakeholders, it’s high time to announce the upcoming changes within the company. Proper and timely communication is a key factor that we’ll complete the project on time and within the budget. We need to inform both the stakeholders and the end-users about what we’re about to do, what is going to change for them in effect, when the migration is going to happen, what downtime they can expect on the existing instances, and what actions are needed from them to ensure the process goes smoothly for everyone. We should let everyone know about the new URLs to bookmark, the guidelines to log in, the training that we’ll provide them with, and the contact people to troubleshoot and get help from. We might ask the app and project admins not to change anything on the new instances until the migration is fully complete. Quite often, information about what’s going to happen with the existing application and its data is also crucial. Sometimes, the users will also need to reset passwords or create new accounts on their own.
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 for the migration itself.
Performing the migration
Current toolset cleanup
We’re starting out with preparing our current applications for migration. By previously documenting the configuration, we better understand which settings, plugins, and other important elements need to be migrated. We’ll use these documents to create the test cases and make sure that all elements are taken into account. This is also the stage where we optimize performance, get rid of unused configurations, and ensure data integrity. The more we clean up, the less we’ll have to move.
One of the best practices is to create backups of the applications, databases, and file directories that we’re currently using and also after each migration phase. If we do it, we should also practice the restore 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 application. Most decent software providers include appropriate tools in the installation package that help automate this process and eliminate errors instead of migrating them. Then, depending on the underlying processes and the amount of data that we need to process, a stress test of the target application might be needed.
Testing & Staging
When we’re done, we should test the migration to get familiar with the process and make sure everything works as expected. This way, we’ll be able to predict the expected downtime more accurately and work out any potential issues.
First, we’ll prepare a test environment that will meet all our requirements from the list, from infrastructure to functionality. For example, for clustered architecture, we’ll need a database component, a load balancer, the desired number of application nodes, a file system, etc.
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 account 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’ll make sure that we have accurate estimates for procedures like backups, which may impact the duration of the whole process a lot.
After the test run, we should review our previous assessment, make amends if needed, and then communicate with the stakeholders again to confirm that everything goes as planned. Then we proceed with the staging phase when we freeze the app’s configuration and perform stress tests. During the freeze period, we should communicate that the settings should not be changed, the application may be periodically restarted, and report errors occasionally. That’s because we’ll periodically update the staging environment with production data, or test the restore process to verify that the backup files are corruption-free and usable.
Production launch
When everything’s ready for the launch, the most important thing is to wisely choose the migration date. It should least impact the users and processes inside the company, and ensure the key team members are available. Unfortunately for us, it often means an all-nighter or a weekend gig, but experienced admins are already familiar with such a schedule. If these options aren’t available, we should choose the time outside the peak usage hours accounting for all the time zones that also don’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. What we should do next is to collect the statistics for the post-migration report. For example, in the case of an application merge, we need to include the before-and-after configuration impact chart to check if we haven’t created clutter somewhere in the system. These will also be useful for future reference when estimating further growth and scaling up. Next, we should shut 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. When it starts being completely unnecessary, we should automatically redirect the users to the new one, disable the ability to sign in, and ultimately switch off. What we shouldn’t switch off, though, is the test environment that we set up for migration purposes. We can use it later on for testing customizations and improvements. A good practice is to synchronize configurations with the production environment so that all the settings are the same.
Training the users
Now it’s time to call the Power Users and ask them 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. Also, additional training for the application and project admins is also useful. 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, as too many things can go wrong while performing it. A solid plan and an execution strategy are critical for success, and they can be extremely different in each case, which depends on numerous factors. Timely communication and preparing everyone for the change is even more important if we want to make sure that the process fits into the planned timeline and budget. However, if we carefully gather requirements we should meet, include improvements into the migration plan, and set up a bulletproof change management process, we’ll most certainly make the teams’ work a bit better and open a new space of possibilities for the whole organization.
At Deviniti, we’ve been helping companies around the globe improve their business results with the help of technology for the last 16 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. Get in touch with us to receive initial consulting and get recommendations to make the right business decision.
Also, read more on our Technology-Driven Blog:
