# AWS MAP: Migration and Modernization Framework

## 1. Assess

สิ่งที่ต้องทำ:
- Initial Discovery (ค้นหาและจัดกลุ่ม workload)
- Strategy Analysis (7Rs – Retire, Retain, Rehost, etc.)
- Migration Readiness Assessment (MRA)
- Initial Business Case (คำนวณ TCO/ROI)
- Briefings & Workshops
- Immersion Day (ทดลองใช้)

เป้าหมาย:
- เข้าใจสิ่งที่ต้องย้ายและประเมินความพร้อมขององค์กร
- สร้าง business case และแรงจูงใจเชิงธุรกิจสำหรับการเปลี่ยนแปลง

---

## 2. Mobilize

สิ่งที่ต้องทำ:
- **Portfolio**:
- Detailed Discovery
- Planning & Governance
- Detailed Business Case
- **People**:
- Skills, Culture, Leadership & Change Mgmt.
- **Platform**:
- Landing Zone
- Operating Model
- Security & Compliance

เป้าหมาย:
- สร้างความพร้อมด้านเทคนิคและองค์กร
- สร้างแผนงาน migration ที่มีความชัดเจนและวาง foundation ที่มั่นคง

---

## 3. Migrate & Modernize

สิ่งที่ต้องทำ:
- Migrate: ดำเนินการย้าย workload จริง
- Operate & Optimize: ปรับและเพิ่มประสิทธิภาพหลังย้าย
- Modernize: ปรับเปลี่ยนระบบให้เหมาะกับ cloud-native architecture

เป้าหมาย:
- ดำเนินการย้ายและปรับปรุง workload อย่างต่อเนื่อง
- สร้างระบบที่ยืดหยุ่น, ปรับขนาดได้ และพร้อมสำหรับอนาคต
___
# AWS Migration Hub Journeys

**Migration Hub Journeys** คือฟีเจอร์ใหม่ใน AWS Migration Hub
ออกแบบมาเพื่อช่วยให้การวางแผนและติดตามการย้ายระบบไปยัง AWS มีประสิทธิภาพมากยิ่งขึ้น

## ความสามารถหลัก

- **Converts** การ migration ให้อยู่ในรูปของ pipeline ที่มี task ชัดเจน
- **Collaborate** ระหว่างทีมภายในและผู้มีส่วนร่วมภายนอกในจุดเดียว
- **Guide** ลูกค้าด้วย task template ที่ได้รับการออกแบบล่วงหน้าโดยผู้เชี่ยวชาญ
เพื่อให้สามารถบรรลุเป้าหมายการย้ายระบบได้รวดเร็วและมีทิศทาง

## เหมาะสำหรับใคร

- ทีม IT หรือ Enterprise Architect ที่ต้องดูแลโครงการ migration ขนาดใหญ่
- พาร์ทเนอร์ AWS ที่ต้องช่วยวางแผนให้ลูกค้า
- องค์กรที่ต้องการจัดการงาน migration แบบเป็นระบบ

## ประโยชน์

- ลดความซับซ้อนของการจัดการโครงการ
- ทำให้การติดตามความคืบหน้าชัดเจนขึ้น
- เพิ่มความร่วมมือระหว่างหลายฝ่ายในโครงการเดียว

___
# Migration & Modernization Accelerators (AWS)

โปรแกรมสนับสนุนเพื่อช่วยให้การย้ายระบบและการปรับปรุงระบบบน AWS ดำเนินไปอย่างรวดเร็วและมีประสิทธิภาพ

---

## 1. Proof of Concepts (PoC)

- สำหรับการทดสอบก่อนการลงทุนจริง เช่น De-risking หรือ POC
- รองรับ Partner ด้าน Services / Hardware / Software ที่อยู่ในขั้น Validated Stage ขึ้นไป
- สนับสนุน:
- Partner Cash Funding
- AWS Promotional Credits
- *ไม่สามารถใช้ร่วมกับ MAP ได้*

---

## 2. Migration Acceleration Program (MAP)

