T2 TECH GROUP

©November 2017 T2 Tech GroupA Five-step Methodology for Application Migration

A best-practices approach for migrating applications to an advanced computing platform

A Five-step Methodology for Application Migration

A Five-step Methodology for Application Migration Page 2

ContentsAn Application Migration Strategy for Healthcare ............................................................... 3

Methodology Overview .......................................................................................................... 3

Initial Migration Assessment ................................................................................................ 4

Map Server Inventory and Applications ............................................................................... 4

Create Application Groups .................................................................................................... 5

Schedule Migration and Estimate Effort ............................................................................. 6

Process for Completing the Five Steps ............................................................................... 7

Step 1: Prerequisite Gathering ............................................................................................. 8

Create Discovery Document for Each Application ......................................................... 8

Design Architecture Diagram ........................................................................................... 8

Create Migration Process Flow ....................................................................................... 8

Secure External Resources, if Required .......................................................................... 8

Step 2: Mock Migration ........................................................................................................ 8

Create/Migrate Servers and Storage .............................................................................. 8

Replicate Servers and Storage ........................................................................................ 9

Create and Perform Test Scripts ...................................................................................... 9

Create Playbook ................................................................................................................ 9

Test Load Balancing and High Availability, if Required .................................................10

Step 3: Failover Testing .......................................................................................................11

Test Failover/Failback .....................................................................................................11

Test Backup/Restore ......................................................................................................11

Step 4: Migration/Go-live ...................................................................................................11

Schedule and Communicate Application Downtime ....................................................11

Cutover Applications to New Data Center .....................................................................11

Step 5: Decommission/Closeout .......................................................................................12

Perform Decommissioning Process ..............................................................................12

Closeout ...........................................................................................................................12

Implement Your Next Application Migration ......................................................................12

Authors and Contributors ...................................................................................................14

Leigh Sleeman ................................................................................................................14

Kevin Torf .........................................................................................................................14

Nikhil Raj .........................................................................................................................14

Paul Conocenti ................................................................................................................14

A Five-step Methodology for Application Migration Page 3

An Application Migration Strategy for Healthcare

The methodology allows organizations to minimize downtime, perfect the process for moving applications during mock migrations, and test and remediate any architectural designs, such as load balancing, load capacity and high availability.

As healthcare providers continue to compile more electronic data and rely heavily on IT infrastructure, CIOs are evaluating the shift towards a variety of modern data center solutions, including remote hosting and cloud services. Using the right computing platform can save health systems millions of dollars and reallocate critical resources towards higher quality patient care. 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.

Even the smallest hospitals host hundreds of applications in a 24X7 environment. In the patient care space that can’t afford operational disruption, there are applications for the electronic health record (EHR), pharmacy, radiology, human resources, finance, risk management and a host of other functionalities. Every application is different on some level, and many environments become aged because they were put in decades earlier and haven’t been upgraded or replaced for reasons such as pending FDA approval. This can create complexities because it can be hard to efficiently move applications that have varying

vendor sources, application types, ages, infrastructure requirements, operating systems and versions.

As the EHR and other critical applications have been integrated in the care process, dependability of the technology has become essential to care teams and the patients they serve. Health systems can’t afford unscheduled application downtime and must minimize scheduled downtime. At the same time, resources are scarce and application migrations must be timely and efficient. By using standard, repeatable and proven best practices, health systems can save themselves from potentially disastrous errors and interruptions.

Methodology OverviewThis white paper outlines T2 Tech Group’s five-step migrating methodology for enterprises looking to shift to a more advanced computing environment (e.g., the cloud, a colocation facility and hosting services). This agile approach to application migration has been used with leading organizations, such as Sharp HealthCare and Verity Health System, and can provide immediate value over the life cycle of a data center modernization project.

IT teams can use our five-step methodology for their next data center modernization project. Each phase of the five-step process includes templated documentation and checklists for the engineering team completing the work effort. To comprehensively outline the methodology, this white paper presents a high-level overview of initial migration assessment best practices and the five steps needed to efficiently move application groups after the initial assessment.

A Five-step Methodology for Application Migration Page 4

Initial Migration Assessment

Figure 1 Sample Server Inventory

An initial migration assessment on the environment is necessary to ensure the effectiveness of the five-step process. This pre-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 estimate 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

