บทที่ 12: Migration Strategy & Execution

1. วัตถุประสงค์บท

บทนี้เป็นเจ้าของ Domain 4 ของ SAP-C02 (“Accelerate Workload Migration and Modernization”) ในส่วนที่ว่าด้วย การวางแผนและลงมือย้าย workload จริงเข้าสู่ AWS (Domain 4 มีน้ำหนัก ~20% ดูบทที่ 01) โดยเน้นมุมของ Solutions Architect ระดับ Professional ที่ต้องออกแบบ program การย้ายทั้ง portfolio ไม่ใช่แค่ย้ายเครื่องเดียว — ต้องประเมิน readiness, จัด portfolio, เลือกกลยุทธ์ต่อ application, วางลำดับ wave, และบริหาร cutover/rollback ให้ธุรกิจไม่สะดุด

เป้าหมายเมื่อจบบท คุณต้องตอบข้อสอบที่ผสมประเด็นเหล่านี้ได้อย่างมั่นใจ:

• ใช้ AWS Cloud Adoption Framework (CAF) และ Migration Readiness Assessment (MRA) เป็นกรอบประเมินความพร้อมองค์กร และเข้าใจ 3-phase migration (Assess → Mobilize → Migrate & Modernize)
• เลือก 1 ใน 7 Rs (Rehost, Replatform, Repurchase, Refactor/Re-architect, Retire, Retain, Relocate) ให้ตรงกับ constraint ของโจทย์ โดยเฉพาะสัญญาณ lift-and-shift, cannot modify code, minimize migration effort, end-of-life
• ออกแบบเฟส discovery & planning ด้วย AWS Application Discovery Service (agent/agentless), AWS Migration Hub, และ AWS Migration Evaluator เพื่อทำ dependency mapping + business case/TCO
• เลือก execution tool ให้ถูกงาน: AWS Application Migration Service (MGN) สำหรับ rehost, AWS DMS สำหรับ database (ดูบทที่ 07), DataSync/Transfer Family/Snow สำหรับ data (ดูบทที่ 06) — และแยก MGN vs DRS ให้ขาด (ดูบทที่ 08)
• วาง wave plan ตาม dependency/complexity/risk พร้อม pilot migration และเข้าใจ hybrid interim state ระหว่างย้าย
• ออกแบบ landing zone readiness ก่อนย้าย (ต่อยอดจากบทที่ 02/03/04) และบริหาร cutover + rollback อย่างปลอดภัย

ขอบเขตที่บทนี้ไม่ลงลึก (cross-reference แทน): modernization pattern เชิงลึก (strangler fig, decomposition เป็น microservices, App2Container path) → บทที่ 13; รายละเอียด storage transfer service (DataSync/Transfer Family/Snow/Storage Gateway internals) → บทที่ 06; DRS ในฐานะ DR strategy ต่อเนื่อง → บทที่ 08 (บทนี้ใช้ DRS เป็นเพียงจุดเทียบกับ MGN); กลไก DMS full load + CDC และ SCT → บทที่ 07.

บทนี้สืบทอด convention <details><summary>เฉลย</summary> และ bullet “ทำไมตัวเลือกอื่นผิด” จากบท 01–11 และใช้ตาราง “requirement/keyword → กลยุทธ์/บริการ → เหตุผล/trade-off” เป็นรูปแบบหลักของส่วนที่ 3

---

2. แนวคิดหลัก

2.1 AWS Cloud Adoption Framework (CAF): กรอบความพร้อมองค์กร

ก่อนจะลงมือย้ายเครื่องแม้แต่เครื่องเดียว ข้อสอบ Pro ชอบถามในมุม “องค์กรพร้อมหรือยัง อะไรคือ gap” — คำตอบเชิงกรอบคือ AWS Cloud Adoption Framework (CAF) ซึ่งเป็น mental model ที่แบ่งความสามารถ (capability) ที่องค์กรต้องมีออกเป็น 6 perspective:

Perspective	เจ้าของหลัก	ตอบคำถาม
Business	ผู้บริหาร/BU	cloud สอดคล้อง business outcome และ ROI ไหม
People	HR/ผู้นำ	ทีมมี skill/culture/organization model พร้อมไหม
Governance	PMO/finance	จัดการ portfolio, benefit, risk, cost อย่างไร
Platform	สถาปนิก/วิศวกร	สร้าง/พัฒนา cloud platform (landing zone, IaC) อย่างไร
Security	CISO/security	identity, control, compliance เป็นอย่างไร
Operations	ops/SRE	run และ recover workload บน cloud อย่างไร

3 perspective แรก (Business/People/Governance) มักเรียกว่าด้าน “foundational/organizational” ส่วน 3 หลัง (Platform/Security/Operations) เป็นด้าน “technical”. ประเด็นออกสอบ: เมื่อโจทย์บอกว่าองค์กร “มี technical plan แล้วแต่ทีมยังไม่มี skill / ไม่มี governance การจัดการ cost” นั่นคือ gap ที่ People/Governance perspective — คำตอบไม่ใช่ “เริ่มย้ายเลย” แต่คือ “ปิด gap เชิง organization ก่อน” (training, Cloud Center of Excellence/CCoE, cloud financial management)

2.2 3-Phase Migration และ Migration Readiness Assessment (MRA)

AWS วาง migration journey เป็น 3 เฟส ที่ควรจำลำดับให้แม่น:

1. Assess — ประเมินความพร้อมและสร้าง business case ระดับ portfolio. เครื่องมือหลักคือ Migration Readiness Assessment (MRA) — workshop ที่ให้คะแนน readiness ตาม 6 perspective ของ CAF เพื่อชี้ gap ก่อน mobilize; ประกอบกับ Migration Evaluator สำหรับ TCO/business case
2. Mobilize — ปิด gap ที่พบใน Assess: สร้าง landing zone (ดู 2.9), ตั้ง CCoE (Cloud Center of Excellence), ทำ detailed discovery + dependency mapping, สร้าง migration plan/wave, และทำ pilot migration เพื่อเรียนรู้และปรับ runbook
3. Migrate & Modernize — ลงมือย้ายจริงเป็น wave ด้วย execution tool (MGN/DMS/DataSync) พร้อม modernize บาง workload (ดูบทที่ 13)

