Skip to content
CTP is part of HPE Pointnext Services.   Explore our new services here →
  • The Doppler Report
Cloud TP Logo
  • Thought Leadership
  • Clients
  • Services
  • Careers
  • Contact Us

Cloud Technology Partners

CLOUD SERVICES

  • The Cloud Adoption Program
  • Application Migration
  • Software Development
  • Infrastructure Modernization
  • DevOps & Continuous Delivery
  • Cloud Security & Governance
  • Cloud Strategy Consulting

TECH DOMAIN

  • Amazon Web Services
  • Google Cloud Platform

ABOUT US

  • Company Overview
  • Leadership Team
  • Partners
  • News & Recognition
  • Announcements
  • Weekly Cloud Report
  • Client Case Studies
  • Events

CAREERS

  • Join Us
  • Job Opportunities
 Cloud Technology Partners
  • Doppler Home
  • Contributors
  • Client Case Studies
  • Podcasts
  • Videos
  • White Papers
  • Quarterly
  • Events
  • Subscribe

Sequencing and Wave Planning for Large-Scale Application Migration

A prescriptive planning approach for migration sequencing in your large-scale public cloud migration project.
Prakash Patil Principal Architect
Share this 
doppler_mail1

For more content like this, Get THE DOPPLER
email every Friday.
 
Subscribe here  chevron_right

When an enterprise has a large portfolio of applications slated for migration to the public cloud, there is a need to identify the sequencing and scheduling aspects of the migration.

In this article, we will describe a real-world planning exercise we undertook, highlighting the various elements essential to any planning and sequencing operation.

The following framework was used for migration sequencing:

  • Develop a rules and scoring system that assigns a score to an application based on preferences, such as less complex applications should migrate first, and dependent groups of applications must be migrated together.
  • Determine the scale and velocity of the migrations, including how many applications can be migrated in a given time period.
  • Create a schedule with preferences for what days migration can and cannot be done – such as, no migrations can be performed on holidays.
  • Create a backlog and iteratively apply any schedule preferences to select applications for migration — similar to a development project where work from a backlog is added in a sprint for development.

Rules and Scores

Suppose we have 100 applications to migrate in a given time frame. To objec­tively assess so many applications, we use a set of rules to score various appli­cation components. Each rule has a base score for a specific characteristic of an application component, and then additional points are added to indicate various aspects of the characteristic – risk, complexity, effort, etc. Rules can use weights to influence preferences when base scores are similar.

All scores are added up and the final scores indicate the order of migration. The lower the score, the easier the application is to migrate (meaning less complex­ity, less risk and lower effort required), and the earlier it should be placed on the schedule.

Some criteria for rules are listed below:

  • Business Criticality
  • Custom Developed (In-house)
  • Application Tiers
  • Complexity
  • Readiness
  • Number of Servers

Some 30 or so rules were used on this specific engagement, including technical, business and func­tional application characteristics. For prioritizing applications, it is important to capture all the essen­tial characteristics you deem important. Rules may be modified or new ones added based on the specific requirements of a migration project.

The general logic should reflect the preferences of the business. For example, an application with non-compliant OS will need additional effort to migrate, so it may be necessary to migrate the appli­cation early on to realize some of the benefits, such as cost of a migration program.

At the end of this exercise, you will have a list of appli­cations and their scores. When you sort this list by score, you will get the preferred order of migration.

Migration Velocity

Migration velocity is the rate at which apps can be migrated. Various factors have to be considered to determine and plan for migration velocity. Typically, the program duration derived from the business case is the driving factor, but others could include busi­ness cycle, application upgrade cycles, support con­tract cycle, required skills and available staff. For example, migrating one application with a rehost migration pattern and three environments may need a few days given the set of resources. CTP uses the concept of a workbench (a self-contained group of staff dedicated to a specific migration pattern who have all the necessary know-how).

Let us postulate that one app with ten servers and three environments (Dev, QA and Prod) can be migrated in three days with one workbench.

Grouping and Scheduling

Now we have a migration priority score, the migra­tion velocity and a calendar with preferred days for migration (or, alternately, preferred blackout days). We use grouping and scheduling rules to lay out the applications on a timetable, given all the information at hand.

Read now
How a technology company reduced operating expenses by 50% on AWS + 17 other cloud transformation stories.

Grouping applications requires dependency informa­tion, gathered during the application assessment. This defines which groups of applications should be migrated together, based on strong dependencies the various applications have on each other. Even with dependency, it may be possible to migrate applica­tions separately, but the type of dependency and tol­erance for latency, etc., drive the decision process. We will skip the details on this for now, and move on to assuming that groups of applications with strong dependency must be moved together.

Through an iterative process, we group and sort applications using the following rules, and begin the wave scheduling process. Applications are grouped and put into waves (a logical grouping of applications in a duration):

V1 of wave schedule (scores)

  • Sort all apps in ascending order of prior­ity scores
  • Determine the required number of apps in a particular duration based on the velocity that can be achieved. The dura­tion is typically a migration wave based on various factors, such as grouping of apps by line of business, business func­tion, etc.
  • Continue the grouping for the remaining servers through the remaining durations
  • We now have V1 of the wave schedule, listing apps and waves

V2 of wave schedule (schedule preferences)

  • Move apps to a specific wave if a sched­ule preference is indicated

