AWS Portfolio Assessment & Migration Strategy

Learning Objectives

By the end of this study guide, you should be able to:

• Identify and define the 7Rs of application migration.
• Explain how to use AWS Migration Hub for tracking and assessment.
• Calculate Total Cost of Ownership (TCO) and justify migration ROI.
• Organize workloads into Migration Waves based on dependencies and business priority.
• Conduct a high-level application assessment to determine the optimal migration path.

Key Terms & Glossary

• 7Rs: A framework for determining the migration strategy for individual applications in a portfolio.
• TCO (Total Cost of Ownership): A financial estimate intended to help buyers and owners determine the direct and indirect costs of a product or system (On-premises vs. AWS).
• AWS Migration Hub: A central service that provides a single place to track the progress of application migrations across multiple AWS and partner solutions.
• Wave Planning: The process of grouping applications into logical migration sets (waves) to minimize risk and optimize resource usage.
• Discovery: The phase of collecting metadata and performance data from on-premises servers using tools like the AWS Application Discovery Service.

The "Big Idea"

Portfolio assessment is the "triage" phase of the cloud journey. Before a single server is moved, an architect must look at the entire landscape of an organization's IT assets. It is not just about how to move, but if and when. By categorizing applications using the 7Rs and analyzing TCO, organizations avoid the trap of "moving the mess to the cloud," ensuring that the migration delivers actual business value rather than just a change in billing address.

Formula / Concept Box

Hierarchical Outline

1. Discovery & Data Collection
   • Agentless Discovery: Best for broad environments (VMware/Hyper-V).
   • Agent-based Discovery: Best for deep performance metrics and dependency mapping.
2. Portfolio Assessment
   • Technical Feasibility: Can the OS/DB run on AWS? (e.g., Mainframe vs. x86).
   • Business Value: Is the application critical? What is the downtime tolerance?
3. Migration Strategy Selection (The 7Rs)
   • Rehost (Lift and Shift)
   • Relocate (VMware Cloud on AWS)
   • Replatform (Lift and Reshape)
   • Repurchase (Drop and Shop/SaaS)
   • Refactor (Rearchitect for Cloud Native)
   • Retain (Keep on-prem for now)
   • Retire (Decommission)
4. Execution Planning
   • Wave Planning: Categorizing by department, complexity, or dependency.
   • Landing Zone: Setting up Control Tower and Multi-account structure before migration.

Visual Anchors

Migration Decision Flowchart

Effort vs. Value Matrix

\begin{tikzpicture} \draw[thick,->] (0,0) -- (6,0) node[right] {Migration Effort}; \draw[thick,->] (0,0) -- (0,6) node[above] {Business Value}; \node[draw, rectangle, fill=blue!10] at (1.5,4.5) {Rehost}; \node[draw, rectangle, fill=green!10] at (4.5,5) {Refactor}; \node[draw, rectangle, fill=yellow!10] at (3,3) {Replatform}; \node[draw, rectangle, fill=gray!10] at (1,1) {Retire/Retain}; \draw[dashed] (0,3) -- (6,3); \draw[dashed] (3,0) -- (3,6); \end{tikzpicture}

Definition-Example Pairs

• Rehosting: Moving an application without making changes to take advantage of cloud scale.
  • Example: Moving a legacy Windows 2012 server to an EC2 instance using AWS Application Migration Service (MGN).
• Replatforming: Changing the platform (e.g., the OS or DB) to reduce management overhead without changing code.
  • Example: Moving a self-managed SQL Server on a VM to Amazon RDS for SQL Server.
• Refactoring: Re-imagining how the application is architected using cloud-native features.
  • Example: Breaking a monolithic Java app into microservices running on AWS Lambda or Fargate.

Worked Examples

Problem: Strategy Selection for a Legacy CRM

Scenario: A company has a 10-year-old CRM running on a physical Linux server. The hardware is at end-of-life. The business wants to move to the cloud quickly but also wants to stop managing the underlying database.

Solution Breakdown:

1. Assessment: The hardware is old (High Urgency), but the code is stable.
2. Options:
   • Rehost: Quick, but still manages the DB.
   • Refactor: Too slow; business needs to move now.
   • Replatform: Optimal. Move the application to EC2 and the database to RDS.
3. Result: Replatform strategy meets the speed requirement while offloading the heavy lifting of DB management to AWS.

Checkpoint Questions

1. What is the primary difference between Replatforming and Refactoring?
2. Which AWS service provides a central dashboard for tracking migration tasks from multiple tools?
3. True or False: Wave Planning should always start with the most complex, mission-critical applications to "get them out of the way."
4. In a TCO analysis, does the cost of data center cooling count as a direct or indirect cost for on-premises hosting?

Muddy Points & Cross-Refs

[!TIP] Replatform vs. Refactor: This is the most common point of confusion. Remember: If you change the code significantly (e.g., changing from synchronous to asynchronous processing), it is Refactoring. If you just change the database engine or the OS but the application code stays 90% the same, it is Replatforming.

Cross-References:

• For data migration tools (Snowball, DataSync), see Domain 4.2.
• For Setting up Multi-account structures, see AWS Control Tower & Organizations.

Comparison Tables