This blog details some important considerations and challenges associated with the lift and shift method, based on our real-world experiences moving both custom and packaged (commercial) legacy applications to Microsoft Azure.
As expected, the challenges to moving legacy business-critical applications span technical, business operations, and business and IT organization domains. The key points I’ll discuss today include:
- Criticality of establishing a shared vision/goals for a cloud migration project
- Definition of the cloud availability and recovery strategy upfront
- Conducting a technical feasibility assessment
- Assessing the business operations impact
- Building an effective migration plan
- Structure the plan with well-defined entry and exit gates for the key stages
- Prepare for the implementation surprises (expect the unexpected)
- Include continuous monitoring in the execution of the migration plan and post cutover
- Define the system cutover plan upfront and test as a much as possible before actual cutover
Establish a Shared Vision
The territory of legacy systems is often populated with many stakeholders (both from business and IT) that often have very different goals, risk profiles, and expected outcomes of the migration effort. Critical information about the legacy system architecture, operations, etc. is often not written down and exists only in the minds of the key stakeholders. Documentation is either insufficient or missing entirely.
This is typically because legacy business application suites are acquired (or customer developed) over a long period from various vendors. Some of those vendors may be out of business or resources involved in custom development may no longer be available for any support. For lift and shift migrations, a key requirement is to find an executive management sponsor or project owner with the authority to unite the various groups, make key decisions and clearly define the business and technology goals and expected outcomes of the migration effort that all groups can be aligned with.
Having a clearly defined lift and shift project structure with key roles and responsibilities delineated is a must.
These issues should be discussed upfront and partnerships among stakeholder groups should be established towards accomplishing the final goal of migration under the leadership of the project owner. Having a clearly defined lift and shift project structure with key roles and responsibilities delineated is a must. Appropriate budget and resources must be allocated for executing tasks related to this partnership.
Change management approaches for the legacy application end users are also a key concern that must be considered in the planning of the migration effort. Ignoring the organizational impacts of legacy application migration imperils the ability of the migration project team to accomplish the final goal of a fully functional system in the cloud.
Plan for Availability and Recovery Upfront
Migrating legacy applications to a new environment they were not originally designed for needs careful evaluation with respect to high availability and disaster recovery. The way these applications (especially commercial off the shelf (COTS) packages) function may rule out some of the standard cloud platform availability services that can typically be leveraged in the cloud environment for custom applications.
Conduct a Technical Feasibility Assessment
From a technical standpoint, legacy business applications may have several cloud migration “risk factors,” including dependencies on Windows OS versions and frameworks that are out of support, no direct product upgrade paths, and even cases where the original application vendors may no longer provide support due to changes in product strategy, merger/acquisitions of the vendor company, or the vendor has gone out of business.
Determining the feasibility of migrating legacy applications, particularly COTS-package applications, is very critical. Prior to going down the path of migration, a fact-based assessment of the technical risk factors and available migration options must be conducted and a firm go/no-go decision on lift and shift (vs. retire/replace with a new system) should be made as early as possible in the project.
The feasibility assessment needs to be thorough with consideration of all architectural components including: proprietary data persistence storage mechanisms or data exchange communication protocols, add-ons or other vendor external product dependencies, customizations implemented for the specific client business processes, etc. Any gaps in conducting the feasibility assessment of the migration can potentially render the whole effort unsuccessful. Building the partnerships among legacy systems stakeholders discussed earlier is key to supporting this analysis.
Some important aspects of this feasibility assessment include:
- Target Deployment Environment Compatibility Assessment: Examine all system upgrade paths and supporting platform system components to rule out any basic incompatibility issues in deploying the migrated applications in the cloud environment. For example, if the legacy application is a COTS product, is there a version that runs on the available OS and Database platforms in the desired target cloud deployment architecture? Another important area to assess is the required connectivity between the application (or applications) to be migrated and can the types of required communications methods be supported in a cloud virtual network environment with potential connections back to the on-premises network and applications. A related key consideration is latency and authentication/authorization issues associated with moving legacy client/server-based applications with thick clients to a cloud environment. You’ll need to consider how the end users will connect to the systems (ex: Virtual desktops) and do things like export data and reports from the legacy system back onto their local PCs.
- Security and Compliance Assessment: Clearly identify the security and compliance requirements for the system and identify what cloud-based controls and mechanisms will be needed to meet these requirements. Map out the key security and compliance scenarios and verify whether the new cloud environment will meet these scenarios.
- Performance Assessment: Creating a list of business transactions that are representative of the different workloads is essential. Define response time requirements for these business transactions based on business needs and the current system’s performance Service Level Agreements (SLAs). Performance feasibility needs to determine how these SLAs can be met in the new cloud environment.
- Scalability Assessment: Especially for COTS-packaged applications, what are the available options for scaling (scale out or scale up)?
- Availability Assessment: Again, for COTS-packaged applications in particular, conduct analysis of possible failure scenarios and determine what mechanisms are available for early detection of failures and potential options for recovery/restart to meet required SLAs, Return to Operations (RTO) and Restore Point Objectives (RPO) requirements.
- Data Migration Assessment: The lift and shift method may include first time and incremental data migration as well. Detailed analysis of the data migration scenarios for the applications is required, and the amount of time required for the migration and its feasibility during the cutover time window must be assessed.
- Production Cutover Method Assessment: Based on the type of business application, the cutover strategy can vary significantly. Consider the constraints that interdependence between the migrated applications and remaining on-premises applications will have on the cutover approach. These can determine if the migration can be performed incrementally or must be done all at once. Determine if it’s possible to have the migrated system in the cloud run in parallel with the on-premises system. Can the parallel operations support running entire business functions or selected portions of business functions? You’ll also need to consider what resource (technical, staffing and budgetary) requirements exist for the cutover strategy, as well as the overall cost and productivity impacts to ongoing business operations.
Conduct a Business Impact Assessment
In addition to performing the technical assessment to determine the appropriate lift and shift approach, it is also important to consider the business operational impacts of the migration effort. This impact can be experienced during both the migration and post-migration stages of the project. Some key items to consider include:
- Operational Impacts: What are the new system’s operational dependencies in terms of the business users’ skills, support and operational costs? This would determine operational feasibility of the new cloud-deployed system.
- Staffing and Vendor Impacts: Prepare a list of internal staff resources and roles required for performing the migration and a list of external parties, including legacy system product vendors. Evaluate the costs of obtaining those resources.
- Schedule Impacts also need to be considered. This entails determining the timeline and the schedule based on the availability of all the resources involved, factoring in the interdependencies of various activities within each work stream and across work streams. Allowing calculated room in the schedule to accommodate the unplanned delays in the availability of the resources, and assess the potential delays in dependent tasks and the impact of the business constraints related to cost and timing. This makes the drafting of the migration timeline and schedule a complex process that needs serious effort and commitment.
- Return on Investment (ROI) Assessment: Before launching the migration effort, perform a thorough analysis of the potential ROI, factoring the results of the technical assessment and the business impacts assessment. It is critical that the effort of undertaking the application migration makes business sense from both a total cost of ownership and operational efficiency perspective.
Build an Effective Migration Plan
Business and technical ownership of legacy application suites are spread across multiple entities and teams. While planning for migration of these apps, there are inherent dependencies across internal and external teams. Creating a comprehensive application cloud migration plan that captures the essence of the entire roadmap, timeline and schedule is the key difference between success and failure.
Define Entry and Exit Gates
Migration of legacy applications must be carefully managed to minimize the disruption to business operations. One way to ensure that migration plans progress in a stable way, is to have well-defined entry and exit gates for each phase of the migration, including cloud architecture deployment definition, initial cloud environment configuration, deploying initial test versions of the migrated application to the new environment, and so on.
Each gate should have well-defined entry criteria that must be reviewed and agreed to by all the stakeholders, and approved by the migration project owner. All team leads (technical and business) that make up the migration team are also required to sign off at each entry/exit stage. Along with the entry/exit criteria, key technical, cost and schedule risks must also be identified and managed throughout each phase of the project.
Expect Implementation Surprises During Migration
Migration to the cloud environment, especially for COTS-product based applications may uncover previously unanticipated technical surprises, often due to the lack of information/knowledge on the legacy systems and their sometimes-hidden architecture dependencies on the original platforms they were designed to operate on. Consider these types of risks when developing the migration plan and include planning for risks that the vendors of these COTS applications bring in.
Careful and upfront planning in defining the ownership of the final goal, feasibility assessment, master plan and milestone checklists will reduce implementation surprises.
Perform Continuous Verification
In legacy projects like these, there is a tendency to wait for a complete deliverable before verification activities begin. This is partly to do with how verification planning is laid out, and partly the mindset of initiating verification on having a complete deliverable. This adds to uncertainties that are quite difficult to resolve later in the schedule. Legacy migration would thus need continuous verification and validation that provides timely feedback for the course correction.
Generally, it is difficult to adopt parallel run with legacy application cutover because of the design constraints. This situation brings in two specific challenges; first – the cutover time window will be short, secondly the rollback from the cloud to an on-premises environment is a difficult composition.
Extra attention and careful planning can help alleviate some of these difficulties of cutover. Important aspects to capture in the plan are:
- Cutover tasks schedule, execution duration, owner(s) and timeline
- Go / no-go verification checklist and test plan
- Makeup of the post go-live stabilization team
- Execution of disaster recovery fire drills
- Consolidation of production operational procedures
- On-going production support as Managed Services
The lift and shift method of migrating the legacy applications to a cloud environment is a way to achieve cloud computing benefits for applications not originally designed for the cloud. These benefits include increased availability, cloud scale performance and total cost of ownership. The realization of lift and shift migration goals depends upon how much detailed planning, feasibility study and impact analysis have been performed. This article provides some pointers to such detailed and elaborate planning exercise.