จุดหลอกที่ออกสอบ: หลายโจทย์ให้สถานการณ์ที่ทีม “อยากรีบย้ายทั้ง 2,000 servers ทันที” — คำตอบที่ถูกในเชิง Pro มักคือ ทำ discovery/assessment ก่อน (assess phase) เพราะการย้ายโดยไม่รู้ dependency = เสี่ยง cutover ล้มและ downtime. คำว่า before migrating, understand dependencies, build a business case ชี้ไปที่ Assess/Mobilize เสมอ

2.3 The 7 Rs: กลยุทธ์การย้ายราย application

หัวใจของ Domain 4 คือการเลือก 1 ใน 7 Rs ให้ตรง constraint. ต้องท่องนิยาม + ตัวอย่าง + สัญญาณคำในโจทย์ให้ครบ:

R	นิยามสั้น	ตัวอย่าง/สัญญาณในโจทย์	effort/ประโยชน์ระยะยาว
Retire	เลิกใช้ ปิดทิ้ง ไม่ย้าย	app ซ้ำซ้อน/ไม่มีใครใช้ (“no longer used”, “decommission”)	effort ต่ำสุด, ประหยัดทันที
Retain	คงไว้ที่เดิมชั่วคราว (“revisit later”)	app ที่ยังไม่คุ้มย้าย, รอ vendor, มี compliance ผูก on-prem, ใกล้ EOL แต่ยังจำเป็น	ไม่ย้าย (ยัง)
Relocate	ย้าย “ทั้งกล่อง” โดยไม่แปลง เช่น VMware → VMware Cloud on AWS	move VMware workloads without changing hypervisor / in days [uncertain สถานะ VMware Cloud on AWS]	effort ต่ำมาก, ไม่ปรับ OS
Rehost	“lift-and-shift” ย้าย server ตามสภาพขึ้น EC2	lift-and-shift, cannot modify application, fastest migration, minimal changes	effort ต่ำ, ประโยชน์ cloud-native ต่ำ
Replatform	“lift-tinker-and-shift” ย้ายพร้อมปรับเล็กน้อย เช่น self-managed DB → RDS	move database to managed service, reduce ops without rewriting app	effort ปานกลาง, ลด ops
Repurchase	เปลี่ยนไปใช้ SaaS/สินค้าใหม่ (“drop and shop”)	ย้าย on-prem CRM → Salesforce, email → WorkMail/M365, replace with SaaS	effort ต่ำ-ปานกลาง, เปลี่ยน licensing model
Refactor / Re-architect	เขียน/ออกแบบใหม่ให้ cloud-native (microservices, serverless)	improve agility/scale, decompose monolith, มี business driver แรง	effort สูงสุด, ประโยชน์สูงสุด (ลงลึกบทที่ 13)

เกณฑ์เลือก (decision heuristic ที่ใช้ตัด distractor):

• โจทย์เน้น speed / minimal effort / cannot change code / tight deadline → Rehost (MGN) เป็นค่า default
• โจทย์เน้น reduce operational overhead แต่ยัง “without re-writing the application” → Replatform (เช่นย้าย DB ไป RDS/Aurora, ย้าย web ไป Elastic Beanstalk/ECS)
• โจทย์เน้น agility / scalability / long-term modernization และยอมลงทุน → Refactor (ดูบทที่ 13 — บทนี้ไม่ลงลึก)
• โจทย์บอก app “commercial off-the-shelf” ที่มี SaaS ทดแทน → Repurchase
• โจทย์บอก server “rarely used / redundant” → Retire; “compliance ties it to on-prem / not worth moving yet” → Retain
• โจทย์บอก “VMware-based, move as-is quickly, keep same tooling” → Relocate [uncertain — ตรวจสถานะบริการปัจจุบัน]

เชื่อมบทที่ 01: constraint cannot modify code / lift-and-shift ที่ถอดจาก keyword ในบทแรก ชี้ไปที่ Rehost เสมอ และเป็นตัวตัด Refactor ออกทันที (ต่อให้ Refactor “ดีกว่า” ในทางทฤษฎี ก็ผิดเพราะละเมิด constraint)

2.4 Discovery & Planning: รู้ก่อนย้าย

การย้ายที่ล้มเหลวเกือบทั้งหมดมาจาก ไม่รู้ dependency (เช่นย้าย app server แต่ลืมว่ามันคุยกับ license server ที่ยังอยู่ on-prem). เครื่องมือ discovery หลักของ AWS:

AWS Application Discovery Service (ADS) — เก็บ inventory + performance + dependency ของ on-prem server มี 2 โหมด:

โหมด	วิธีทำงาน	เมื่อไหร่ใช้	ข้อจำกัด
Agentless (OVA appliance บน VMware vCenter)	deploy appliance ตัวเดียวใน vCenter เก็บข้อมูล VM ทั้งหมด	สภาพแวดล้อม VMware, ไม่อยากลง agent ทุกเครื่อง, least intrusive	ได้ข้อมูลระดับ VM (ไม่ลึกถึง process-level network dependency), เฉพาะ VMware
Agent-based (Discovery Agent)	ลง agent บนแต่ละ server (Linux/Windows)	ต้องการ process-level + network connection dependency ละเอียด, physical server หรือ non-VMware	ต้องลงทุกเครื่องที่ต้องการข้อมูลลึก

ข้อมูลจาก ADS ไหลเข้า AWS Migration Hub (ดูด้านล่าง). อีกทางคือ import ข้อมูลจากเครื่องมือ third-party (เช่น RVTools) ผ่าน Migration Hub import เมื่อ deploy agent/appliance ไม่ได้

