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 objectively assess so many applications, we use a set of rules to score various application 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 complexity, 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 functional application characteristics. For prioritizing applications, it is important to capture all the essential 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 application 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 applications 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 business cycle, application upgrade cycles, support contract 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 migration 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.
Grouping applications requires dependency information, 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 applications separately, but the type of dependency and tolerance 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 priority scores
- Determine the required number of apps in a particular duration based on the velocity that can be achieved. The duration is typically a migration wave based on various factors, such as grouping of apps by line of business, business function, 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 schedule 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 remaining 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 beginning ). 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 influence 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 subsequent 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, applications may have to be put in a backlog if they do not fit anywhere else in the current 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.
