The Doppler Quarterly Summer 2018 - Page 70

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. 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. 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) Migration Velocity • Sort all apps in ascending order of prior- ity scores 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). • 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. 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. 68 | THE DOPPLER | SUMMER 2018 • 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