Day 5 - Week 6 Review: Integrated Migration Strategy Scenarios

Week 6 covered the entire cloud migration process: the decision-making framework 7R (Day 1), standard server transfer tools MGN and DRS (Day 2), the science of DB migration with DMS+SCT (Day 3), and acceleration tools completing the ecosystem (Day 4). These four days form the core of SAP-C02 Domain 3 (Migration & Modernization, 20%).

Common Domain 3 patterns: "Long scenarios with multiple tools appearing, requiring precise tool role distinction to choose the correct answer." Today we compress core concepts into decision trees and solidify real-world skills through 12 complex scenarios.

7R Decision Tree: Choosing R from Scenarios

7R is not memorization but scenario classification. Understanding each R's "entry conditions" via decision tree is essential.

Question 1: Is there reason to continue using this system?
  NO → Retire (decommission)
  YES → Next

Question 2: Does migration lack ROI or is on-premises mandatory per regulation?
  YES → Retain (keep as-is)
  NO → Next

Question 3: Must VMware vCenter be maintained as-is?
  YES → Relocate (VMware Cloud on AWS)
  NO → Next

Question 4: Is quick transfer without code changes top priority?
  YES → Rehost (lift-and-shift, MGN)
  NO → Next

Question 5: DB engine or OS change with minimal code fixes?
  YES → Replatform (DMS+SCT, MGN)
  NO → Next

Question 6: Is SaaS product conversion more sensible?
  YES → Repurchase (Salesforce, ServiceNow, etc.)
  NO → Next

Question 7: Redesign architecture to microservices/serverless?
  YES → Refactor/Re-architect (A2C, Refactor Spaces, Lambda redevelopment)

⚠️ Critical Distinction: Replatform vs Refactor boundary.

• Replatform: code unchanged, replace infrastructure layer only. "Oracle → Aurora (code unmodified)", "EC2-based app → ECS (Docker only)"
• Refactor: code also changes, architecture redesigned. "Monolith → Lambda+DynamoDB", "REST API → event-driven architecture" Edge case: "Oracle → Aurora PostgreSQL with PL/SQL converted to PostgreSQL functions" → Even if SCT auto-converts, code transformation occurs, so technically Replatform (infra + some code). SAP exam primarily distinguishes by code change presence.

Final Tool Mapping Table

💡 Related Theory: In migration, data consistency (Consistency) is mandatory, not optional. ACID (Atomicity, Consistency, Isolation, Durability) properties in OLTP DBs mean how open transactions are handled during migration is critical. DMS reads DB engines' transaction logs (Oracle Redo Log, MySQL binlog, SQL Server CDC, PostgreSQL WAL) to capture changes per transaction. MGN's block-level replication doesn't recognize transaction boundaries, so DB migration via DMS is Best Practice.

Homogeneous vs Heterogeneous Migration Decision Basis

Are engines the same?
  MySQL → Aurora MySQL → DMS only
  PostgreSQL → Aurora PostgreSQL → DMS only
  Oracle → RDS Oracle → DMS only

Are engines different?
  Oracle → Aurora PostgreSQL → SCT (schema) + DMS (data)
  SQL Server → Aurora PostgreSQL → SCT + DMS
  MongoDB → DynamoDB → DMS (NoSQL→NoSQL, SCT unnecessary)
  SQL Server → Aurora MySQL Babelfish → Babelfish (T-SQL compatibility layer)

Same engine but significantly different versions?
  MySQL 5.6 → Aurora MySQL 3.x (MySQL 8.0 compatible) →
  DMS transfer only, but pre-test string functions and system variable changes

Understanding SCT Conversion Quality

SCT (Schema Conversion Tool) auto-converts schemas between heterogeneous engines, but conversion rate isn't complete.

SCT Assessment Report example:
  Auto-convertible: 75%
  Manual fixes needed: 20% (complex PL/SQL functions, package dependencies)
  Unsupported: 5% (DB-specific features, custom C extensions)

Practical lessons:
- Lower SCT conversion rate → higher Refactor cost
- Many Oracle-specific hints, DB links, partitioning → difficult conversion
- Run SCT Assessment upfront to predict effort

🔍 Deeper Dive: DMS CDC minimal-downtime migration pattern. Full Load alone prolongs downtime on large DBs. Full Load + CDC combination: (1) Full Load transfers existing data (source still operating), (2) After Full Load, CDC continuously applies changes, (3) When lag shrinks to seconds → brief app shutdown → final CDC reflection → switch. This pattern enables multi-TB DB transfer within minutes downtime. On SAP exam, "minimal-downtime DB migration" always means DMS Full Load + CDC pattern.