AWS Migration Hub — single pane of glass ที่รวม discovery data และ ติดตามสถานะการย้ายข้ามหลายเครื่องมือ/หลาย region (MGN, DMS ฯลฯ) ในที่เดียว. ฟีเจอร์สำคัญ:

• Migration Hub Strategy Recommendations — วิเคราะห์ inventory แล้วแนะนำ R ที่เหมาะต่อ application
• Migration Hub (application grouping) — จัดกลุ่ม server เป็น application เพื่อ track ความคืบหน้าเป็นหน่วยธุรกิจ
• Migration Hub Refactor Spaces — สร้าง infrastructure สำหรับ strangler fig pattern (application ค่อย ๆ route ไป service ใหม่ทีละส่วน) — รายละเอียด refactor อยู่บทที่ 13; บทนี้แค่รู้ว่ามันคือ “โครงให้ทำ incremental refactor”

AWS Migration Evaluator (เดิม TSO Logic) — สร้าง business case / TCO เปรียบเทียบต้นทุน on-prem ปัจจุบันกับ projected cost บน AWS โดยเก็บ utilization จริงแล้วจับคู่ right-sized EC2 + licensing scenario (เช่น BYOL vs license-included). ใช้เมื่อโจทย์ถาม justify migration to leadership, quantify cost savings, build a business case — ต่างจาก ADS ที่เน้น technical discovery/dependency. Compute Optimizer (บทที่ 10/11) เป็น right-sizing ของ workload ที่ อยู่บน AWS แล้ว ไม่ใช่ pre-migration business case — จุดหลอกที่สลับกัน

Portfolio analysis & dependency mapping — เอาผล discovery มาจัดกลุ่ม: application ไหนพึ่งกัน (dependency), ตัวไหน complexity สูง/ต่ำ, business criticality เท่าไร → เป็นวัตถุดิบของ wave planning (2.6)

2.5 Execution Tools: เลือกเครื่องมือให้ถูกงาน

AWS Application Migration Service (MGN) — บริการ rehost หลักของ AWS (แทน CloudEndure Migration เดิม) ทำ continuous block-level replication จาก source server (physical/VMware/Hyper-V/other cloud) ไป staging area ราคาถูก ใน AWS แล้วเมื่อพร้อมก็สั่ง test/cutover เพื่อ launch เป็น EC2 instance จริง. กลไก:

• ลง AWS Replication Agent บน source → replicate ต่อเนื่องเข้า staging (EBS volume ราคาถูก + instance เล็ก)
• ทดสอบได้ไม่กระทบ production (launch test instance จาก replica ล่าสุด)
• cutover window สั้น เพราะข้อมูล sync มาเรื่อย ๆ แล้ว เหลือแค่ finalize
• รองรับ post-launch actions / templates เพื่อ automate การ modernize เล็กน้อยตอน launch (เช่นลง agent, ปรับ config) — ทำให้ replatform เบา ๆ ได้บางส่วน

MGN vs DRS — จุดหลอกที่ออกสอบซ้ำ (ตอบ cross-reference จากบทที่ 08): ทั้งคู่ทำ continuous block-level replication เหมือนกัน แต่ เจตนาต่างกัน:

• MGN = migration ครั้งเดียว — ย้ายเสร็จแล้ว decommission source, หยุด replication, ไม่ failback. keyword: migrate, move to AWS, retire on-prem data center
• DRS = disaster recovery ต่อเนื่อง — replicate ไปเรื่อย ๆ เพื่อ failover/failback ซ้ำได้ เมื่อเกิดภัย. keyword: disaster recovery, RPO seconds, fail back to on-prem (ดูบทที่ 08) ถ้าโจทย์พูดว่า “ย้าย data center ปิด on-prem” → MGN; ถ้า “รักษา DR copy พร้อม failover” → DRS. ตอบสลับกันคือกับดักคลาสสิก

AWS DMS (Database Migration Service) — สำหรับย้าย database โดยเฉพาะ ทำ full load + CDC เพื่อ near-zero downtime; heterogeneous ต้อง SCT/DMS Schema Conversion ก่อน (กลไกเต็มดูบทที่ 07). ใน migration program: มักใช้ MGN ย้าย app tier + DMS ย้าย database tier พร้อมกัน แล้ว cutover ให้ตรงจังหวะ

Data transfer tools (กลไกเต็มดูบทที่ 06 — บทนี้เน้นบทบาทใน migration wave):

• AWS DataSync — online bulk file/object transfer (NFS/SMB/HDFS/S3) พร้อม incremental + validation → เหมาะ file server data ที่มี network พอ
• AWS Transfer Family — managed SFTP/FTPS endpoint สำหรับ partner ที่ต้อง protocol เดิม (ไม่ใช่ tool ย้าย bulk one-off แต่เป็น interface ถาวร)
• AWS Snow Family — offline transfer เมื่อ bandwidth ไม่พอ/ข้อมูลมหาศาล (petabyte); Snowball Edge ยัง compute ได้ที่ edge ระหว่างขน

VMware Cloud on AWS — สำหรับ Relocate: ยก VMware vSphere workload ขึ้น bare-metal ใน AWS โดยไม่แปลง hypervisor/OS ย้ายได้เร็ว (วัน) ใช้ tooling VMware เดิม (vMotion/HCX) — เหมาะเมื่อองค์กรลงทุน VMware หนักและต้องออกจาก data center เร็วโดยยังไม่ปรับสถาปัตยกรรม. [uncertain: สถานะเชิงพาณิชย์/ownership ของบริการนี้เปลี่ยนหลัง Broadcom เข้าซื้อ VMware — ตรวจสอบชื่อ/ความพร้อมล่าสุดก่อนตัดสินใจจริง]

2.6 Wave Planning และ Pilot Migration

การย้าย portfolio ใหญ่ทำเป็น wave (คลื่น) — จัด application เป็นกลุ่มที่ย้ายพร้อมกันเป็นรอบ ๆ แทนการย้ายทีเดียวหมด. หลักการจัด wave:

• จัดตาม dependency — application ที่คุยกันแน่นควรอยู่ wave เดียวกัน เพื่อลด latency ข้าม on-prem↔cloud และลดช่วง hybrid ที่เปราะ (แยก dependent apps คนละ wave = traffic วิ่งข้าม WAN นาน = ช้า/เสี่ยง)
• เรียงตาม complexity/risk จากต่ำไปสูง — เริ่ม wave แรกด้วย app ง่าย/ความเสี่ยงต่ำ (dev/test, stateless, dependency น้อย) เพื่อสร้าง momentum + เรียนรู้ + ปรับ runbook ก่อนแตะ mission-critical
• business criticality — mission-critical มักย้ายหลังทีมชำนาญแล้ว

Pilot migration (wave 0) — เลือก application ตัวแทน 1–2 ตัวย้ายก่อนเพื่อ validate landing zone, runbook, tooling และ estimate จริง ก่อน scale ทั้ง portfolio. โจทย์ที่พูด prove the approach, validate before full rollout, reduce risk of large migration → คำตอบคือ pilot/wave-based ไม่ใช่ big-bang

2.7 Online vs Offline Bulk Transfer (เชื่อมบทที่ 06)

ระหว่าง migration ต้องตัดสินใจว่าจะขนข้อมูล online (ผ่าน network) หรือ offline (Snow) — สูตรตัดสินใจ (ดูบทที่ 06 หัวข้อ transfer):

• คำนวณเวลา online = ปริมาณข้อมูล ÷ bandwidth ที่ใช้ได้จริง. ถ้าเวลาที่ได้ เกินกรอบ deadline/ไม่สมเหตุผล (เช่น 100 TB บนสาย 100 Mbps ใช้เวลาหลายเดือน) → offline Snow
• online (DataSync) เหมาะเมื่อ bandwidth เพียงพอ, data ยัง เปลี่ยนแปลงต่อเนื่อง (DataSync incremental sync ตามได้), หรือย้าย AWS↔AWS
• offline (Snowball) เหมาะเมื่อ bandwidth จำกัด/แพง, one-time bulk, ยอม latency การขนของทางกายภาพ (วัน-สัปดาห์)
• ข้อควรจำ: แม้ใช้ Snow ย้าย bulk ก้อนใหญ่ ก็มักตาม DataSync/DMS CDC เก็บ delta ที่เกิดระหว่างขน Snow เพื่อลด downtime ตอน cutover

2.8 Hybrid Interim State และ Network Cutover (เชื่อมบทที่ 04)

ระหว่าง migrate ระบบจะอยู่ในสภาพ hybrid (บางส่วนบน AWS บางส่วน on-prem) ชั่วคราว ซึ่งต้องมี connectivity ที่เสถียร:

• ต้องมี AWS Direct Connect หรือ Site-to-Site VPN ระหว่าง on-prem↔VPC เพื่อให้ dependent apps ที่ยังไม่ย้ายคุยกับตัวที่ย้ายแล้วได้ (ดูบทที่ 04). โจทย์ที่ต้องการ consistent low-latency during migration → DX; quick/temporary/backup → VPN
• workload ที่ domain-joined กับ Active Directory ต้องวางแผน AD ในช่วง hybrid: ใช้ AD Connector ชี้กลับ on-prem AD หรือ AWS Managed Microsoft AD + two-way trust เพื่อให้ rehosted servers ยัง authenticate ได้ (ตอบ cross-reference บทที่ 03)
• ต้องระวัง CIDR overlap ระหว่าง on-prem กับ VPC ที่จะทำให้ route ไม่ได้ (ดูบทที่ 04 — วางแผน CIDR/IPAM ก่อน)
• network cutover — เปลี่ยน DNS ให้ชี้จาก on-prem endpoint ไป AWS endpoint (Route 53 weighted/failover routing ช่วยทยอยเปลี่ยน traffic ได้) โดยระวัง DNS TTL (ตั้ง TTL ต่ำก่อน cutover เพื่อให้เปลี่ยนเร็ว — ดูบทที่ 08)

2.9 Landing Zone Readiness ก่อน Migrate (เชื่อมบทที่ 02/03/04)

ต้องมี landing zone พร้อมก่อนย้าย — นี่คือผลลัพธ์ของเฟส Mobilize และเป็น dependency แข็งของ Migrate. องค์ประกอบที่ต้องพร้อม (รายละเอียดในบทที่อ้าง):

• Multi-account structure + OU + SCP guardrails ผ่าน AWS Control Tower (ดูบทที่ 02) — มี account ปลายทางสำหรับ workload ตาม environment
• Identity & access — IAM Identity Center + permission set, cross-account role, federation กับ corporate IdP/AD (ดูบทที่ 03)
• Network foundation — VPC/subnet/CIDR ที่ไม่ overlap, Transit Gateway hub, DX/VPN, DNS resolver (ดูบทที่ 04)
• Security baseline — encryption (KMS), logging (CloudTrail org trail → Log Archive account), GuardDuty/Config (ดูบทที่ 09)
• Observability + operations — CloudWatch, SSM สำหรับ manage fleet ที่ย้ายมา (ดูบทที่ 11)

จุดออกสอบ: โจทย์ที่บอก “องค์กรจะย้าย 500 servers แต่ยังไม่มี multi-account/network/security foundation” — คำตอบเชิง Pro คือ สร้าง landing zone (Control Tower) ก่อน ไม่ใช่ย้ายเข้า account เดียวแล้วค่อยจัดทีหลัง (blast radius/governance พังภายหลังแก้ยาก)

2.10 Cutover และ Rollback

Cutover = จังหวะสลับให้ traffic จริงไปที่ระบบบน AWS. หลักการออกแบบให้ปลอดภัย:

