The Cloud Migration Use Case Guide is a process. It is a process of identifying, evaluating, and migrating on-premise applications to the cloud using SaaS solutions and cloud technologies. This process aims to improve the quality of service provided to both customers and employees. Migration to the cloud allows organizations to improve compliance, performance, productivity, and service management while optimizing cost and reducing time to market.
As in the Application Rationalization use case, Cloud Migration identifies which applications should be tolerated, migrated, invested in, or eliminated. Cloud Migration builds on this assessment to identify a migration strategy in the Amazon 6Rs. Cloud Migration can be delivered as a once-off initiative but is often part of a continuous process to ensure that applications are best aligned to enable business capabilities.
Amazon 6Rs are:
Rehosting : Otherwise known as “lift-and-shift.” This strategy involves moving applications from the on-premise environment to the cloud without modification. It is commonly used to migrate large-scale legacy applications to meet specific business objectives such as an accelerated product launch timeline.
Replatforming : Sometimes referred to as “lift-tinker-and-shift.” The re-platform strategy involves moving applications almost as-is but replacing some components to take advantage of the cloud.
Repurchasing : This strategy involves decommissioning the application and replacing it with a cloud-based version typically SaaS-based.
Refactoring / Re-architecting: This strategy calls for a complete overhaul of an application to adapt it to the cloud. It is valuable if you have a strong business need for cloud-native features, such as improved development agility, scalability, or performance. Refactoring often involves breaking up the application into independent services and transitioning to a microservices architecture.
Retire : During a migration project you can identify redundant applications, and shutting them down can represent a cost saving. This is the primary purpose of the Application Rationationalization use case.
Retain : Usually, this means “revisit” or do nothing (for now).
This article covers the Ardoq approach to Cloud Migration, the scope, the implementation rationale, and how to implement it in practice.
Purpose, Scope, and Rationale
Purpose
Cloud Migration illustrates how organizations can leverage the value of the cloud to improve services, respond to demand, and avail of modern technology stacks. The Cloud Migration process identifies candidates for migration and opportunities for SaaS migration to facilitate the development of relevant business cases and impact analysis processes. Thus enabling organizations to identify the most effective way to host applications.
Cloud Migration assists organizations in answering the following questions:
Which applications in my organization are viable candidates for the cloud vs a SaaS alternative?
Can we identify all the interconnected infrastructure, integrations, and capabilities for each of my applications targeted for cloud migration?
Can we reduce the amount of CAPEX to our application portfolio while maintaining or improving the same level of service?
How do I manage the impact, risk, and stakeholders of doing Cloud Migration?
Cloud Migration utilizes the components and references that are established as part of the following use cases:
However, the Metamodel does require the addition of a number of new fields to the Application component.
Scope
The Cloud Migration Use Case Guide is scoped to identify applications that do not reside in the cloud and should be considered for migration to the cloud or a SaaS alternative. This use case does not focus on application rationalization, cloud optimization, or application modernization as those processes typically occur outside of a cloud migration initiative.
Cloud Migration focuses on the rehosting or re-platforming of applications in either a hybrid or full cloud implementation. It also focuses on the repurchasing of the application as a consideration to repurchase the application as a SaaS alternative. Through migration, we look to host applications and data in the most effective IT environment possible, based on factors such as cost, performance, and security.
The primary focus of this use case is to provide stakeholders with a list of actionable Cloud Migration candidates to facilitate further business case and impact analysis processes on an individual application basis.
Rationale
The objective of the Use Case is to capture information through the Cloud Migration process to determine the strategic rating (in the form of Gartner’s TIME model) and then recommend an appropriate migration strategy (in the form of Amazon’s 6Rs Refactor, Rehost, Replatform, Repurchase, Retain, Retire) to a given application.
To facilitate the Tolerate, Invest, Migrate, Eliminate (TIME) strategic rating and determine the business value and technical fit of an application Ardoq broadly follows the CIO Cloud Migration Playbook as the method to inventory the application portfolio and gather relevant information. The playbook provides an alternative strategic rating scoring model in the form of Review, Reward, Refresh and Remove. Ardoq recommends aligning application scoring to the more widely recognized Gartner TIME model. Cloud Migration in Ardoq, therefore, uses an amalgamation of Gartner's TIME and CIO Council's playbook to determine the strategic rating of an application.
Once applications have been identified with a strategic rating of ‘migrate’, decisions need to be made relating to migration strategy. To provide a framework for migration Ardoq leverages the Amazon 6Rs when determining a respective path for applications.
Amazon's 6Rs:
Refactor
Rehost
Replatform
Repurchase
Retain
Retire
Ardoq uses the 6Rs to make migration strategy recommendations for architects to validate. Once validated architects and application owners create migration plans that are relevant and focused which are based on a recognized migration framework.
While Ardoq leverages the Amazon 6Rs, you can easily apply any migration framework like Gartner 5Rs, Microsoft Azure 5Rs, etc. The Amazon 6Rs are further explained in the application component properties section below.
Our rationale for the Cloud Migration metamodel is to handle the broadest set of scenarios possible with the minimum number of metamodeling concepts.
Learn more about this approach in our Seven Principles of Creating a great Enterprise Architecture Metamodel. We also aim to leverage what has been provided in supporting use cases.
Ardoq’s Approach to Cloud Migration
Ardoq’s approach to cloud migration starts with determining applications with a strategic rating of migration. Highlighting these applications will identify potential opportunities to migrate to the cloud. This allows the architect the opportunity to then make decisions on which applications to move to a relevant cloud environment.
Ardoq’s Use Case for Cloud Migration leverages and evaluates existing data captured from other use cases. Then combines that output with data collected through surveys to deliver a list of opportunities.
Cloud Migration decisions are based on four factors: Suitability (which is captured by an application’s Strategic Rating), Structural Complexity (indication of connected infrastructure), Migration Strategy, and Cost.
When utilizing the relationship between Applications and their explicit connection to Business Capabilities, also take into consideration the market differentiation of the capability. When evaluating Rehosting, Replatforming, or Repurchasing applications that realize commodity capabilities like payroll, as an example, are likely best to repurchase as a SaaS Alternative.
Suitability captures the application’s fit in the organization as a whole. It considers the Alignment of Processes, Features and Usability, Criticality, and Organizational Fit. We also supplement this data with application performance metrics in the form of outages. This information is collected from application owners.
Recommended Migration Strategy identifies a recommended course of action for identified applications based on the strategic rating. This will then be validated by the relevant architect or IT leader to and Migration Strategy which is the validated course of action. This is then used to develop the relevant business plan.
Structural complexity records a quantitative way to determine how interconnected an application is in relation to the overall IT portfolio. Ardoq uses Integration Count, Number of Connected Technology Services and Servers, and the number of Business Capabilities realized by a specified application. These fields and their related reports and viewpoints provide stakeholders with a way to evaluate how much effort might be required to migrate a given application.
Cost is the last area the Use Case considers and is the calculated cost provided by the application component.
As a basis for identifying cloud migration opportunities, Ardoq uses a strategic rating of migration. Migrate Applications are then evaluated using the market differentiation and whether or not a SaaS Alternative exists to determine where applications should be rehosted or repurchased. Architects will need to evaluate Rehost applications manually and the respective destination cloud platform whether to rehost or re-platform.
Once the migration strategy determination has been made, data captured by total cost and structural complexity can inform business case development and potentially provide the basis for decision-making and further assessment.
Understanding the Cloud Migration Metamodel
This section will walk through the different component types, fields, and reference types that make up the metamodel for Cloud Migration.
Application Components
At the heart of Cloud Migration is the Application Component. As covered in greater detail in the Application Lifecycle Management Metamodel article, an application is the configuration of lower-level software or technology to provide specific business capability or technology capability, perform a defined task, or analyze specific information.
Application Component Fields
We combine existing application component data and create fields to facilitate the assignment of a strategic rating. This data can later be captured through input, import, or surveys. We also add value through the recommendation of a migration strategy for architects to then validate and confirm prior to the development of relevant business cases.
These properties provide the opportunity to calculate the suitability, relevant migration strategies, and cost in meaningful ways to produce relevant Cloud Migration dashboards, reports, and visualizations.
Suitability
Suitability looks at the strategic rating which balances the importance and overall fit of an application in the business. This provides a framework to evaluate your application portfolio against two primary measures; Business Value and Technical Fit.
The allocation of business value and technical fit generate the following suitability criteria:
Tolerate: Applications that provide low business value, but do have a working function, and provide high technical fit. This type of application shouldn't be too costly and should require little to no support. For example applications with a business value score of 0-3 and a technical fit score of 3-5 would be given a strategic rating of tolerate.
Invest: Applications that are both high in technical fit and help you reach your business objectives deserve further investment. This application experiences no disruptions and serves its purpose and ideally generates cost savings or income. For example applications with a business value score of 3-5 and a technical fit score of 3-5 would be given a strategic rating of invest.
Migrate: Applications that serve a crucial purpose to your business but are problematic on the IT side need to be migrated. Migrate highlights applications that might require too much effort or cost for maintenance and support. For example applications with a business value score of 3-5 and a technical fit score of 0-3 would be given a strategic rating of migrating.
Eliminate: Applications that have low business value and poor technical fit should be eliminated. For example applications with a business value score of 0-3 and a technical fit score of 0-3 would be given a strategic rating of eliminate.
Field | Type | Description | Definition |
Strategic Rating | Calculated Text (TIME) | Application model from Gartner for placing applications Tolerate, Invest, Migrate, and Eliminate. | Strategic Rating = (Business Value measured against Technical Fit) |
Business Value | Calculated Number Value (1-5) | Assesses how well the application supports the current needs and the future plans and value to its users. | Business Value = Business Strategic Fit + Features and Usability + Functional Fit + Criticality |
Technical Fit | Calculated Number Value (1-5) | How well the application supports the current technical needs and the future plans of the support organization. | Technical Fit = Technical Integrity + Maintainability and Agility + Technical Strategic Fit |
Business Value
Field | Type | Description | Definition |
Business Strategic Fit | Survey Calculated Number
Scale (1-5) | Application’s ability to support business strategy or the ambitions of its users. | Survey Value
1 - No Alignment -> 5 Highly Aligned |
Features and Usability | Survey Number
Scale (1-5) | Is the application easy to use without unreasonable training or extensive experience? | Survey Value
1 - Highly complex and requires training and extensive knowledge to get maximum value -> 5 Easy to use and intuitive / no or minimal training is required. |
Functional Fit | Survey Number
Scale (1-5) | Does the application provide all the functionality required to realize the relevant capability/value stream | Survey Value
1 - Requires supplemental tools or workarounds -> 5 Highly Aligned |
Criticality | Survey NUmber
Scale (1-5) | Criticality of the application in supporting the business and/or customers | Survey Value
1 - Non-Critical No Impact -> 5 Mission Critical - Serious Impact |
This contains the Gremlin Code that calculates a value for the field values to the target component Business Value. The code checks the fields: Functional Fit, Features and Usability, Business Strategic Fit, and Criticality and calculates Business Value. The code also takes into account a specific weighting in Business Value.
functionalFitKey = 'functional_fit'
functionalFitWeighting = 0.25
availabilityAndQualityKey = 'availability_and_quality'
availabilityAndQualityWeighting = 0.25
businessStrategicFitKey = 'business_strategic_fit'
businessStrategicFitWeighting = 0.25
criticalityKey = 'criticality'
criticalityWeighting = 0.25
def calculateBusinessFit(it) {
a=it.get().values(functionalFitKey)[0] as Double
b=it.get().values(availabilityAndQualityKey)[0] as Double
c=it.get().values(businessStrategicFitKey)[0] as Double
d=it.get().values(criticalityKey)[0] as Double
return (a*functionalFitWeighting + b*availabilityAndQualityWeighting + c*businessStrategicFitWeighting + d*criticalityWeighting).round(2)
}
g.V(ids)
.and(
has(functionalFitKey),
has(availabilityAndQualityKey),
has(businessStrategicFitKey),
has(criticalityKey))
.project('id', 'name', 'value').
by(id).
by('name').
by(map{calculateBusinessFit(it)}) |
Technical Fit
Field | Type | Description | Definition |
Technical Integrity | Survey Number
Scale (1-5) | Determines how the application adheres to technical standards. | Survey Value
1 - Non-Compliant -> 5 Highly Compliant |
Maintainability and Agility | Survey Number
Scale (1-5) | Provides value for the ease of upkeep and ability to adapt within the technology landscape. | Survey Value
1 - Maintenance is feared and full of unknown impacts -> 5 Easy to Maintain and Flexible |
Technical Strategic Fit | Survey Number
Scale (1-5) | Provides an indication to future-proofing of an application. | Survey Value
1 - Legacy and does not support modern architecture -> 5 Highly extensible and aligned with future requirements. |
Performance Outages | Survey Number | Provides an indication of the stability of the application. | The number of unplanned outages the application has experienced over the previous 12-month period. |
This contains the Gremlin Code that calculates a value for the field values to the target component Technical Fit. The code checks the fields: Technical Integrity, Maintainability And Agility, and Technical Strategic Fit and calculates Technical Fit. The code also takes into account a specific weighting in Technical Fit.
technicalFitRatingField = 'Technical Fit'
technicalIntegrityKey = 'technical_integrity'
technicalIntegrityWeighting = 0.40
maintainabilityAndAgilityKey = 'maintainability_and_agility'
maintainabilityAndAgilityWeighting = 0.27
technicalStrategicFitKey = 'technical_strategic_fit'
technicalStrategicFitWeighting = 0.33
def calculateTechnicalFit(it) {
a=it.get().values(technicalIntegrityKey)[0] as Double
b=it.get().values(maintainabilityAndAgilityKey)[0] as Double
c=it.get().values(technicalStrategicFitKey)[0] as Double
return (a*technicalIntegrityWeighting + b*maintainabilityAndAgilityWeighting + c*technicalStrategicFitWeighting).round(2)
}
g.V(ids)
.and(
has(technicalIntegrityKey),
has(maintainabilityAndAgilityKey),
has(technicalStrategicFitKey))
.project('id', 'name', 'value').
by(id).
by('name').
by(map{calculateTechnicalFit(it)}) |
Recommended Migration Strategy
After identifying applications to Migrate, the Cloud Migration bundle will prepopulate a recommended migration strategy for architects to manually validate as a migration strategy property. The recommended migration strategy property is based on Amazon’s 6Rs.
Field | Type | Description | Definition |
Recommended Migration Strategy | Calculated LIst | Field provides a recommendation based on Strategic Rating and Supplemental data (if Necessary). | Calculated Recommendation (list) consistent with Amazon 6Rs: Rehost, Refactor, Replatform, Repurchase, Retain, and Retire. |
Migration Strategy | List | Architect validated field, based on insight and the recommended migration strategy. | Dropdown list with options consistent with Amazon 6Rs: Rehost, Refactor, Replatform, Repurchase, Retain, and Retire. |
SaaS Alternative | List | Survey questions to application owners of applications with a strategic rating of Migrate on whether or not there is a viable SaaS alternative. This will determine whether the recommendation is to rehost or repurchase. | Survey responses are Yes / No |
This contains the Gremlin Code that calculates a value for the field values to the target component Recommended Migration Strategy. The code checks the fields: Strategic Rating, if necessary SaaS Alternative, and Business Capability: Market Differentiation.
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(choose(has('strategic_rating','Eliminate'),constant('Retire'),
choose(has('strategic_rating','Invest'),constant('Refactor'),
choose(has('strategic_rating','Tolerate'),constant('Retain'),
choose(has('hosting_type','Cloud'),constant('Retain'),
choose(has('hosting_type','SaaS'),constant('Retain'),
choose(has('hosting_type','3rd Party'),constant('Retain'),
choose(and(has('strategic_rating','Migrate'),has('saa_s_alternative','Yes')),constant('Repurchase'),
choose(and(has('strategic_rating','Migrate'),has('saa_s_alternative','No')),constant('Rehost'),
constant('Validation Required')
))))))))) |
Structural Complexity
As previously mentioned, Structural Complexity is a basic way of determining how interconnected, technically, the application is in the overall IT portfolio.
Field | Type | Description | Definition |
Total Capabilities Realized | Calculated Number | Provides stakeholders with a view of what capabilities the application realizes. | Count of all the Business Capabilities that a given application realizes |
Total Integrations | Calculated Number | Highlights if the application provides and/or consumes data from other applications or systems. | Sum of all of the Incoming and Outgoing Integrations |
Total Connected Infrastructure | Calculated Number | Provides a high-level overview of the Connected infrastructure. | Sum of all “Is Support By” directly connected infrastructure |
Total Connected Technology Services | Calculated Number | Provides a high-level overview of the Connected Technology Services. | Sum of all “Is Support By” Technology Services |
Total Supporting Infrastructure | Calculated Number | Provides a high-level overview of the connected services. | Sum of all “Is Support By” Servers & Technology Services |
If these metrics all have notionally high values, then stakeholders could infer the application would have a high level of effort to rationalize the application.
As an example:
Two applications have a strategic rating of ELIMINATE.
In comparing the two applications, we discover;
Application one’s structural complexity values are >4 Realized Capabilities + >5 Total Integrations + >10 Total Connected Infrastructure components.
Application two’s structural complexity is 1 Realized Capability + 1 Total Integrations + 1 Total Connected Infrastructure Component.
In this scenario, the person responsible for Application Rationalization could infer that application two would require less effort to Eliminate the application. It should be noted that Structural Complexity only provides an indication of effort.
Total Cost
Cost is often a key consideration when evaluating applications.
Utilizing the ITCM Use Case we can provide indicative cost values for Applications:
Field | Type | Description | Definition |
Total Cost | Calculated Number | Shows the Total Cost of the
Component | Total Direct + Total Attributed
Cost from the Component in
question |
Business Capability
As identified in the BCR and BCM use cases, a business capability is a set of resources that, by working together, gives the organization the ability to purposefully produce a particular business output. They are the modular building blocks of a business, either as something that exists today or something that a company is able to do in the future. The use case does not create any new properties on business capability, it only utilizes existing capability properties.
Cloud Migration References
Cloud Migration relies on two reference types:
Reference | Description |
Is Realized By | Represents that a component implements the
logical requirements, behaviors, or characteristics defined by another component.
As an example: a Business Capability is realized by an Application. |
Is Supported By | Represents the operation of one component is a requirement or precondition for the operation of another.
As an example: an Application is supported by a server |
The references are important in determining the suitability or structural complexity of an application, which is why it’s important to be mindful of creating the right connections. Below is an example of the references between the four component types:
Practical Implementation
If previous use cases are complete, the Cloud Migration Use Case does not require further component types or references.
Cloud Migration requires that Applications are modeled to relevant Business Capabilities (and that you have assigned a value to the market differentiation property on the capability) they realize and that relevant cost information is provided through IT Cost Management.
Ardoq recommends the simplest model to do the job. The picture below illustrates the workspaces and their relations used to implement the data lineage bundle.
Extending your CM Metamodel
We have provided our criteria but this section explains how you can add your own by extending the metamodel. For example, adding new fields can be done by an administrator in seconds - see this article for information on adding fields.
An administrator can also easily create a new component and reference type, although we suggest you plan this process carefully. Over-complex metamodels can be hard to navigate and query.
Before extending your metamodel, ask:
How will I or others capture this information?
How much effort will it be across the whole application portfolio?
How will I use this information to create actionable insight?
With those considerations, you can quickly adapt your model to changing requirements. You can keep your critical data up-to-date and maintain your insights, keeping it continuously relevant as requirements evolve.
We're always happy to help. Feel free to reach out to us via the in-app chat if you have any follow-up questions about this article.
Migration Strategy Comparison
Amazon AWS | ||
Refactor | Rearchitect / Rebuild | Refactor / Rearchitect |
Rehost | Rehost | Rehost |
Replatform | Refactor | Revise |
Repurchase | Replace | Replace |
Retain |
|
|
Retire |
|
|
Version | Date | Author | Rationale |
1.0 | 19/12/2022 | Sean Gibson | Published |
|
|
|
|
|
|
|
|