Map Server Inventory and ApplicationsTo start off, a full server inventory and application mapping process must be completed. Typically, an extract of all pertinent information is taken from the virtual server environment, and the physical server environment is manually filled in to match. Once the server environment has been audited (CPU, RAM, storage, OS and location), applications are tied to each of the servers listed. This is done through infrastructure/ application team interviews, naming convention checks, and manually logging into any unknown servers to determine application necessities.

Once all teams sign off on a server to application mapping, the next objective to tackle is defining application groups.

Figure 1 depicts a sample inventory developed from an audit of the server environment. This table shows application to server mapping and provides key details about each application within the environment. When determining an optimal migration strategy for migrating applications and the data they contain, this documentation will be a vital reference.

Prerequisite Gathering

Mock Migration

Failover Testing

Migration/Go-Live

Decomm/Closeout

Application Migration

Methodology

Initial Migration Assessment

A Five-step Methodology for Application Migration Page 5

Create Application Groups

Figure 3 Sample Application Grouping

By creating application groups, multiple applications can be migrated concurrently rather than scheduling one application to completion at a time. Furthermore, if more than one application is required to be on the same IT platform, this approach tackles that as well. To accomplish this, each application should be assessed to determine function/ purpose, user count, clinical versus non-clinical, and interfaces. This information is used to determine which applications can or need to be performed concurrently as a group.

When grouping applications, teams will need to account for business and technical drivers to develop an optimal migration schedule. Business drivers include factors such as the need for 24x7 versus 8-to-5 availability, use by supporting staff or type of practice (e.g., the emergency department or Women’s Health). Technical drivers include factors such as physical versus virtual server, storage platform or type of operating system. See Figure 2 above.

A sample application grouping is shown below in Figure 3. As indicated by the asterisks, different groups can be formed for a variety of reasons. Here, Group 1 applications were placed together because they are all non-clinical while Group 2 applications are organized more specifically by their function in the ambulatory care environment.

Teams should allocate enough effort upfront to perform a migration assessment and group applications together by business and/or technical drivers. This will provide some economy of scale without increasing the risk associated with moving multiple applications in a group.

• Application Usage• Application Support Team• Criticality/Tiering• Type of Practice/Application• User Count• Volunteer Groups

Business

• Virtual vs. Physical Environment• Storage Platform• Technical Requirements• Interface Communications• Operating System• Downtime Dependencies

Technical

Figure 2 Ideal Application Grouping Criteria

A Five-step Methodology for Application Migration Page 6

Schedule Migration and Estimate Effort

ID Iterations Duration Start Finish

1 Application Migration 17 wks Mon 8/28/17 Fri 12/22/172 Initial Migration Assessment 5 wks Mon 8/28/17 Fri 9/29/173 Map server inventory and applications 1 wk Mon 8/28/17 Fri 9/1/174 Create application groups 2 wks Mon 9/4/17 Fri 9/15/175 Schedule migration and estimate effort 2 wks Mon 9/18/17 Fri 9/29/176 Application Group 1 12 wks Mon 10/2/17 Fri 12/22/177 Prerequisite Gathering 3 wks Mon 10/2/17 Fri 10/20/178 Mock Migration 3 wks Mon 10/23/17Fri 11/10/179 Failover Testing 2 wks Mon 11/13/17Fri 11/24/1710 Migration/Go-live 3 wks Mon 11/27/17Fri 12/15/1711 Decommission/Closeout 1 wk Mon 12/18/17Fri 12/22/1712 Application Group 1 Migration Complete 0 days Fri 12/22/17 Fri 12/22/17 12/22

Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep OctQtr 3, 2017 Qtr 4, 2017 Qtr 1, 2018 Qtr 2, 2018 Qtr 3, 2018 Qtr 4, 2018

Figure 4 Sample Sequenced Application Migration Schedule

Each application group needs to be scheduled for migration within a project plan/charter. An application group migration schedule is created from resource availability and interdependencies found as well as considering the efforts required from those resources based on each applications’ complexities. No two application groups are the same; therefore, a priority or sequencing needs to be determined. It’s easier to migrate low-hanging fruit application groups first and then tackle the critical application migrations after teams are familiar with the process. Also, schedules will need to be determined if vendors are involved in the migration, since allocation of resources needs to occur from their side as well.

Using this approach to help define all the requirements necessary in the initial assessments, a team should have the appropriate information to start migrations of all application groups based on the selected schedule within the organization.