• ทำ test launch ก่อนจริงเสมอ — MGN launch test instance จาก replica เพื่อ validate function ก่อน cutover จริง โดยไม่กระทบ production และไม่หยุด replication
• ลด cutover window — ให้ MGN/DMS sync ข้อมูลมาต่อเนื่องจน delta เหลือน้อย แล้ว cutover เฉพาะช่วง finalize (หยุด write ที่ source สั้น ๆ → sync delta สุดท้าย → เปลี่ยน DNS)
• rollback plan ต้องมีก่อน cutover — เพราะ MGN ไม่ failback อัตโนมัติ วิธี rollback ที่ปลอดภัยสุดคือ ยัง keep source on-prem รันอยู่ (ไม่ decommission) จนกว่าจะ validate บน AWS ครบ แล้วเปลี่ยน DNS กลับได้ทันทีถ้ามีปัญหา. อย่า decommission source เร็วเกินไป
• cutover strategies: big-bang (ทีเดียว, เสี่ยงสูง, เหมาะ app เล็ก/ไม่มีทางเลือก) vs phased/canary (ทยอยย้าย user/traffic ด้วย Route 53 weighted routing — validate ทีละส่วน rollback ง่าย) — โจทย์ที่เน้น minimize risk / minimal downtime มักตอบ phased + keep source รอ rollback

---

3. ตารางเปรียบเทียบบริการ

3.1 เลือก R ให้ตรง keyword

keyword/constraint ในโจทย์	R ที่ตอบ	เหตุผล / ตัวตัด distractor
lift-and-shift, cannot modify code, fastest, minimal effort	Rehost (MGN)	ไม่แตะ app; Refactor ผิดเพราะละเมิด “cannot modify”
reduce ops without rewriting, move DB to managed	Replatform	ได้ประโยชน์ managed โดยไม่ rewrite; Refactor over-engineered
improve agility/scale long-term, decompose monolith	Refactor (บทที่ 13)	มี business driver ยอมลงทุน; Rehost ไม่ได้ประโยชน์ cloud-native
commercial off-the-shelf ที่มี SaaS ทดแทน	Repurchase	ถูก/เร็วกว่าย้ายเอง; Rehost = จ่าย license เดิมโดยไม่ได้ประโยชน์
redundant / no longer used	Retire	ประหยัดทันที; ย้ายของไม่ใช้ = เสียเงินเปล่า
compliance ties to on-prem, revisit later, near EOL	Retain	ยังไม่คุ้ม/ย้ายไม่ได้; อย่าฝืนย้าย
VMware as-is, move in days, same tooling	Relocate (VMware Cloud on AWS [uncertain])	ไม่แปลง hypervisor; Rehost ต้อง convert ทีละ VM ช้ากว่า

3.2 เลือก execution tool

requirement	เครื่องมือ	เหตุผล / trade-off
rehost server ทั้งเครื่อง (OS+app) minimal downtime	AWS MGN	block-level replication + short cutover; decommission source หลังย้าย
DR ต่อเนื่อง failover/failback ซ้ำได้	AWS DRS (บทที่ 08)	ไม่ใช่ migration; ถ้าตอบ MGN ในบริบท DR = ผิด
ย้าย database (near-zero downtime, อาจข้าม engine)	AWS DMS (+SCT) (บทที่ 07)	full load + CDC; heterogeneous ต้องแปลง schema
ย้าย file/object bulk online, bandwidth พอ	AWS DataSync (บทที่ 06)	incremental + validation
ย้าย petabyte, bandwidth จำกัด, offline	AWS Snow Family (บทที่ 06)	คำนวณเวลา online เกิน deadline → offline
interface SFTP ถาวรให้ partner	AWS Transfer Family (บทที่ 06)	ไม่ใช่ bulk one-off tool
relocate VMware ทั้ง cluster เร็ว	VMware Cloud on AWS [uncertain]	ไม่ปรับสถาปัตยกรรม

3.3 เลือกเครื่องมือ discovery/planning

ต้องการ	บริการ	เหตุผล / ตัวตัด
inventory + dependency ระดับ VM บน VMware โดยไม่ลง agent	ADS Agentless (OVA)	least intrusive; agent-based overkill ถ้าแค่ต้องการ VM-level
network/process-level dependency ละเอียด, physical/non-VMware	ADS Agent-based	ต้องลง agent ทุกเครื่อง แต่ได้ dependency ลึก
track สถานะการย้ายหลายเครื่องมือ/หลาย region ที่เดียว	AWS Migration Hub	single pane of glass
business case / TCO justify ต่อ leadership	AWS Migration Evaluator	เน้น cost/licensing; ADS ไม่ทำ TCO
right-size workload ที่อยู่บน AWS แล้ว	Compute Optimizer (บทที่ 10/11)	post-migration — จุดหลอกสลับกับ Evaluator
แนะนำ R ต่อ application	Migration Hub Strategy Recommendations	อัตโนมัติจาก inventory

---

4. สถาปัตยกรรมตัวอย่างและ trade-off

4.1 Large-scale data-center exit: 800 servers เป็น wave (rehost หลัก + replatform DB)

โจทย์: enterprise มี ~800 VMware VM + Oracle/SQL Server databases ใน data center ที่สัญญาเช่าจะหมดใน 12 เดือน ต้องการ migrate the entire data center with minimal application changes และ minimize downtime per application

สถาปัตยกรรม:

1. Assess — deploy ADS Agentless appliance ใน vCenter เก็บ inventory + dependency; ใช้ Migration Evaluator สร้าง TCO business case ให้ leadership อนุมัติ
2. Mobilize — สร้าง landing zone ด้วย Control Tower (multi-account, TGW hub, DX ไป data center, KMS/CloudTrail baseline); ทำ dependency mapping ใน Migration Hub → จัด wave; ทำ pilot ด้วย app dev/test 2 ตัว
3. Migrate — app tier: MGN replicate ต่อเนื่อง, test launch, cutover ทีละ wave; database tier: DMS full load + CDC (Oracle heterogeneous → Aurora PostgreSQL ใช้ SCT; SQL Server homogeneous → RDS SQL Server); ข้อมูล file server ใหญ่บน bandwidth จำกัด → Snowball + DataSync เก็บ delta
4. Cutover — keep source รันจน validate ครบ; Route 53 TTL ต่ำ; rollback = ชี้ DNS กลับ on-prem

