Technology transitions in the healthcare industry can be challenging because even the smallest hospitals depend on hundreds of applications in a 24X7, always-on environment. In the patient care space, we need to minimize scheduled downtime and can’t afford unscheduled operational disruption. The complexity to manage data center projects is intensified further because every application is different on some level within a hospital. For instance, many of our clients’ IT environments accumulated technologies over several decades, which led to disparate ecosystems and many of the problems they are trying to solve with new data center strategy.
When a healthcare organization has either developed greater computing needs or wants to capitalize on more advanced computing platform solutions (e.g., clouds, colocation and hosting services), my team is brought on to seamlessly migrate applications. This can involve overcoming application roadblocks caused by varying vendor sources, application types, ages, infrastructure requirements, operating systems and versions. To combat this problem, we realized the need for an application migration strategy that helps healthcare organizations avoid unnecessary downtime and achieve the best end result while they are switching to a new computing platform.
A Five-step Application Migration Methodology
From our application implementation and infrastructure experiences, my team and I developed a five-step methodology for migrating applications for health systems looking to move their data center environment to a different platform. Per our approach, the IT team performs a high-level, upfront migration assessment to group applications. Then, the team can proceed by migrating one or several application groups through the five-step migration process shown below.
- 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. To develop a feasible plan, you’ll have to pull together the people, processes and technology needed to move applications. This requires creating a standard discovery document for each application that outlines key features and strategy, creating an architecture diagram, developing an application migration process flow, and securing appropriate migration staff and vendor assistance.
- Mock Migration: This is the step where you test applications and rehearse migration scenarios. It includes creating an application migration playbook with step-by-step instructions and schedules, replicating servers/storage, piloting applications using prepared scripts, and verifying load balancing and high availability.
- Failover Testing: This step has teams test disaster recovery processes and functionality. In this part of the process, teams will rehearse failover/failback, verify restore from backups, and validate applications functionality at each point of the test while still maintaining all production functionality.
- Migration/Go-live: To avoid business interruption, teams will schedule windows of application downtime and go-live support based on application user input, communicate windows of downtime over the appropriate communication channel, and cut over applications to the new data center or cloud platform with the optimized process determined by earlier testing.
- Decommission/Closeout: During this step, the team will retire legacy equipment (including disposing and updating infrastructure management tools), perform any necessary updates to application documentation (including disaster recovery), and provide any necessary organizational asset tracking that could be beneficial to the organization’s business team (including updating budgets and vendor contract terminations).
These steps are an amalgamation of lessons learned from helping health system’s move applications to new computing platforms. Completing the steps for an application group results in a finished deliverable, less user and staff disruption, and lessons learned that can be used for the next group being migrated. For more information about our application migration methodology, please view our white paper, A Five-step Methodology for Application Migration.