- สำหรับ Partner ที่มี Migration Competency หรือ Capability Review ผ่านแล้ว
- ประเภทเงินสนับสนุน:
- **MAP Large (>500K USD)**: Partner Cash + Service Credits
- **MAP Lite (<100K USD)**: Service Credits
- ครอบคลุมบริการเสริม:
- Database & Analytics, VMware (MAP Lite), Oracle Apps, SAP
- สนับสนุนทั้งการย้ายแบบ Greenfield และ Modernization
- สามารถใช้แบบ Standalone ได้
- VMware: สนับสนุน Partner Cash โดยเฉพาะ

---

## 3. OLA Program (Optimization & Licensing Assessment)

- โปรแกรมประเมิน License และประสิทธิภาพการใช้งาน
- AWS สนับสนุนค่าใช้จ่าย
- สำหรับลูกค้าที่ใช้:
- Microsoft Windows Server / SQL Server
- Oracle
- SAP
- ประเมินด้าน Application & Business Impact ได้
- ใช้ในเฟส Assess (แนะนำ) หรือ Mobilize ก็ได้

---

## 4. ISV Migration and Modernization

- เหมาะสำหรับลูกค้าปัจจุบันของ ISV (Independent Software Vendors)
- ครอบคลุมทั้ง On-prem, Cloud, Multi-cloud
- รองรับเทคโนโลยี Enterprise workload เช่น VMware, Oracle, Microsoft, Mainframe, SAP
- AWS สนับสนุนผ่าน ISV โดยตรง
- สำหรับตลาดที่ไม่สามารถใช้ AWS MGN ได้ ก็ยังสามารถขอการสนับสนุนนี้ได้
- ตัวอย่าง ISV: CAST, Unisys, Microfocus, Virtana, Cloudamize, vFunction, MontyCloud เป็นต้น

___
# MAP Program Modernization SPI Incentives Eligible Services

**Services ที่ตรงเงื่อนไขเข้าโปรแกรม MAP2.0**
ไม่ควรใส่ services ที่ไม่เข้าเงื่อนไขลงใน Price Calculator ที่จะขอ Funding

---

## 1. Move to Cloud Native

ใช้บริการที่สร้างขึ้นเพื่อทำงานบนระบบคลาวด์โดยเฉพาะ เพื่อเพิ่มความยืดหยุ่นและปรับขยายได้ง่าย

- API Gateway
- Lambda
- Elastic Container Registry (ECR)
- ECS / EKS
- Fargate
- EventBridge
- Step Functions
- SQS / SNS
- Amazon MQ
- AppSync
- Cognito / Sync
- Kinesis
- Amplify
- X-Ray
- Migration Hub Refactor Spaces

---

## 2. Move to Containers

นำแอปพลิเคชันบรรจุใน container เพื่อความยืดหยุ่นในการจัดการ deployment

- ECR
- ECS / EKS
- Fargate
- App Runner
- ECR Public

---

## 3. Move to Managed Databases

ย้ายข้อมูลไปยังระบบฐานข้อมูลที่ดูแลจัดการโดย AWS

- RDS (MySQL, Postgres, MariaDB)
- Aurora
- DynamoDB
- DynamoDB Accelerator (DAX)
- DocumentDB
- Keyspaces
- Neptune
- Timestream
- MemoryDB
- DMS (Database Migration Service)
- Managed Blockchain

---

## 4. Move to AI (ใหม่)

เปลี่ยนไปใช้บริการ AI/ML ของ AWS เพื่อเพิ่มความสามารถอัจฉริยะ

- SageMaker
- Bedrock
- CodeWhisperer
- Amazon Personalize
- Rekognition
- Comprehend Medical
- Translate
- Textract
- Lex
- Forecast
- Transcribe
- HealthLake

---

## 5. Move to Open Source

ใช้โซลูชันที่เป็นโอเพ่นซอร์สเพื่อความยืดหยุ่นและลดการยึดติดกับผู้ให้บริการ