MGN vs DMS Selection Final Summary

Transfer target is "entire server (OS + app + middleware)"?
  YES → MGN

Transfer target is "DB data"?
  YES → DMS (homogeneous) or DMS+SCT (heterogeneous)

Can DB server be transferred via MGN?
  Technically possible but not Best Practice.
  Reason: Open transactions during replication → potential data inconsistency
  Recommended: App servers → MGN, DB → DMS

Both needed?
  700 app servers → MGN (parallel)
  100 Oracle DBs → SCT+DMS (parallel)
  → Coordinate with Migration Hub Orchestrator

A2C (App2Container) Advanced: Containerization Automation

A2C analyzes Java, .NET (IIS) based apps to auto-generate Docker images and ECS/EKS deployment artifacts.

A2C operation sequence:

1. Discover (analyze app)
   $ app2container discover --target-container-id app-001
   └── Analyze running app process, port, dependencies, environment vars

2. Extract (extract)
   $ app2container extract --application-id java-app:1234
   └── Extract app files, config, runtime to tar package

3. Containerize (containerization)
   $ app2container containerize --application-id java-app:1234
   └── Generate Dockerfile, build Docker image, push to ECR
   └── Generate ECS Task Definition or EKS Helm Chart

4. Generate Pipeline (CI/CD pipeline)
   $ app2container generate app-deployment \
     --application-id java-app:1234 \
     --deploy-target ecs
   └── Generate CodePipeline + CodeBuild CloudFormation

📚 Case Study: A2C's limitations. A Korean SI company containerized a legacy Java EE app (JBoss 4.2 based) via A2C. Specific JBoss 4.2 JMX configuration and EJB remote calls didn't work in container environment. A2C puts the app "as-is" in containers but doesn't make it container-friendly. Legacy apps storing server state in files, JVM heap configs conflicting with container memory are typical A2C post-work targets.

EKS Anywhere vs AWS Outposts: Hybrid Kubernetes

After containerization covered in Day 4's migration tools, comes "where to deploy?" choice.

🎯 Scenario classification:

• "Deploy Kubernetes to existing on-premises servers and manage unified from AWS console" → EKS Anywhere
• "Hospital internal patient data must never leave site but need RDS" → Outposts
• "Finance regulations require data processing in domestic data center only" → Outposts or EKS Anywhere (depends on regulation details)

Entire Migration Pipeline Flow

Organize enterprise migration end-to-end pipeline:

[Phase 1: Discover & Assess]
  ADS (Application Discovery Service)
  └── Agentless Collector (VMware environment)
  └── Discovery Agent (physical servers, other clouds)
  └── Inventory: CPU, memory, disk, network dependencies

  DMS Fleet Advisor
  └── DB server specialized inventory
  └── Schema complexity, conversion feasibility assessment

  Migration Evaluator
  └── On-Demand vs Savings Plans comparison
  └── 5-year TCO savings projection

  Migration Hub Strategy Recommendations
  └── Per-server 7R auto-recommendation (Refactor/Replatform/Rehost...)

[Phase 2: Plan & Mobilize]
  MAP (Migration Acceleration Program)
  └── AWS partners + funding support + training
  └── Assess → Mobilize → Migrate 3-stage

  Migration Hub
  └── Unified tracking of all migration progress

[Phase 3: Migrate]
  Server transfer:
  MGN (Rehost → EC2) + DRS (continuous DR)

  DB transfer:
  DMS + SCT (heterogeneous) or DMS (homogeneous)
  DataSync (file/object storage)
  Snow Family (large offline)

  Containerization:
  App2Container (Java, .NET)
  Porting Assistant (.NET Core porting)
  EMP (EoS Windows)

[Phase 4: Modernize]
  Refactor Spaces (gradual microservices separation)
  EKS / ECS (container orchestration)
  Lambda / EventBridge (serverless event-driven)
  Serverless Application Model (SAM)

[Phase 5: Optimize]
  Compute Optimizer (Right-Sizing)
  Savings Plans / Reserved Instances (cost commitment)
  Trusted Advisor (overall recommendations)
  Well-Architected Tool (6 Pillar review)

Key Comparison Table: Pre-Exam Check

📝 Practice Questions

Click a choice to reveal the answer and explanation.

Question 1

Large retailer must migrate 800 physical servers (700 app + 100 Oracle DB) to AWS within 6 months. Replace Oracle with Aurora PostgreSQL; quickly migrate app servers to EC2. Best tool combination?

