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