- RDS (MySQL, Postgres, MariaDB)
- Aurora
- Linux container บน ECS / EKS
- Keyspaces
- Lambda
- MSK
- MQ

---

## 6. Move to Managed Analytics

เพิ่มความสามารถในการวิเคราะห์ข้อมูลขนาดใหญ่ด้วยเครื่องมือที่จัดการง่าย

- Lake Formation
- Kinesis
- EMR
- Redshift
- MSK
- Athena
- Glue
- QuickSight
- OpenSearch
- Kendra
- MWAA (Apache Airflow)
- AppFlow
- HealthLake

---

## 7. Move to Modern DevOps

ปรับโครงสร้าง DevOps ให้ทันสมัย ด้วยเครื่องมือแบบอัตโนมัติ

- CloudFormation
- CodeCommit / CodeBuild / CodeDeploy / CodePipeline
- CodeGuru / Amplify
- X-Ray
- CodeArtifact
- CodeCatalyst
- DevOpsGuru
- Prometheus
- DeviceFarm
___
# Optimization and Licensing Assessments (OLA)

## License Optimization on AWS

AWS ให้การสนับสนุนการทำ assessment ด้าน License และ Infrastructure สำหรับระบบ On-Premise เพื่อลดต้นทุนและเพิ่มประสิทธิภาพในการใช้งานทรัพยากร

---

## รายละเอียดหลัก

- OLA เป็นโปรแกรมที่ AWS สนับสนุนค่าใช้จ่ายในการประเมินโครงสร้างพื้นฐานและการจัดการลิขสิทธิ์
- ใช้สำหรับการประเมินระบบที่มีขนาด 50 เซิร์ฟเวอร์ขึ้นไป หรือมีรายได้ประจำปี (ARR) อย่างน้อย 100,000 USD

---

## ประเภทของ OLA

1. **Standalone OLA**
- cash funding แก่พาร์ทเนอร์ที่ระบุและส่ง OLA
- สามารถขอแยกจาก MAP ได้

2. **OLA through MAP**
- ใช้ร่วมกับ MAP (Migration Acceleration Program)
- ไม่สามารถขอ cash funding funding stacking restriction
- ให้สิทธิ์เข้าถึงเครื่องมือ discovery และพาร์ทเนอร์ผู้ส่งมอบบริการ Licensing (LDP)

---

## หมายเหตุ

- การขอ OLA ไม่มีผลต่อสิทธิ์ในการขอ Funding MAP Assess หากดำเนินการขอ OLA มาก่อน
- รองรับระบบจาก Microsoft, VMware, Oracle (เช่น Oracle DB, JD Edwards, PeopleSoft, E-Business Suite)

---

## เครื่องมือที่รองรับสำหรับการ Discovery

- Migration Evaluator
- Cloudamize
- Matilda Cloud
- Device 42
- Modelize IT

___
# Migration and Modernization ISV Program
## ✅ AWS Vetted & Funded ISV Tools
โปรแกรมที่ AWS คัดเลือกและให้ทุนแก่เครื่องมือจาก ISV (Independent Software Vendors) เพื่อช่วยให้ Partner สามารถดำเนินการ Migration และ Modernization ได้เร็วขึ้น มีประสิทธิภาพมากขึ้น และประหยัดมากขึ้น โปรแกรมนี้เหมาะสำหรับองค์กรที่ต้องการเร่งการย้ายระบบไปยังคลาวด์หรือปรับปรุงระบบเดิม โดยไม่ต้องลงทุนสูง และใช้เครื่องมือที่ผ่านการรับรองจาก AWS โดยตรง

___
## Request Process for Eligible Partners
1. ISV Accepts Referral from Partner

2. ISV Qualifies Opportunity Against AWS Eligibility and Creates APFP Fund Request

3. AWS Approves ISV Funding Request

4. ISV Allocates License to Customer or Partner and Provides Services

5. ISV Provides Proof of Execution to AWS

6. ISV Invoices AWS

---

**Service Level Agreement (SLA):**
ISV อาจใช้เวลาถึง 48 ชม. หลังจากได้รับ referral
___
## Migration & Modernization Automation