V3 of wave schedule (dependencies)

  • Group apps together based on their dependencies
  • For selected apps in wave x, move the dependent apps into that wave (if they are not already there)
  • If the number of apps in a wave exceeds the expected migration velocity, adjust/move nondependent apps to the next wave, and continue through the remain­ing waves

V4 of wave schedule (complexity, app tiers)

  • Irrespective of the scores, we should make sure we are migrating a good mix of less complex and more complex apps in a duration (we do not want to leave all complex apps at the end or the begin­ning ). When the migration velocity is calculated, an additional factor is the mix of complexity in each time period. Complex apps may require additional staff, additional duration, reduced downtime, etc., and these things influ­ence the velocity.
  • Rebalance the wave with the desired mix of less complex and more complex apps. What we generally recommend is to start and end with less complex apps, and add more complex apps in subse­quent waves. This logic may need fine tuning based on specific requirements.

Figure 1 displays an example of a summary wave schedule.

Detailed Wave Schedule Rules

Now that we have the initial migration wave plan, we still need to create a migration execution plan that lays out activities per day. As we already have the list of applications and the desired wave, it is now a matter of laying out these apps on a calendar.

We used the following rules for creating the detailed schedule:

Rule 1 – For every application, the migration sequencing must follow: first, Dev; next, other non production environments; finally, the production environment.

Rule 2 – For every environment of an application, add into the schedule a gap of one week before the next environment is migrated. This allows for rollback, additional time for testing and adjusting migration procedures. Based on the velocity of migrations, it may not be possible to fit all applications within a wave, and further adjustment may be necessary, including moving apps to the next wave or to the backlog.

This concludes the wave planning exercise. Realistically, for every wave, there is a preparation phase (of at least one prior wave), where there may be a need to fine tune the process. With situations where a rollback is required, applica­tions may have to be put in a backlog if they do not fit anywhere else in the cur­rent period/schedule.

Figure 2 displays an example of a detailed wave schedule (partial view).

Conclusion

A large-scale application migration requires careful planning for sequencing. With an objective assessment and analysis, and a consideration of client specific variations and requirements, we are able to apply a method to the madness. While the logic of the rules and scoring mechanism may differ from client to client, it is important to define that mechanism upfront, so a consistent set of rules can be applied. It goes without saying that fine tuning and adjustments may be required as you move along the migration journey.

In summary, using an approach of systematic analysis will allow the migration project to provide visibility and flexibility, and will result in greater success.

Contributors to this article include Andy Clark.

Share this


Related articles

 

Enterprise Data Lake Architecture: What to Consider When Designing

By Sudi Bhattacharya

 

5 Steps to Building a Cloud-Ready Application Architecture

 

Refactor vs. Lift-and-Shift vs. Containers

By David Linthicum

Related tags

Application Migration   Cloud Adoption   How To

Prakash Patil

Full bio and recent posts »



Find what you're looking for.

Visit The Doppler topic pages through the links below.

PLATFORMS

AWS
CTP
Docker
Google
IBM
Kubernetes
Microsoft Azure
OpenStack
Oracle
Rackspace

BEST PRACTICES

App Dev
App Migration
Disaster Recovery
Change Management
Cloud Adoption
Cloud Economics
Cloud Strategy
Containers
Data Integration
DevOps
Digital Innovation
Hybrid Cloud
Managed Services
Security & Governance

SUBJECTS

Big Data
Blockchain
Cloud Careers
CloudOps
Drones
HPC
IoT
Machine Learning
Market Trends
Mobile
Predictive Maintenance
Private Cloud
Serverless Computing
Sustainable Computing
TCO / ROI
Technical "How To" Vendor Lock-In

INDUSTRIES

Agriculture
Energy & Utilities
Financial Services
Government
Healthcare
Manufacturing
Media & Publishing
Software & Technology
Telecom

EVENTS

CES
DockerCon
Google NEXT
Jenkins
re:Invent


 

Get The Doppler

Join 5,000+ IT professionals who get The Doppler for cloud computing news and best practices every week.

Subscribe here


Services

Cloud Adoption
Application Migration
Digital Innovation
Compliance
Cost Control
DevOps
IoT

Company

Overview
Leadership
Why CTP?
News
Events
Careers
Contact Us

The Doppler

Top Posts
White Papers
Podcasts
Videos
Case Studies
Quarterly
Subscribe

Connect

LinkedIn
Twitter
Google +
Facebook
Sound Cloud

CTP is hiring.

Cloud Technology Partners, a Hewlett Packard Enterprise company, is the premier cloud services and software company for enterprises moving to AWS, Google, Microsoft and other leading cloud platforms. We are hiring in sales, engineering, delivery and more. Visit our careers page to learn more.

CWC-blue-01

© 2010 - 2019 Cloud Technology Partners, Inc., a Hewlett Packard Enterprise company. All rights reserved. Here is our privacy policy CTP, CloudTP and Cloud with Confidence are registered trademarks of Cloud Technology Partners, Inc., or its subsidiaries in the United States and elsewhere.

  • Home
  • Cloud Adoption
  • Digital Innovation
  • Managed Cloud Controls
  • The Doppler Report
  • Clients
  • Partners
  • About CTP
  • Careers
  • Contact Us
  • Most Recent Posts
  • All Topics
  • Podcasts
  • Case Studies
  • Videos
  • Contact
We use cookies to provide the best experience on our website. You can change your cookie settings at any time, otherwise, we assume you are OK to continue.Continue