• AMGN (all) + RDS Oracle (DB)
• BMGN (700 apps) + DMS+SCT (100 Oracle DB → Aurora PG)
• CApp2Container (all) + DMS (DB)
• DRefactor Spaces (all) + Babelfish (DB)

Question 2

ADS discovered 3,000 servers, 500 showing avg CPU < 3%, no traffic, last login 2 years ago. Remaining 2,500 active. 7R strategy for 500?

• ARetain (on-premises, regulatory)
• BRehost (EC2 transfer, monitor)
• CRetire (decommission)
• DRepurchase (SaaS conversion)

Question 3

Financial company with SQL Server hosting .NET Framework 4.6 app wants AWS transfer + SQL Server license removal with minimal code change. Limited dev resources, no large rewrites possible. Most realistic combination?

• APorting Assistant for .NET Core porting + RDS PostgreSQL
• BApp2Container containerization + RDS SQL Server
• CAurora PostgreSQL Babelfish (DB) + MGN (app EC2)
• DDMS+SCT (DB) + Refactor Spaces (app)

Question 4

Enterprise migration kickoff. Executives ask "5-year TCO savings?" Teams ask "Which 7R per server?" AWS services satisfying both?

• ACost Explorer + Trusted Advisor
• BMigration Evaluator (TCO) + Migration Hub Strategy Recommendations (7R recommendation)
• CAWS Pricing Calculator + Compute Optimizer
• DAWS Budgets + AWS Config

Question 5

500 VMs migrated to VMware Cloud on AWS (Relocate). After 6 months, VMware licensing costs remain high. Next step?

• ARenegotiate VMware/AWS VMC subscription license unit price (architecture unchanged)
• BMGN transfer VMC VMs to EC2 native (Relocate → Rehost)
• CImmediately Refactor all 500 VMs to Lambda + DynamoDB serverless redesign
• DKeep VMC, only Compute Optimizer Right-Sizing to review cost

Question 6

Large monolithic Java app (2M lines) in microservices transition. Operate existing monolith while developing new order management module first as microservice, then gradually transition order API traffic from monolith to new service. Which service manages routing automation?

• AAWS App Mesh
• BAWS Migration Hub Refactor Spaces
• CAmazon API Gateway (manual setup)
• DAWS Cloud Map

Question 7

1,000 VMware VM CPU/memory usage and TCP dependency collection without agents to design Waves. vCenter environment, no agent install desired. Suitable tool?

• ADMS Fleet Advisor
• BADS Agentless Collector (vCenter virtual appliance)
• CADS Discovery Agent (install per VM)
• DAWS Systems Manager Inventory

Question 8

MySQL 5.7 → Aurora MySQL 2.x (MySQL 5.7 compatible) migration with 100 stored procedures. Which between DMS and SCT needed?

• ADMS + SCT both (MySQL also heterogeneous)
• BDMS only (homogeneous engine, no schema conversion)
• CSCT only (stored procedure conversion)
• DMGN server-as-is

Question 9

Migration manager running MGN 150, DMS 30, partner tool 20 simultaneously. Manage each server "Discovery → Ready → Testing → Cutover Complete" state and Wave-by-Wave progress in one console, including wave dependency automation. Which service?

• ACloudWatch Dashboards
• BAWS Migration Hub + Migration Hub Orchestrator
• CAWS Service Catalog
• DAWS Config + Systems Manager

Question 10

Post-migration EC2 instances over-provisioned per source server specs. CPU avg 15%, memory 40%. Want instance type downsizing recommendations. Which service?

• AAWS Cost Explorer
• BAWS Compute Optimizer
• CAWS Trusted Advisor (cost category)
• DAWS Pricing Calculator

Question 11

Company completed on-premises to AWS migration. Remaining on-premises data center to be used as AWS service DR site. Possible configuration?

• AReinstall MGN in reverse—AWS EC2 source, on-premises block-level continuous replication
• BConfigure DRS with AWS EC2 source, on-premises DR target (reverse replication)
• CAWS doesn't support on-premises as DR target; use different AWS region
• DAWS DataSync copy EC2 EBS volume data to on-premises NFS, schedule-based periodic

Question 12

Company received Well-Architected migration review. "Domain 3: Migration and Modernization missing minimal-downtime DB migration design." 10TB Oracle DB → Aurora PostgreSQL within 2-hour downtime. Best Practice design?

• AOracle Dump → S3 → Aurora import (Full Load only)
• BOracle Data Pump initial transfer + DMS CDC change sync → cutover at seconds lag, brief downtime
• CInstall Aurora on same server as Oracle for real-time replication
• DSnowball Edge offline transfer, then switch