### Migration Automation Areas and Purposes

**1. Discovery, Assessment and Business Case Automation**
- Automate discovery and data collection.
- Automate inventory analysis, dependency mapping, instance mapping, and instance right-sizing.
- Perform TCO (Total Cost of Ownership) analysis and build business cases.

**2. Cloud Foundation Automation**
- Automate landing zone deployment.
- Implement DevOps and cloud operating model (infrastructure monitoring, logging, deployment, patching, inventory, alerting, backup).
- Implement Cloud Security and Compliance Baseline.
- Monitor governance and compliance.

**3. Server, Application, Data and Database Migration Automation**
- Automate migrations of servers, applications, data, and databases.
- Help de-risk and accelerate the migration or modernization process.

**4. Migration Planning Automation**
- Automate planning using centralized runbooks for definition, execution, and tracking.

**5. Validation Automation**
- Validate architecture against AWS Well-Architected Framework.
- Validate security and compliance requirements.

---

### Key Principles and Best Practices

- Automate with AWS Services or Partner Tooling.
- Use well-defined runbooks to standardize processes.
- Scale automation using custom solutions.
- Leverage GenAI to bridge engineering and resource skill gaps.
- Start automation early to accelerate cloud value realization.

> 💡 *Automate business-as-usual migrations to accelerate modernization.*

## AWS Modernization Workflow

### Step-by-Step Guidance to Execute Modernization

#### Phase: Assess

**1. Directional Business Case**
- Business Case Data Collection
- Business Case Build
- High-Level Design
- Business Case Presentation

**2. Detailed Discovery**
- Data Collection
- Data Analysis
- Reporting

---

#### Phase: Mobilize

**3. Application Grouping**
- Initial Application Grouping
- Application Name Grouping
- Application Move Group Definition

**4. Modernization Mobilization**
- Application Modernization Selection
- Application Modernization Assessment
- Application Design
- Application Modernization Strategy

**5. Application Prioritization**
- Application Wave Group Definition

---

#### Phase: Modernize

**6. Modernization Execution**
- Review & Refinement
- Build & Modernize
- Integrate
- Validate
- Cutover

---

#### Phase: Operate

**7. Operation & Optimization**
- Documentation & Handover
- Monitor
- Continuous Optimization
- Modernization+
___
## Discovery Data Collection Sheet

### Standardize Data Collection Sheet

- ใช้เอกสารโครงสร้างเดียว (Single Structured Document) เพื่อเก็บข้อมูลสำหรับการย้ายระบบขึ้นคลาวด์ (Cloud Migration) และการปรับปรุงระบบ (Modernization) ครอบคลุมหลายระยะ

- มีจุดประสงค์เพื่อเก็บข้อมูลที่จำเป็นในการวางแผนการย้ายระบบและการปรับปรุงระบบแอปพลิเคชัน

- ช่วยให้สามารถวิเคราะห์และรายงานข้อมูลได้ผ่านกลไกที่เป็นมาตรฐานหรือรวมศูนย์

- ข้อมูลที่ควรเก็บอย่างน้อยมี 3 กลุ่มหลัก:
- Infrastructure–Application Input Data
- Detailed Application Input Data
- Business Case Input Data
___

### Data Collection Mechanism
___
## Directional Business Case

### Directional Business Case Process Workflow

#### 1. Data Collection Mechanisms

**ใช้ Data Collection Tools**
- AWS Migration Evaluator
- AWS Application Discovery Service
- Concierto
- Matilda Cloud
- Device42
- Cloudamize
- modelizeIT
- AWS Transform
- V-Realize Ops Report
- RV-Tool
- Custom Scripts
- Hyper-V Inventory Tool
- CMDB
- APM
- Interview Sessions (Light)

#### 2. Business Case Build

**Data Centralization & Analysis:**
- ใช้ **Data Collection Sheet** เก็บข้อมูล

