1 Objective
The objective for this document is to support stakeholders in the decision making process of choosing the right migration strategy for their application/s.
Here’s a general strategy and process for migrating applications to Private, Public Cloud and SaaS/PaaS model. Creating a decision tree for migrating applications involves outlining migration drivers, considering various application profiles and criteria for determining the correct migration strategy and process.
2 Migration Drivers
2.1 Cost reduction
Optimize IT costs such as license renewal, hardware replacement, the need for increased operational efficiency.
2.2 Risk reduction
Reduce risks and satisfy all sorts of regulatory requirements and compliances, end of life for hardware components, audit compliance.
2.3 Business transformation
Business transformation and increase the speed of innovation and agility and reduce time to market.
3 Application categories
Standard Enterprise Processes, SaaS for commoditized non-core business applications.
Mission critical proprietary applications migrate to AWS Outpost or AWS EKS hybrid model.
Operational Data Usage. User Services non-commoditized non-core application migrate to AWS EKS or AWS Native
4 Migration Options
- Retain if no compelling reasons for migration.
- Retire if application is EOL, no need to invest.
- Migrate to SaaS if suitable alternatives exist.
- Migrate to AWS Outpost.
- Migrate to EKS on AWS Cloud.
- Migrate to AWS Native
5 Migration Key Determinants
5.1 SaaS/PaaS considerations
5.1.1 Profile Criteria:
- Availability of SaaS commoditized alternative.
- Cost.
- Customization requirements
- Data Sensitivity
- Compliance Requirements
5.1.2 Decision Points:
- Is it commoditized application?
- Are there suitable alternatives available for the application?
- How does the cost of SaaS compare to other options?
- Can the application’s customization requirements be met by SaaS solutions?
- Does the application handle sensitive data?
- Are there specific compliance requirements (e.g., regulatory, security)?
5.2 OpenShift Suitability
5.2.1 Profile Criteria:
- Mission critical proprietary applications
- Containerization Readiness
- Integration Complexity
- Performance Sensitivity
5.2.2 Decision Points:
- Is the application a backbone process crown jewel?
- Does the application follow “cloud native” principles?
- Can the application be easily containerized?
- Does the application have complex integrations?
- Is the application sensitive to performance changes?
5.3 AWS OpenShift Suitability
5.3.1 Profile Criteria:
- Operational Data usage, User Services
- Cloud-Native Architecture
- Data Sensitivity
- Compliance Requirements
5.3.2 Decision Points:
- Is the application User Services oriented?
- Is the application designed with cloud-native principles?
- Does the application handle sensitive data?
- Are there specific compliance requirements (e.g., regulatory, security)?
5.4 AWS considerations
5.4.1 Profile Criteria:
- AWS Native Services Utilization
- Scalability Requirements
- Data Storage Needs
- Data exchange for Analytics/ML/AI
5.4.2 Decision Points:
- Is the application non-commoditized, non-core?
- Does the application leverage AWS native services?
- Are there scalability requirements that align with AWS capabilities?
- What are the data storage needs, and how well do they align with AWS storage services?
- Does the application require data exchange capabilities for AWS data warehousing, analytics, ML or AI?
5.5 Application Assessment:
5.5.1 Profile Criteria:
- Monolithic vs. Microservices
- Criticality to Business Operations
- Resource Utilization
5.5.2 Decision Points:
- Is the application monolithic or microservices-based?
- How critical is the application to business operations?
- Does the application have variable resource requirements?
5.6 Integration Dependencies
5.6.1 Profile Criteria:
- External Service Dependencies
- Network Architecture
- Security
5.6.2 Decision Points:
- Does the application have external service dependencies?
- How is the network architecture designed, and does it align with cloud requirements?
5.7 Migration Complexity
5.7.1 Profile Criteria:
- Codebase Size and Complexity
- Data Migration Complexity
- Interdependencies with Other Applications
- Interdependencies with other teams such as Architecture, Security, Data, external consultants and resources.
5.7.2 Decision Points:
- Is the codebase large or complex?
- How complex is the data migration process?
- Are there significant interdependencies with other applications and teams?
5.8 Operational Consideration
5.8.1 Profile Criteria:
- Operational Overheads
- Maintenance and Patching
- Monitoring and Logging Requirements
5.8.2 Decision Points:
- What are the operational overheads associated with the application?
- How are maintenance and patching handled?
- What monitoring and logging requirements does the application have?
6 Migration Strategy process
6.1 Re-host
Containerize and “lift and shift”. Not advisable but may be applicable for small code base and simple applications. Quick implementation and quick wins.
6.2 Refactor
Re-use programming languages, code, and containerize. As a result the application should follow “cloud native” principles.
6.3 Revise
The application will require to be altered extensively prior to migration. The current code will be modified. This is the case for legacy applications/end of life applications which require revision. It is an expensive strategy and time consuming.
6.4 Rebuild
The existing code will be discarded and the application will be rearchitected and rebuild from the ground up, following with “cloud native” principles and best practices.
6.5 Replace
The application is discontinued and replaced with a SaaS/PaaS solution.
6.6 Retire
The application is no longer needed or in use.
6.7 Retain
Retain if no compelling reasons for migration.