Wednesday, February 1, 2023

 One of the advantages of migrating workloads to the public cloud is that there are well-known patterns to leverage which make the assess->deploy->release path quite predictable. For example, we can talk about the migration strategy identification itself as a pattern that leverages the notion of an AppScore. The idea behind this pattern is that the challenges around missing operational data crucial for studying applications such as recovery time objective, recovery point objective or data privacy, can be overcome by using an application centric view of the portfolio of applications to migrate. This includes a recommended transformation route for each of the application against the 5 R’s model described in the earlier post

The score helps to capture application information, determine the ideal transformation route, identify the risk, complexity, and benefits of cloud adoption, and quickly define the migration scopes, move groups and schedules.

The score is used towards a recommendation based on the following three categories of application attributes:

1.       Risk – which is the business criticality of the application, whether it contains confidential data, data sovereignty requirements, and the number of application users or interfaces.

2.       Complexity – which is the application’s development language, age, UI, or number of interfaces.

3.       Benefit – which is the batch processing demand, application profile, disaster recovery model, development, and test environment use.

There are four phases of iterative data capture, which include:

1.       Signposting – questions that are combined with server data to produce the assessments.

2.       Scoring – questions that produces scores for risk, benefit, and complexity.

3.       Current state assessment – questions that provide a current state assessment of the application.

4.       Transformation – questions that comprehensively evaluate the application for future state design.

Only the signposting and scoring stages are required to receive application scores, assessments and enable group planning.  After the applications are grouped and scopes are formed, the latter two stages are used to build a more detailed overview of the application.

While the migration evaluator helps to create a directional business case for planning and migration, the application centric view helps to bridge the gap between discovery and migration implementation and provide a recommended route to the cloud.

This workflow can be described with the following stages:

1.       Start the discovery and assessment.

2.       Align Applications and servers.

a.       Capture the application and business information.

b.       Import server and technical details.

3.       Obtain recommendations, scoring and costs for each application.

4.       Plan costed schedules using move groups.

5.       Design application migration or transformation activities

6.       Export Application assessment and transformation reports from 3. 4. And 5.

7.       Perform approved migration or transformation activities.

With this pattern, the determination of the recommended migration strategy becomes more predictable.  

 

 

No comments:

Post a Comment