trade-off: เลือก Rehost เป็นหลักเพราะ constraint minimal changes + deadline 12 เดือน (Refactor ทั้งหมดไม่ทันและละเมิด constraint). แลกกับการที่ workload ยังไม่ cloud-native (จะ modernize ทีหลังใน wave ถัดไป — ดูบทที่ 13). Replatform เฉพาะ database เพราะได้ประโยชน์ managed สูงและ DMS ทำ near-zero downtime ได้อยู่แล้ว

4.2 Hybrid interim state สำหรับ app ที่พึ่ง AD และ on-prem license server

โจทย์: ย้าย application 3-tier ที่ domain-joined กับ on-prem Active Directory และพึ่ง on-prem license server ที่ยังย้ายไม่ได้ (Retain) โดยต้อง minimize latency ระหว่างช่วง migration

สถาปัตยกรรม:

• จัด app tier + web tier ไว้ wave เดียวกัน (dependency แน่น) และย้ายพร้อมกันด้วย MGN เพื่อไม่ให้ traffic วิ่งข้าม WAN
• license server = Retain → คง on-prem, เชื่อมผ่าน Direct Connect (ต้องการ latency นิ่ง; VPN เป็น backup)
• AD: deploy AWS Managed Microsoft AD + two-way forest trust กับ on-prem AD (ดูบทที่ 03) เพื่อให้ rehosted servers ยัง authenticate ได้ระหว่าง hybrid; หรือใช้ AD Connector ถ้าไม่ต้องการ directory ใน AWS
• วางแผน CIDR ไม่ overlap ผ่าน IPAM (ดูบทที่ 04)

trade-off: การมี hybrid interim state เพิ่มความซับซ้อนและต้นทุน DX ชั่วคราว แต่หลีกเลี่ยง big-bang ที่ต้องย้ายทุกอย่างพร้อม license server (ซึ่งย้ายไม่ได้). two-way trust ให้ความยืดหยุ่นแต่ต้องเปิด port AD ข้าม DX และดูแล trust; ถ้า workload authenticate อย่างเดียวไม่ต้อง object ใน AWS → AD Connector เบากว่า

4.3 Pilot-first migration ลดความเสี่ยงก่อน scale

โจทย์: องค์กรไม่เคยย้าย cloud มาก่อน มี 200 apps ต้องการ prove the migration approach and validate cost before committing to full rollout พร้อม least risk

สถาปัตยกรรม:

• Assess/Mobilize เต็มรูปแบบ: MRA workshop ประเมิน 6-perspective readiness → พบ gap ที่ People/Governance → ตั้ง CCoE + training ก่อน
• เลือก pilot wave = 2–3 app ความเสี่ยงต่ำ (stateless, dependency น้อย) ย้ายด้วย MGN → วัดผลจริงเทียบ Migration Evaluator estimate → ปรับ runbook/landing zone
• ค่อย scale เป็น wave ถัด ๆ ไปเรียง complexity ต่ำ→สูง; mission-critical อยู่ wave ท้าย

trade-off: pilot-first ช้ากว่าการ big-bang แต่ลดความเสี่ยง failure ระดับ portfolio อย่างมาก และให้ข้อมูลจริงปรับ estimate/plan. เหมาะเมื่อ organization maturity ต่ำ (โจทย์บอก first cloud migration) — ถ้าองค์กรชำนาญแล้วและ deadline บีบ อาจ parallelize หลาย wave พร้อมกันได้

---

5. ข้อผิดพลาดที่พบบ่อยในข้อสอบ

1. ตอบ MGN ในบริบท DR (หรือ DRS ในบริบท migration) — MGN = ย้ายครั้งเดียว decommission source; DRS = DR ต่อเนื่อง failover/failback. keyword disaster recovery / RPO seconds / fail back → DRS; migrate / retire data center → MGN (ดูบทที่ 08)
2. เลือก Refactor ทั้งที่โจทย์บอก cannot modify code / tight deadline — constraint ตัด Refactor ออกทันที แม้จะ “ดีกว่า” ทางทฤษฎี → ตอบ Rehost
3. ข้าม discovery/assessment แล้วย้ายเลย — โจทย์ Pro ที่บอก “รีบย้ายทั้งหมด” มักมีคำตอบที่ถูกกว่าคือทำ ADS/dependency mapping ก่อน เพราะ dependency ที่มองไม่เห็นทำ cutover ล้ม
4. สับสน Migration Evaluator (pre-migration TCO/business case) กับ Compute Optimizer (post-migration right-sizing) — Evaluator ตอบ justify to leadership; Optimizer ตอบ workload ที่อยู่บน AWS แล้ว
5. สับสน ADS agentless vs agent-based — VMware + ไม่อยากลง agent + VM-level พอ → agentless (OVA); ต้องการ process/network dependency ลึก หรือ non-VMware/physical → agent-based
6. ย้ายเข้า single account แล้วค่อยจัด governance ทีหลัง — Pro ต้องสร้าง landing zone (Control Tower) ก่อน; blast radius/billing/security แก้ย้อนหลังแพงและเปราะ (ดูบทที่ 02)
7. decommission source ทันทีหลัง cutover — ทำลาย rollback path; ต้อง keep source จน validate ครบ (MGN ไม่ failback อัตโนมัติ)
8. จัด dependent apps คนละ wave — ทำให้ traffic วิ่งข้าม WAN นานในช่วง hybrid = latency สูง/เปราะ; ควรจัด app ที่คุยกันแน่นใน wave เดียวกัน
9. เลือก online transfer ทั้งที่ bandwidth ทำให้ใช้เวลาเกิน deadline — ต้องคำนวณเวลา = data ÷ bandwidth; เกินก็ต้อง Snow (ดูบทที่ 06)
10. ลืม CDC/delta หลัง Snow bulk load — ข้อมูลเปลี่ยนระหว่างขน Snow; ต้อง DataSync/DMS CDC เก็บ delta ก่อน cutover ไม่งั้นข้อมูลไม่ตรง
11. ลืมวางแผน AD/identity ในช่วง hybrid — rehosted domain-joined server จะ authenticate ไม่ได้ถ้าไม่มี trust/AD Connector (ดูบทที่ 03)
12. มองข้าม DNS TTL ตอน cutover — TTL สูงทำให้ traffic ค้างที่ endpoint เดิมนาน; ต้องลด TTL ก่อน cutover (ดูบทที่ 08)
13. ตอบ big-bang เมื่อโจทย์เน้น minimize risk / first migration — ควร pilot + wave-based phased cutover
14. คิดว่า Retire/Retain ไม่ใช่ “กลยุทธ์การย้าย” — เป็น 2 ใน 7 Rs และมักเป็นคำตอบที่ประหยัดสุดเมื่อ app ซ้ำซ้อน/ผูก compliance on-prem