The below Gantt chart shown in Figure 3 depicts a sequenced migration schedule, as the output from the work listed above. This document is a living document

updated on a regular, cyclical basis to align with any changes to strategic initiatives and resource availability (including vendor resources) and any amended durations and interdependencies.

A detailed effort/work estimate assists in projecting out application migration resource needs. High-level steps are involved with each application migration as well as each resource role needed to complete an application group migration. These resource requirements are built out via analogous estimates and developed based on direct input from project managers, architects, analysts and engineers who have the appropriate knowledge and experience.

Migrations range from minimal effort (small applications with minimal integrations and clinical impact) to extensive migrations. The effort estimate table shown below in Figure 4 depicts a sample effort calculation for completing an application group migration. The specific estimates in a project will vary based on the organization’s environment and requirements.

A Five-step Methodology for Application Migration Page 7

Process for Completing the Five Steps

Figure 5 Sample Effort Calculation

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

When incorporated into T2 Tech’s hybrid-agile project management approach, the iterations also empower teams to work more effectively. Using this framework, a team can 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. This flexible approach allows teams to streamline project execution before closeout and better adapt to unexpected roadblocks.

A Five-step Methodology for Application Migration Page 8

Step 1: Prerequisite Gathering

Step 2: Mock Migration

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. The stage includes creating a standardized discovery document for each application that outlines key features and strategy, creating an architecture diagram for each application, developing an application migration process flow, and securing appropriate migration staff, including any needed vendor assistance.

Create Discovery Document for Each Application Standardized documentation for each application should include the following items:

• Application leads • Infrastructure leads • User base • Criticality • Authentication • Back-up strategy • Application interdependencies • Interface requirements • Current and future server information • Required database features • Application delivery method

Design Architecture Diagram To create architecture diagrams, the team will need to identify the following items:

• New IPs • All servers by naming standards • Port communication for network design • Core service dependencies • Disaster recovery (DR) strategy

Create Migration Process Flow To create an application migration process flow, the team will need to complete the following actions:

• Document sequence of steps • Document party(s) responsible• Document task location

Secure External Resources, if Required Depending on the resources available at the organization, a project manager may have to estimate and secure required external labor and vendor assistance. When securing these resources, teams may have to complete the following tasks:

• Create and validate migration SOW with vendor • Negotiate quote • Issue PO request and tracking • Perform best practices for vendor management

After 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). For the virtual environment, perform a migration using a suitable V2V utility. For the physical environment, if there are no necessities to stay on physical, a team can perform a migration by using a suitable physical to virtual (P2V) utility. If there is a requirement for servers to stay physical, each server needs a decision on whether to take downtime and relocate or acquire new hardware and storage for the data center.

If an environment is not on the latest technical standards, a team might want to consider installing an application on a net-new environment, which would include the latest approved operating systems agreed upon by a technical review board. This would allow the team to upgrade applications if they are on unsupported versions.

A Five-step Methodology for Application Migration Page 9

Replicate Servers and StorageThe process for replicating servers and storage requires the following tasks:

• Acquire and utilize P2V and/or V2V solution for server replication

• Migrate data using file/block copies where necessary

• Validate servers/storage replication was successful • Upgrade virtual hardware drivers where necessary • Create appropriate network communications in the

destination• Assign VMs to proper port group • Power on test copies of VMs• Assign new IP addresses and hostnames where

necessary• Perform server integrity testing (DNS, AD, network

communications, etc.) • Configure agents, if necessary (backup, SCCM,

antivirus, etc.)

Create and Perform Test ScriptsMake 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 PlaybookThe migration playbook is a sequenced set of tasks to provide play-by-play efforts needed for the resource(s). From the work completed during the initial migration assessment to determine the application migration process flow, the team will use the documented sequence of tasks, party(s) deemed responsible

and the task location to develop the playbook. As an additional key part, 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. In the end, a perfect playbook will show the executive team (1) the migration has been practiced, (2) what resource(s) are involved in the initiative and (3) no surprises will occur during the production migration.

Figure 6 depicts a sample application migration playbook from a team that has plotted out tasks. When the playbook is performed, the necessary columns outlined are filled with times and updates.

The mock migration step is the most important part in this methodology because it allows the team to practice migrating the application system without impacting the production environment. This will let the team perform the migration process as many times as required until all steps are documented correctly.

Figure 6 Sample Playbook

A Five-step Methodology for Application Migration Page 10

