The COVID-19 crisis has reinforced the importance of data centers and what critical impact they have on organizations. Entire industries are effectively being reset, and this transition has made digital infrastructure more important than ever. As part of that, CIOs are evaluating the shift toward a variety of modern data center solutions, including remote hosting and cloud services.
While many organizations are considering the shift to these new environments, the process of actually executing that strategy and moving applications is a major obstacle to overcome. To successfully aid organizations needing to quickly shift to new data center solutions, we developed a unique methodology for migrating applications with minimal operational disruption and risk. The approach calls for an upfront migration assessment, along with a five-step process that teams can follow to migrate one or multiple application groups at a time. Application-by-application, the five-step process ensures optimal value is achieved each step along the way with minimal downtime. With proven success at topU.S. healthcare institutions, this approach has the ability to restructure the way organizations migrate to updated infrastructure platforms and models.
To tackle each iteration in the application migration process, it’s best to use a hybrid-agile project management methodology. A PMI-backed waterfall model for upfront planning ensures appropriate processes for a sound governance framework, a high-level timeline, a clear charter, and budget controls and metrics. Then, during execution, an iterative agile approach facilitates organizational transparency, continuous reflection, a flexible schedule and overall team empowerment. With sound processes to organize and maximize team efforts, this methodology ensures important application migrations are implemented as efficiently and cost-effectively as possible.
What is application migration?
Application migration is the process of moving a software application from one computing environment to another. You might, for instance, migrate an application from one data center to another, from an on-premises server to a cloud provider’s environment, or from the public cloud to a private cloud environment. Because applications are typically built to run on particular operating systems in specific network architectures or developed for a single cloud platform, moving an application to a new environment can pose a number of challenges.
Additionally, every application is different on some level, and many environments become aged because they were put in years earlier and haven’t been upgraded or replaced. This can create additional complexities because it can be hard to efficiently move applications that have varying vendor sources, application types, ages, infrastructure requirements, operating systems and versions. To best combat those challenges, IT teams can utilize the five-step process for their next data center modernization project. Each phase of this process includes templated documentation and checklists for the engineering team completing the work effort.
Overall, this methodology allows team members and stakeholders to effectively address scope changes, increase team productivity and properly utilize resources without investing in unneeded technology.
Initial Migration Assessment
To ensure the effectiveness of the five-step process, it is necessary to conduct an initial migration assessment. This prep work requires the full attention of the infrastructure and application teams. The teams will work with the goal of (1) obtaining an accurate list of applications involved in the migration and all servers associated to each application and (2) determining the grouping of applications to be migrated together. Then, a true evaluation can be developed for the migration scheduling and effort required.
This phase is critical to provide teams with the necessary information to be able to successfully start the migration process without any unanticipated roadblocks. It will require the following actions:
- Map server inventory and applications
- Create applications groups
- Schedule migration and estimate effort needed
After the initial assessment, the application migration will be completed with an agile methodology that vertically slices application groups into iterations. Using the application groups determined in the initial migration assessment phase, an iteration would involve completing the entire five-step process for one application group. For example, one group in an iteration for a hospital could contain only pharmacy and medication dispensing applications. Splitting the project in this way minimizes operational disruption because fewer IT and clinical staff are involved at once for a shorter window of time. Additionally, by executing one application group from start to finish, the team will have a completed deliverable that’s running and ready to utilize in the new environment. Another benefit of this framework is that a team can also work all the way through one application group, review results with the project team and stakeholders, and apply lessons learned when starting on the next application group. The approach allows them to streamline project execution before closeout, and better adapt to unexpected roadblocks.
Step 1: Prerequisite Gathering
This step is about assessing the application’s operating requirements and developing a strategy for migrating the application and other groups of software and hardware necessary for its operation. There are four key components to this stage, including:
- Create a discovery document
- Design an architecture diagram
- Develop a migration process flow
- Secure external resources, if required
Step 2: Mock Migration
Once the prerequisite gathering stage is completed, IT teams can begin executing the mock migration phase of the application migration methodology. This phase allows teams to perfect the steps defined in the migration process flow. To do that, the server environment needs to be created first. This will depend on the process defined by the technical teams on whether to create new servers for application installs or to perform virtual to virtual (V2V) server migrations from one virtualized environment to another. During this phase, there are four key action items to accomplishing a successful mock migration.
- Create/migrate servers and storage
- If an application is running on the current supported version, the best approach is to migrate the existing server(s).
- If an environment is not on the latest technical standards, a team might want to consider installing the application on a net-new environment, which would include the latest approved operating systems agreed upon by a technical review board.
- Create and validate testing scripts
- Make sure there is a standardized template for test script creation.
- Each application lead should be responsible for ensuring completion of the scripts that are tested on the current environment.
- Once servers/applications are turned over to the application team for testing, the leads should execute the same scripts on the new environment to ensure functionality.
- This is also the phase to remediate any issues found within the testing period.
- Create a playbook
- The migration playbook is a sequenced set of tasks to provide play-by-play efforts needed for the resource(s).
- As an additional key tool, the playbook also incorporates the assigned estimated duration to each step, and it indicates the team is onboard with the determined plan so that the project lead can obtain team sign off.
- Test load balancing, load capacity and high availability, if needed
- These configurations should be set up before the final production migration
- Once configured, these functions should be tested with the test copy of the servers.
- To conclude this step, the IT team will need to validate capacity by completing a full test load to ensure the system can handle it (where possible).
Step 3: Failover Testing
Failover is the ability to switch application processing from a primary to a secondary location when needed. Failback is the process of shifting back to the primary location after a failover. Both capabilities need to be tested to ensure continuity of applications and prevent disruptions. Since you’ll need to test both of these capabilities, creating and performing pilot simulations with a practice playbook of these steps can help prove the processes work as designed.
If a server experiences a technical issue, backup images can make restoring the damaged item less of a challenge. The team will want to choose the best solution for the enterprise, and then setup the backup solution for all application servers from there. After a solution is selected, the team should verify that automated backups are created at necessary intervals. The final step of this phase is testing the functionality by restoring data from backups and validating restored data.
Step 4: Migration/Go-live
When it’s time to go live with a group of applications, it can impact a select group of users or the entire organization. Therefore, it’s important the right parties are aware when their ability to work may be impacted by a migration. When the team is confident about the cutover process, they should formally schedule the application migration by informing all appropriate parties, even if there isn’t any expected downtime.
Schedule and communicate application downtime
The first step is to identify a cutover window with application owners and the user community. If a team is migrating a critical application, a good window would be during off business hours that does not impact shift changes. Before sending out communication about the migration window to the necessary parties, a team will also need to determine and secure go-live resources to make sure all necessary components will be available during the migration process.
Cutover applications to new data center
When actually performing the application cutover, your prep work in the mock migration phase will start to pay off. Following the migration process and tested migration playbook, the team will need to stop the application at the old platform, ensure replication is complete, start the application at the new platform, use and validate the application using test scripts, reroute user traffic to the new platform, communicate when applications are back running and available for the users, and document and track ongoing issues.
Step 5: Decommission/Closeout
Decommissioning unnecessary legacy applications can significantly reduce operating costs, including fees for licensing, specialized SMEs and energy usage; however, the old applications may store data important for regulatory compliance or business needs. With that, a smart decommissioning strategy and a thorough approach can help an organization retire the applications at the right time for the best ROI. The closeout stage involves documenting achieved cost savings as well as changes to the overall environment. This will tell stakeholders the benefits they achieved from decommissioning old equipment and migrating to a new environment. Closeout will also be crucial for running and maintaining the new IT environment.
The application migration methodology has been an invaluable tool to efficiently coordinate data center modernization efforts for various renowned organizations. Executing an application migration plan is a major project that needs to be carefully managed to ensure success. There really is no “silver bullet” to magically move your applications to a new environment, but with these five steps, organizations can carefully and meticulously plan to ensure success and minimize business disruption.