---

6. คำถามทบทวน

ข้อ 1. บริษัทจะปิด data center และย้าย 600 VMs ขึ้น AWS โดย cannot modify the applications และต้องการ minimize downtime per server. หลังย้ายจะ decommission the on-premises servers. ควรใช้บริการใดเป็นหลัก?

เฉลย

AWS Application Migration Service (MGN) — rehost ด้วย continuous block-level replication + short cutover, เหมาะกับ cannot modify (lift-and-shift) และ decommission source หลังย้าย

• AWS DRS ผิด — เป็น DR ต่อเนื่องสำหรับ failover/failback ไม่ใช่ migration ครั้งเดียว (โจทย์บอก decommission source ชัดว่าเป็น migration)
• DMS ผิด — สำหรับ database ไม่ใช่ทั้ง server/OS+app
• สร้าง AMI ด้วยมือทีละเครื่อง ผิด — operational overhead สูง ไม่ scale กับ 600 VMs และ downtime นานกว่า

ข้อ 2. ทีมต้องการ justify the migration to the leadership team ด้วยการเปรียบเทียบต้นทุน on-prem ปัจจุบันกับ projected AWS cost พร้อม licensing scenario. ควรใช้เครื่องมือใด?

เฉลย

AWS Migration Evaluator — สร้าง business case/TCO จาก utilization จริง + right-sized EC2 + licensing (BYOL vs included)

• Application Discovery Service ผิด — เน้น technical inventory/dependency ไม่ทำ TCO/business case
• Compute Optimizer ผิด — right-sizing ของ workload ที่อยู่บน AWS แล้ว (post-migration) ไม่ใช่ pre-migration business case
• Cost Explorer ผิด — วิเคราะห์ cost ที่เกิดบน AWS แล้ว ไม่เทียบ on-prem baseline

ข้อ 3. สภาพแวดล้อมเป็น VMware vCenter องค์กรต้องการเก็บ inventory และ dependency ของ VM ทั้งหมด แบบ least intrusive ไม่อยากลง agent ทุกเครื่อง. ควรใช้อะไร?

เฉลย

Application Discovery Service — Agentless (OVA appliance ใน vCenter) — deploy ตัวเดียวเก็บ VM ทั้งหมด least intrusive

• Discovery Agent (agent-based) ผิด — ต้องลงทุกเครื่อง ขัด least intrusive (เลือกเฉพาะเมื่อต้องการ process/network dependency ลึก)
• Migration Hub เพียงอย่างเดียว ผิด — เป็น tracking hub ไม่ใช่ตัวเก็บ discovery ต้องมี ADS/import feed เข้ามา
• CloudWatch agent ผิด — สำหรับ metric/log ของ resource บน AWS ไม่ใช่ on-prem discovery

ข้อ 4. application เป็น commercial CRM แบบ off-the-shelf ที่มี SaaS เทียบเท่าในตลาด องค์กรอยากลด operational burden และไม่ต้องดูแล server/license เดิม. ควรเลือก R ใด?

เฉลย

Repurchase (“drop and shop”) — เปลี่ยนไปใช้ SaaS ตัดภาระ infra/license เดิม

• Rehost ผิด — ย้าย CRM เดิมขึ้น EC2 ยังต้องจ่าย license + ดูแล server เอง ไม่ลด burden
• Replatform ผิด — ยังต้องดูแล app เดิม
• Refactor ผิด — เขียน CRM ใหม่เองไม่คุ้มเมื่อมี SaaS สำเร็จรูป

ข้อ 5. ต้องย้าย file server data 400 TB ขึ้น S3 แต่ available bandwidth เพียง 200 Mbps และ deadline 2 เดือน. วิธีที่เหมาะสุด?

เฉลย

AWS Snowball Edge (offline) — 400 TB บน 200 Mbps ใช้เวลา online หลายเดือน (เกิน deadline) จึงต้อง offline; ตามด้วย DataSync/CDC เก็บ delta ที่เปลี่ยนระหว่างขน

• DataSync online อย่างเดียว ผิด — bandwidth ทำให้ใช้เวลาเกิน deadline
• Direct Connect ใหม่ ผิด — ติดตั้ง DX ใช้เวลาเป็นสัปดาห์-เดือน ไม่ทันและ overkill สำหรับ one-time bulk
• Transfer Family ผิด — เป็น SFTP endpoint ถาวร ไม่ใช่ bulk migration tool

ข้อ 6. องค์กรกำลังจะทำ first-ever cloud migration ของ 300 applications ต้องการ validate the approach and reduce risk ก่อน commit เต็ม. แนวทางที่ถูกต้อง?

เฉลย

Pilot migration + wave-based rollout — เลือก app ความเสี่ยงต่ำ 2–3 ตัวย้ายก่อน (pilot/wave 0) validate landing zone/runbook/cost แล้วค่อย scale เป็น wave เรียง complexity ต่ำ→สูง