Test Load Balancing, Load Capacity and High Availability, if RequiredSince each application is separately architected, some might have technical dependencies for load balancing or high availability. These configurations should be set up before the final production migration, and the steps need to be captured within the migration playbook. Once configured, these functions should be tested against the test copy 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.

Figure 7 depicts end users going through a load balancer to efficiently route network traffic for application access. In this particular scenario, the three application servers are highly available, so if any of the applications server(s) go down, the others take

over the processing load. These two infrastructure designs for applications require extra quality testing since they are typically only utilized for applications that are mission critical and require 24x7 availability.

Step 3: Failover Testing Failover testing is a critical step to validate the DR functionality for business continuity solutions. In this step, the technical team will test failover/failback from a server perspective and use backup/restore methods if required. Concurrently, the application team will be testing the necessary applications that meet these needs and validating application functionality at each point of the test.

PHX – NewCo Primary Datacenter

Frontend (1130) ManagementUntrusted (VLAN) Backend (1131)Web Test (1132)

ExtUser

TCP 80TCP 443

DNS SCCM

CB NTP

SMTPAD

DMZ

Intranet

Workstations

TCP 1433

PHX-RMP-APP01(10.81.1.54)

PHX-RMP-APP02(10.81.1.55)

PHX-RMP-APP03(10.81.1.56)

App

PHX-RMP-SQL01(10.81.1.57)

DBPHX-RMP-APP01T

(10.81.1.58)

App

PHX-RMP-SQL01T(10.81.1.59)

DB

Load Balancer

80 443

TCP 80TCP 443

Figure 7 Sample Architecture Diagram

If the testing of architectural decisions (e.g., load balancing, high availability, disaster recovery) fail, then the team must remediate those failures as well as correct the steps in the application migration playbook to reflect the new changes. This playbook must be practiced until a successful test of all applicable architecture decisions occurs.

A Five-step Methodology for Application Migration Page 11

Step 4: Migration/Go-live

Step 3: Failover TestingTest Failover/Failback Failover is the ability to switch application processing from a primary to a secondary location. 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. Since both of these capabilities need to be tested, creating and performing pilot simulations with a practice playbook of these steps helps prove the processes work as designed.

Test Backup/Restore If a server experiences a technical challenge, backup images can make restoring the damaged item less of an issue. The team will want to choose the best solution for the enterprise and then setup the backup solution for all application servers. After a solution is selected, the team will need to verify that automated backups are created at necessary intervals. The team will then want to test the backup functionality by restoring data from backups and validating restored data.

Going live with a group of applications can impact a select group of users or the entire enterprise. Therefore, it’s important to communicate to the right parties when their ability to work may be impacted by a migration. When the team is confident about the cutover process, they need to schedule the application migration, even if there isn’t an expected downtime required, by informing all appropriate parties.

Schedule and Communicate Application Downtime The team will need 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 an off hour that does not impact shift changes. Once a window of time to perform the migration in has been determined, the IT team will need to communicate to the right parties through the appropriate channel. Before sending out the scheduled communication about the migration window,

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, prep work in the mock migration phase will start to pay off. A team can follow the migration process and utilize the tested migration playbook developed during the mock migration step. During this process, 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.

A Five-step Methodology for Application Migration Page 12

Step 5: Decommission/Closeout

Implement Your Next Application Migration

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. Therefore, 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.

Perform Decommissioning Process At this stage, the team should have already determined which servers were part of an application and the applications that should be decommissioned. Therefore, for this phase, the team will need to follow decommissioning steps for virtual and physical servers. This should include the following actions:• Verify checklist of servers to decommission • Initiate change control to decommission all servers

• Remove servers from backup software/schedule• Remove servers from antivirus software • Remove A records from DNS server • Remove alerts from the server monitoring solution • For physical servers – pull network cables, unrack

servers and destroy data on disks • For virtual servers – delete VMs from the

management server • Delete LUNS/NFS/CIFS shares associated

with server • Update all application documentation, if necessary • Cancel existing vendor obligations/contracts,

if necessary • Revise budget and deliver report of completion

CloseoutDuring this stage, the team will complete performance cost measures, which include ensuring any new contracts are set and budgeted in the upcoming financial year, verifying that the inventory has been updated, and updating cost changes. It may also be useful to implement an operations monitoring management system that will help keep track of the new environment.