**ทำ Business Case Build โดยใช้ Tools**
- Migration Portfolio Assessment
- AWS Calculator
- Business Case Presentation Template

#### 3. Output

**Business Case Presentation**
- High Level Design
- Directional Business Case
- High Level Strategy
- Business Case Presentation
___
## Detailed Discovery Workstream
### Data Collection
มีวิธีการทั้งหมด 3 แบบ
- ใช้ Tools ในการเก็บข้อมูล
- ทำ Manual Discovery ด้วยตัวเอง
- ทำ Interview Session กับลูกค้า

ควรทำ 2 ใน 3 หรือทำทั้งหมดเพื่อเก็บส่วนตกหล่นของแต่ละวิธีการ
___
### Discovery Tooling Best Practices
#### Discovery and Assessment Tooling Consideration

---

#### Understand the customers requirements
- Performance & Utilization Metrics
- Application dependency discovery and mapping
- Operating Systems of the servers
- Application Analysis vs Infrastructure Analysis
- Visualization and reporting capability
- TCO/Cost analysis capability

---

#### Understand the customers constraints
- Agent-based vs Agentless
- Security and Compliance
- Data Residency
- Data Sovereignty
- Type of Data Collection
- Customers’ resource expertise – support requirements
- Customers Access Permissions

---

#### Tool Selection Best Practices
- Tools can be expensive. Besides the customers’ requirements and constraints, as partners you need to evaluate your commercial feasibility to adopt the tool.
- Pick tools that can meet as many requirements to collect data required by the data collection sheet.
- Pick tools that can be leveraged in as many phases of the migration – tooling standardization.
___

## Data Analysis
### Application Grouping

### Initial Application Grouping

#### STEP 1:
แบ่งเป็น 2 กลุ่ม:
- **Infrastructure**: OS, Shared Services, Infra Mgmt
- **Business**: แอปที่ไม่ใช่ Infra

#### STEP 2:
กำหนด grouping ลงใน tooling

#### STEP 3:
หา Dependency จาก Business → Infrastructure

### หา Infrastructure-Application Grouping (Wave 0)

#### STEP 4:
ลบเส้น dependency ที่ไม่จำเป็น

#### STEP 5:
กลุ่ม Infrastructure จะจัดเป็น **Wave 0** และ migrate ก่อน
- migration strategies:
- Rehost
- Repurchase
- Re-platform
- Extend Services

Application Name Mapping

#### STEP 6:
- Group server ตาม tiers (Web/App/DB)
- ใช้ hostname หรือสัมภาษณ์เพื่อ mapping
- เป้าหมายคือกำหนด **Application Name Group**

---

### Grouping Applications to Move Together

#### STEP 7:
วิเคราะห์ชนิดของ dependency:
- Application → Infrastructure
- Business App → Business App
- Application Tier → Component
- Business App → Infra Services (AD, Logging, Monitoring)

---

### Move Group Definition

#### STEP 8:
กำหนด Move Group โดยใช้หลักการ:
**Move Group = Connection Critical + Private Connection**

- ใช้กับเกือบทุกแอป ยกเว้นที่ต้องพิจารณาด้าน cost หรือ compliance
- พิจารณาด้วยว่าแอปที่ใช้ resource ร่วมกันควรรวมกลุ่มหรือแยก
- ต้องกำหนดหมายเลข Move Group ให้ชัดเจน
___

# Application Modernization Selection

ใช้แนวทางการกรองแบบ Funnel เพื่อตัดสินใจเลือกแอปพลิเคชันสำหรับการ Modernize

## ขั้นตอนการคัดเลือกแอปพลิเคชัน

### 1. All
- เริ่มจากแอปพลิเคชันทั้งหมดที่มีอยู่
- จัดทำ Inventory / Application List

### 2. Feasible
- ตรวจสอบความเป็นไปได้ทางเทคนิค
- ใช้ Feasibility Checklist เพื่อตอบคำถาม: *"Is it possible?"*

### 3. Viable
- วิเคราะห์เหตุผลทางธุรกิจ
- ใช้ Rationale Checklist เพื่อตอบคำถาม: *"Should we do it?"*