• Big-bang migration ผิด — เสี่ยงสูงสุดสำหรับองค์กรที่ไม่เคยย้าย ขัด reduce risk
• Refactor ทุก app ก่อนย้าย ผิด — effort มหาศาล ช้า ไม่ตอบ validate approach
• ย้ายทั้ง 300 พร้อมกันด้วย MGN ผิด — ไม่ validate ก่อน = เสี่ยงล้มระดับ portfolio

ข้อ 7. ระหว่าง migration แบบ hybrid มี rehosted server ที่ domain-joined กับ on-prem Active Directory ต้อง authenticate ได้ต่อเนื่อง และมี license server ที่ยัง cannot be migrated yet. ควรออกแบบอย่างไร?

เฉลย

• license server = Retain บน on-prem เชื่อมผ่าน Direct Connect (latency นิ่งระหว่าง hybrid)
• AD = AWS Managed Microsoft AD + two-way forest trust (หรือ AD Connector) เพื่อให้ rehosted server authenticate ได้ (ดูบทที่ 03)

ทำไมตัวเลือกอื่นผิด:

• บังคับย้าย license server ทันที ผิด — โจทย์บอก cannot migrate yet
• ตั้ง AD ใหม่แยกไม่ trust ผิด — server จะ authenticate ข้าม domain ไม่ได้
• ใช้ public internet แทน DX ผิด — latency/security ไม่เหมาะ workload ที่พึ่งกันแน่น

ข้อ 8. สถาปนิกวางแผน cutover ของ application สำคัญ ต้องการ minimize downtime และมี safe rollback. ข้อใดคือแนวปฏิบัติที่ถูกต้อง? (เลือกสองข้อ)

เฉลย

(A) ให้ MGN/DMS replicate ต่อเนื่องจน delta น้อย แล้ว cutover เฉพาะช่วง finalize (ลด cutover window) และ (B) คง source on-prem ไว้ (ไม่ decommission) จน validate บน AWS ครบ เพื่อ rollback ได้ด้วยการชี้ DNS กลับ

• decommission source ทันทีหลัง cutover ผิด — ทำลาย rollback path (MGN ไม่ failback อัตโนมัติ)
• ตั้ง DNS TTL สูงก่อน cutover ผิด — traffic จะค้างที่ endpoint เดิมนาน; ต้องตั้ง TTL ต่ำ (ดูบทที่ 08)
• หยุด write ที่ source เป็นชั่วโมงเพื่อ full copy ผิด — downtime นานเกินจำเป็นเมื่อมี CDC/continuous replication อยู่แล้ว

ข้อ 9. องค์กรมี datacenter บน VMware vSphere ล้วน ต้องออกจากอาคารภายในไม่กี่สัปดาห์ ต้องการย้าย as-is without changing the hypervisor or re-architecting, ใช้ tooling VMware เดิม. แนวทางใดเหมาะ?

เฉลย

Relocate → VMware Cloud on AWS — ยก vSphere workload ขึ้น bare-metal AWS ด้วย HCX/vMotion โดยไม่แปลง hypervisor/OS ย้ายได้เร็ว [uncertain: ตรวจสถานะบริการล่าสุดหลัง Broadcom]

• Rehost ทีละ VM ด้วย MGN ผิด (ในบริบทนี้) — ต้อง convert แต่ละเครื่องเป็น EC2 ช้ากว่าและเปลี่ยน operating model; โจทย์เน้น as-is + same tooling + few weeks
• Refactor ผิด — ขัด without re-architecting และช้าเกินไป
• Retain ผิด — ต้องออกจากอาคาร จึงคงที่เดิมไม่ได้

---

7. Cross-references

• บทที่ 01 — 7 Rs และ constraint lift-and-shift/cannot modify code ถอดจาก keyword; mindset Assess-before-migrate สะท้อน Pro thinking (บทนี้ครอบคลุมการ map keyword → R เต็มในส่วน 2.3/3.1)
• บทที่ 02 — landing zone/Control Tower/OU/SCP ที่ต้องพร้อมก่อน migrate (readiness ใน 2.9)
• บทที่ 03 — identity/AD ในช่วง hybrid migration: Managed Microsoft AD + two-way trust, AD Connector สำหรับ rehosted domain-joined servers (2.8, สถาปัตยกรรม 4.2)
• บทที่ 04 — network cutover, DX/VPN hybrid connectivity, CIDR overlap, Route 53 DNS cutover (2.8, 2.10)
• บทที่ 06 — DataSync/Transfer Family/Snow ในบริบท migration wave และ online vs offline decision (2.5, 2.7); รายละเอียด transfer service internals อยู่บทที่ 06
• บทที่ 07 — DMS full load + CDC, SCT, homogeneous vs heterogeneous ในเฟส Migrate database tier (2.5, สถาปัตยกรรม 4.1)
• บทที่ 08 — MGN vs DRS แยกให้ขาด (บทนี้ชี้ความต่าง migration vs DR); DNS TTL failover primitive
• บทที่ 09 — security baseline (KMS/CloudTrail org trail/GuardDuty) ใน landing zone readiness (2.9)
• บทที่ 11 — CloudWatch/SSM สำหรับ operate fleet หลัง migrate; Compute Optimizer เป็น post-migration right-sizing (แยกจาก Migration Evaluator)
• ฝากไปบทที่ 13 — modernization pattern เชิงลึก (strangler fig ผ่าน Migration Hub Refactor Spaces, decomposition เป็น microservices, App2Container path, serverless refactoring); บทนี้แตะ Refactor เพียงในฐานะ 1 ใน 7 Rs และแนะนำ Refactor Spaces เชิงแนวคิด
• ฝากไปบทที่ 14 — decision framework สังเคราะห์: เลือก R, เลือก migration tool (MGN/DMS/DataSync/Snow), wave planning เป็นส่วนหนึ่งของ cross-domain scenario