Our application migration methodology has been an invaluable tool to efficiently coordinate data center modernization efforts for Sharp HealthCare, Verity Health System and other nationally renowned providers. Using this approach to coordinate an application migration allows teams to efficiently build a solid application strategy; validate the strategy through testing; and go-live with minimal business interruption, a minimized project cost, and an optimal result.

Our process also makes application migration into an iterative process, which allows team members and stakeholders to effectively address scope changes, increase team productivity and take advantage of

resources without investing in unneeded technology. Application-by-application, the five-step process ensures optimal value is achieved each step along the way with minimal downtime.

To tackle each iteration in the application migration process, our team uses a hybrid-agile project management methodology. A PMI-backed Waterfall model for upfront planning ensures appropriate processes for a sound governance framework, a fixed scheduled timeline, a detailed charter, and budget controls and metrics. Then, during execution, an iterative agile approach facilitates organizational transparency, continuous reflection, a flexible

A Five-step Methodology for Application Migration Page 13

schedule and overall team empowerment. With sound processes to organize and maximize team efforts, this methodology ensures important application migrations are implemented as efficiently as possible.

Contact usWorking with our team, you can gain the following benefits:

• Learn how to use this approach to coordinate an application migration with a strong strategy

• Validate migration strategy through testing• Utilize existing resources effectively and avoid

investing in unnecessary technology• Use a hybrid-agile project management methodology

to ensure project efficiency and go-live with minimal business interruption

• Build or receive consultation on infrastructure requirements

If you are interested in learning more or seeing if our application migration strategy can bring value to your organization, contact us for a free consultation at 424-212-8900 or info@t2techgroup.com.

ABOUT T2 TECH GROUP

T2 Tech Group specializes in tackling difficult technology challenges and transforming IT liabilities into valuable assets for clients in a range of industries. Since its founding in 2006, T2 Tech has built a reputation for delivering high-quality technology consulting and management advisory services to executives and IT leaders in a range of industries. Unlike many consulting firms, T2 Tech has no financial interest in vendor selection, freeing the company to focus completely on realizing customer goals. At T2 Tech, we advocate for our clients; approach each project with no bias; and practice the highest levels of integrity, experience and expertise. For more information about T2 Tech Group, visit t2techgroup.com and connect with us on Twitter @T2TechGroup.

A Five-step Methodology for Application Migration Page 14

Leigh Sleeman, Author Leigh Sleeman is an experienced program manager with a 15-year career in healthcare information technology. Since joining T2 Tech in 2012, he has championed multiple projects, including large VDI, storage and network initiatives for Kootenai Health and a datacenter migration effort for Sharp HealthCare. In his most recent role before joining T2 Tech, Leigh was an IT PMO manager at UCLA Health Systems. Prior to that, he acted as a program manager during the build of the 520-bed Ronald Reagan UCLA Medical Center. For this, he successfully orchestrated all IT activities and administered a $60+ million IT budget.

Kevin Torf , AuthorManaging Partner Kevin Torf is an information systems executive with a 30+ year career. In 2012, Kevin became a managing partner of T2 Tech Group after merging the consulting division of Inventtrex into T2 Tech. He specializes in large-scale IT project design, procurement and implementation. He offers experience in executive-level technology consulting involving data centers, server farms, storage and backup systems, security, video messaging and VoIP systems.

Nikhil Raj, AuthorNikhil Raj is an experienced healthcare technologist. His past successes encompass medical interoperability projects that included vital signs technology, lab results systems, fetal monitoring and medication dispensing, and his programming experience includes coding and debugging in Java, C and C++. At T2 Tech Group, he facilitates and manages clinical projects in all aspects of implementation and leverages his clinical applications expertise to help health systems improve their EHRs. In his most recent position before joining T2 Tech, Nikhil was a technology architect for Women’s Health at Cerner Corporation.

Paul Conocenti, ContributorPaul Conocenti has over 20 years in healthcare IT leadership, including CIO and CTO positions with complex academic medical centers, integrated healthcare systems, public statewide health information exchange networks and in NCI-Designated Cancer Centers and Research Institutes. In addition to his experience in healthcare, he has over 20 years of IT leadership experience in the Financial Wall Street industry. At T2 Tech Group, Paul holds the title of partner and is responsible for delivering IT strategy, oversight, architecture direction and solutions to top clients.

T2 TECH GROUP

21250 Hawthorne Boulevard, Suite 250 | Torrance, CA 90503www.t2techgroup.com | 424.212.8900