### 4. Selected
- ดำเนินการวิเคราะห์และจัดลำดับความสำคัญเพิ่มเติม
- พร้อมเข้าสู่การใช้งานบนบริการของ AWS

### หมายเหตุจาก Assess Phase
- แอปพลิเคชันที่ได้รับการคัดเลือกจะถูกพิจารณาทั้งในมุม **ระยะสั้น** และ **ระยะยาว**:

**Short Term:**
- Retire
- Retain
- Migrate / Rehost
- Repurchase

**Long Term:**
- Modernize
- Re-architect
- Refactor

---

# Application Modernization Selection Criteria

การจัดลำดับความสำคัญของแอปพลิเคชันสำหรับการ Modernize โดยใช้เกณฑ์ 2 แกน:

## แกนการประเมิน

### Feasibility
- ตรวจสอบว่ามีปัจจัยที่อาจขัดขวางการ Modernize หรือไม่

### Rationale
- ตรวจสอบว่ามีเหตุผลทางธุรกิจที่เพียงพอหรือไม่

## กลุ่มแอปพลิเคชันตามเกณฑ์

### กลุ่ม: Low Friction Modernization
- ขับเคลื่อนด้วยเทคโนโลยี
- เหมาะแก่การ Relocate, Replatform, ใช้เครื่องมือ Modernize
- ควรจัดลำดับความสำคัญ

### กลุ่ม: Complex Transformation
- ขับเคลื่อนด้วยธุรกิจ
- ต้องการ Refactor, Re-architect, หรือพิจารณาใช้ SaaS
- ควรทำในคลื่นถัดไป (Later wave)

### กลุ่ม: Tech Driven Modernization
- ขับเคลื่อนด้วยเทคโนโลยี
- ต้อง Relocate, Replatform
- ต้องอธิบายคุณค่าด้าน IT และ Operation ให้ลูกค้าเข้าใจ

### กลุ่ม: Migration
- ไม่มีคุณค่าทางธุรกิจหรือเทคนิคเด่นชัด
- อาจ Retain, Rehost, Retire
- พิจารณา revisiting ใหม่ในภายหลัง

___
# Modernization Assessment (MODA)

## MODA Objectives, Goals & Overview

- The Modernization Assessment Workshop (MODA) จะจัดขึ้นในช่วง Application Mobilization Phase ของกระบวนการ Modernization engagement

- MODA มีจุดประสงค์เพื่อทำความเข้าใจแอปพลิเคชันในด้านต่าง ๆ ดังนี้:
- เข้าใจตัวขับเคลื่อนธุรกิจและ KPI
- เข้าใจความท้าทายทางเทคนิค
- เข้าใจทักษะด้าน Modernization ของลูกค้าในปัจจุบัน

- MODA ช่วยให้การสนทนากับลูกค้ามุ่งไปสู่ความสามารถในการปรับปรุงและพัฒนาแอปพลิเคชัน

- การใช้แบบสอบถามมาตรฐานช่วยให้ทีมงานและผู้เชี่ยวชาญสามารถตัดสินใจโดยอิงจากข้อมูลได้ดีขึ้น

- MODA ให้คำแนะนำเชิงลึกที่แม่นยำมากขึ้นตามผลลัพธ์จากการประเมิน

- MODA เป็นขั้นตอนที่จำเป็นก่อนจะดำเนินการ ModAx

### Process
- Prerequisite questions
- Business Questions
- Application Questions
- DevOps Questions
- Debrief Presentation / Roadmap

# AWS Cloud Reference Architecture

## Define a baseline architecture that all architecture must comply too

- A reference architecture is a blueprint or a set of guidelines, best practices, and standards that help developers design and implement systems.
- Review current reference architecture, re-design for AWS Cloud following AWS Well Architected Best Practices and reference implementations from AWS Architecture Center.
- AWS Architecture Center provides well-documented reference architecture for Industry Solutions, ISV Solutions, Technology and Business.
- Ensure AWS Cloud defined reference architecture covers the reference architecture coverage areas at minimum.

## Reference Architecture Coverage Areas
- Application Operational Components
- AWS Services
- Application Component / Function
- Application Code
- Application Network Connectivity
- Data Management, Flow and Stack
- Application Security
- Application Compliance
- Application Tiers
___
# Storage Assessment Methods

## Options to Collect Storage Information from Current Environment

---

## Agentless Collector

- Leverages NetApp Data Infrastructure Insights (NetApp DII) or AWS DataSync Discovery
- Collects metrics for capacity planning, application space savings and performance requirements, databases, and shared storage
- Right-sizes the target AWS storage services based on actual utilization and performance needs
- Maps hosts and storage arrays data to the most appropriate AWS storage services
- Supports enterprise Block and File storage arrays
- Delivers a higher level of accuracy using actual data

---

## Using Existing Data

- Bypasses environmental constraints preventing deployment of on-premises tooling
- Facilitates simple data upload with standard import template
- Utilizes inventory and usage data provided by the customer via monitoring exports and/or other tools
- Leverages industry benchmarks where there are gaps in the data
- Eliminates collection period for time-sensitive engagements
___
# Application Migration & Modernization Strategies

## R1: Retain

**Pattern Description**
- Client will keep host/application in their source environment
- Minimal analysis/validation of scope and application affinity
- Dependency on integrating service management

**Example**
- Mainframe
- UNIX host/applications

---

## R2: Retire

**Pattern Description**
- Application and host decommission on source
- No migration to target
- Application owner approvals needed

**Example**
- Existing Decom Program Scope
- UNIX, SCO
- Clustered hosts for DR, alternative HA hosts

---

## R3: Re-Locate

**Pattern Description**
- VMware running on EVS
- Container to Managed Container

**Example**
- Move of existing VMware environments to AWS
- Move to EKS/ECS Fargate

---

## R4: Re-Hosting

**Pattern Description**
- Like-for-like application migration to target cloud
- Minimal effort to make the application work on the target cloud infrastructure
- Storage migration will be needed
- UAT – Some level of application testing

**Example**
- Simple to Medium V2V, P2V
- Storage: Local to DASD
- RHEL 6 and above
- Win 2008 and above

---

## R5: Re-Purchase

**Pattern Description**
- Moving to a Software as a Service option

**Example**
- Migration to AWS Marketplace Options
- Migration to Salesforce

---

## R6: Re-Platform

**Pattern Description**
- Up-version of the OS and/or Database onto the target cloud
- Storage migration will be needed (without application change)
- Some level of application changes
- Application reinstallation on the cloud
- UAT is highly recommended

**Example**
- W2K3 to Win 2012; Win 2008 and below
- RHEL below
- Oracle 8 to 11+
- MS SQL state technology (RDS)
- Move to EKS/ECS from VM

---

## R7: Re-Factor

**Pattern Description**
- OS and/or Database porting
- Middleware and application change to cloudify an application
- Data conversion; Database transition to MySQL, Aurora, etc.
- UAT required

**Example**
- AIX to Linux
- Oracle to SQL; SQL to Aurora
- Middleware, IBM products

---

## Modernization Strategy Notes

- Modernization strategies are:
- Re-Purchase to SaaS
- Re-Platform to AWS Managed Services
- Re-Factor – OS, Code, or Schema
- Not all modernization strategies result in MAP Modernization SPI.
___
# Application Prioritization

## Criteria

- Process to prioritize Application Move Group
- Move Groups are prioritized into Wave Groups using the prioritization criteria.
- Partners should develop/leverage Application Prioritization Scoring sheet to score the Application by Move Groups.
- Wave number defines the order of Migration or Modernization.
- Pilot Migrations are defined as Wave Group or WG1.

> Build a prioritization scoring sheet using the Application Prioritization Scoring Sheet or Detailed Assessment Sheet
> (Application Modernization Feasibility – Rationale Checklist) as guidance for build.

### Criteria

#### Business Criticality
- Revenue Impact
- Operational Impact
- SLA/OLA
- RTO/RPO
- Number of Users
- Risk
- Security & Compliance
- Compelling Events

#### Technical Challenges
- Number of Servers
- Number of Data Centres
- Number of Dependencies
- Hybrid Requirements
- Multi-Cloud Requirements
- Environment
- Application Design Requirements
- Multi Region
- Licenses

#### Move Effort
- Source Type
- Target Services
- Migration or Modernization Strategy
- Modernization Types
- Number of Migration or Modernization Phases
- Automation Usage
- Accelerator Usage
- Resource Availability
___
### Migration & Modernization Wave Plan

- Document Application Wave Group migration high-level tasks into Work Breakdown Structure (WBS).
- The Work Breakdown Structure (WBS) must include tasks from Migrate or Modernization Phase and Rollback tasks defined in the strategy phase.
- Charter high-level end-to-end Wave Group timeline Gantt Chart.
- For WG1 (Pilot Application Migration or Modernization), update the initial Work Breakdown Structure (WBS) with detailed tasks and timeline.
- The Wave Group Gantt chart should reflect the detailed timelines for WG1 (minimum).
- Other Wave groups will be updated post assessment/strategy

# Modernization Execution

## Modernization Execution Phases

### 1. Review & Refinement
- Application state discovery review
- Application backlog refinement
- Modernization strategy review & refinement
- Cutover Plan Refinement
- Rollback Plan Refinement

### 2. Build & Modernize
- Execution of Modernization as per defined modernization strategy
- Use automation runbook developed
- Use tools

### 3. Integrate
- Ensure connectivity requirements
- Integrate with landing zone components
- Integrate with inter-dependency application
- Integrate with operating model application
- Integrate with security and compliance applications

### 4. Validate
- AWS Well Architected Validation
- Integration Validation
- Functional validation
- Performance validation
- Vulnerability assessment

### 5. Cutover
- Use cutover plan to execute cutover process
- Use rollback plan if cutover unsuccessful
- Document learnings to improve process in next wave

---

# Modernization Experience Based Acceleration (ModAx)

## Modernization EBA (ModAx) Phases

---

### Qualification (< 1 Day)
- Program Qualification check
- Guidance on engagement activities required

---

### Assessment, Application Design & Strategize (1–2 Weeks)
- Executive alignment and buy-in
- Establish Mod priorities, and check-in cadence
- Establish CCOE team for kick-off
- Voice of Customer
- Role of CCOE
- Introduce Mod Pathways
- Workload discovery – select 2 strategic applications
- Mod Assessment Workshop
- Identify MVPs for selected application(s)
- Match to pathways and create target architecture
- Recommendations debrief and buy-in

---

### Build & Modernize (5–7 Weeks)
- CCOE enablement, cloud native deep dive tech modules mapped against selected pathways
- Planning and Enablement for EBA
- Build & Deploy MVPs during 3 days EBA Party
- Review recommendations, roadmap, and next steps

---

### Scale (Ongoing Mod post engagement)
- Apply repeatable patterns / learnings to broader portfolio
- Off-ramp to other programs (if required
___
# Application Documentation

## Application Report Structure

The Application Documentation should include and highlight the following sections (recommended structure):

### 1. Executive Summary
- Brief overview of the application and purpose of documentation.

### 2. Application Overview
- General description of the application and its functionality.

### 3. Modernization Strategy
- Outline the approach taken for modernization.

### 4. Technical Specification
- **Service specification**
- **Service configuration**
- **ISV tooling**

### 5. Implementation Details
- **Application backlog**
- **Implementation step**

### 6. User Documentation
- **Guides & Runbooks**

### 7. Change Management
- **Communication Plan**
- **Change Requirement**

### 8. Security & Compliance
- **Services**
- **Controls**
- **Policies**
- **Compliance & Governance**

### 9. Project Closure
- **Lesson learnt**
- **Strategic Roadmap**
- **Support Transition**
- **Knowledge transfer and procedures**
___