Cloud Migration Strategies (7 Rs)

ปัญหา

data centre หนึ่งแห่งแทบไม่เคยมีแอปพลิเคชันแค่ตัวเดียว มันมีเป็นร้อย: product สำเร็จรูป, โค้ดที่เขียนเองสะสมมายี่สิบปี, database, file share, VMware estate และอาจมี mainframe อีกตัว แล้ววันหนึ่งก็มาถึง (สัญญาเช่าตึกหมด hardware ถึงรอบต้องเปลี่ยน หรือสัญญา support หมดอายุ) และทั้งหมดนี้ก็ต้องย้ายไปไหนสักที่

การจัดการทั้ง estate ด้วยวิธีเดียวกันพังได้ทั้งสองทาง ถ้า lift and shift ทุกอย่าง ความไม่มีประสิทธิภาพทั้งหมดก็ตามขึ้นไปบน cloud ทั้งหมด แล้ว server ที่ใหญ่เกินจำเป็นแต่จ่ายเงินไปแล้วก็กลายเป็นบิลรายเดือน ส่วนถ้าเขียนใหม่ทุกอย่าง ก็ต้องดึงวิศวกรเก่ง ๆ ไว้เป็นปี ๆ แล้วยังเพิ่มความเสี่ยงให้ระบบที่ไม่เคยต้องเปลี่ยนเลย คำถามที่มีประโยชน์ต้องถามทีละ workload: ทางย้ายที่ถูกที่สุดที่ยังทำให้ workload นี้ได้ตามเป้าหมายทางธุรกิจคืออะไร "Rs" ให้ทุกคนมีรายการคำตอบสั้น ๆ ชุดเดียวกัน แล้ว portfolio assessment ก็ให้ข้อเท็จจริงไว้ใช้เลือก

ทำงานยัง⁠ไง

การย้ายระบบเริ่มจากการตัดสินใจระดับ portfolio ก่อน แล้วค่อยตามด้วยการย้ายทีละขั้น ตามสี่ขั้นใน diagram

1. ประเมิน ทุก workload แล้วจดการตัดสินใจหนึ่งอย่างของแต่ละตัวลงในตาราง portfolio
2. ทำการตัดสินใจที่ไม่ต้องลงแรงมากก่อน: ปิดสิ่งที่ไม่มีใครต้องการ เก็บไว้ที่เดิมสำหรับสิ่งที่ยังไม่ควรย้าย ย้ายทั้ง platform ไปตามเดิม และเปลี่ยน software ทั่วไปไปใช้ SaaS
3. Rehost workload ที่แค่ต้องออกจาก data centre และ replatform ตัวที่ managed service ช่วยลดงาน operation ได้จริง
4. Refactor เฉพาะที่ architecture ใหม่คุ้มทุนในตัวเอง ส่วนใหญ่คือระบบที่ทำให้ธุรกิจโดดเด่นกว่าคนอื่น

R มาจากไหน

• Gartner ปี 2011: ห้า R Richard Watson ผู้อำนวยการฝ่ายวิจัยของ Gartner อธิบายห้าวิธีย้ายแอปพลิเคชันขึ้น cloud: rehost บน infrastructure as a service, refactor ให้เข้ากับ platform as a service, revise โค้ดก่อนแล้วค่อย rehost หรือ refactor, rebuild บน PaaS หรือ replace ด้วย software as a service ตัว refactor ของ Gartner หมายถึงการรันโค้ดเดิมบน PaaS โดยแก้นิดหน่อย แบบนี้ใกล้กับสิ่งที่ตอนนี้เรียกว่า replatform มากกว่า
• AWS ปี 2016: หก R ใน 6 Strategies for Migrating Applications to the Cloud (1 พฤศจิกายน 2016) Stephen Orban จาก AWS ต่อยอดจากรายการของ Gartner: rehost (lift and shift), replatform (lift, tinker and shift), repurchase (ย้ายไปใช้ product ตัวอื่น), refactor หรือ re-architect, retire และ retain เขาบอกว่าในการย้ายระบบ legacy ขนาดใหญ่ แอปพลิเคชันส่วนใหญ่ถูก rehost และแอปพลิเคชันจะ optimise ได้ง่ายขึ้นเมื่อมันรันอยู่บน cloud แล้ว
• AWS ช่วงหลัง: เจ็ด R จากนั้น AWS ก็เพิ่ม relocate สำหรับการย้ายทั้ง platform (ปกติคือ VMware estate) ไปยังเวอร์ชัน cloud ของ platform เดียวกัน ตอนนี้ AWS Prescriptive Guidance มีเจ็ดตัว: retire, retain, rehost, relocate, repurchase, replatform และ refactor (หรือ re-architect) ส่วน diagram ก็ใช้ชื่อชุดนี้

เจ็ด R

ประเมิน portfolio

ขั้นที่ 1 ของ diagram กลายเป็นเฟสที่ยาวที่สุดของการย้ายระบบจริง เป้าหมายคือตารางที่มีหนึ่งแถวต่อหนึ่ง workload และมีข้อเท็จจริงมากพอจะอธิบายการตัดสินใจแต่ละข้อได้

• ค้นหาว่ามีอะไรอยู่บ้าง เก็บ inventory แบบอัตโนมัติ (server, utilisation ของมัน, software ที่ติดตั้ง, database) แล้วเพิ่มสิ่งที่ไม่มีเครื่องมือไหนเห็น: เจ้าของ, user, กระบวนการธุรกิจที่มันรองรับ, สัญญาและ licence ที่ผูกอยู่ เครื่องมือตอนนี้มี AWS Transform เป็น agentic AI service ที่เปิดตัวเมื่อพฤษภาคม 2025 และตอนนี้ AWS ชี้ให้ใช้สำหรับ discovery และ assessment (AWS Application Discovery Service กับ AWS Migration Hub เลิกรับลูกค้าใหม่ตั้งแต่ 7 พฤศจิกายน 2025), Azure Migrate ที่มี appliance หรือ collector แบบใช้ครั้งเดียว มี assessment และ business case และ Migration Center ของ Google Cloud ที่มี discovery และการประมาณค่าใช้จ่าย
• ทำแผนที่ dependency หาว่า server ไหนคุยกับตัวไหน, database กับ file share ไหนใช้ร่วมกัน และ batch job ไหนรันตอนกลางคืน ยกตัวอย่าง dependency analysis ของ Azure Migrate จะจับกลุ่ม server ที่คุยกันเป็นแอปพลิเคชัน และแสดงว่าตัวไหนต้องย้ายไปด้วยกัน
• ทำ business case เทียบว่าตอนนี้แต่ละ workload เสียเงินเท่าไร (hardware, licence, ไฟ, พื้นที่, support, คน) กับถ้าอยู่บน cloud ภายใต้ R แต่ละตัวที่เป็นตัวเลือกจะเสียเท่าไร รวมค่าย้ายแบบจ่ายครั้งเดียวไว้ด้วย ส่วน Azure Migrate, AWS Transform และ Migration Center ทั้งสามตัวก็ประมาณ total cost of ownership ออกมาให้ได้ ให้ถือเป็นจุดเริ่มต้นแล้วเช็กสมมติฐานอีกที
• ให้คะแนนคุณค่าและความพร้อม workload สำคัญกับธุรกิจแค่ไหน และพร้อมขึ้น cloud แค่ไหน สองข้อนี้ตัดสินการเลือกเป็นส่วนใหญ่ คุณค่าสูงแต่ความพร้อมต่ำชี้ไปทาง replatform หรือ refactor แบบรอบคอบ ส่วนคุณค่าต่ำชี้ไปทาง retire หรือ repurchase
• วางแผน migration wave จับ workload เป็น wave ละไม่กี่สัปดาห์ และใส่ workload ที่พึ่งพากันไว้ใน wave เดียวกัน แอปพลิเคชันที่คุยถี่ ๆ จะได้ไม่ต้องคุยกับ database ของมันข้าม VPN อยู่หลายเดือน เริ่มจาก workload ที่ง่ายและเสี่ยงต่ำ ให้ทีมคล่องมือก่อนเจอตัวยาก Orban ก็แนะนำแบบเดียวกัน ยกตัวอย่าง AWS Transform MGN จะจับ server เป็นแอปพลิเคชัน และจับแอปพลิเคชันเป็น wave ทำให้ launch และ cutover ทำทีละ wave

workload เดียว ใช้ได้มากกว่าหนึ่ง R ตามเวลา

R คือการตัดสินใจสำหรับการย้ายครั้งนี้ ไม่ใช่ป้ายติดตัวไปตลอด AWS แนะนำให้ rehost, relocate หรือ replatform ระหว่างการย้ายขนาดใหญ่ แล้วค่อย modernise ทีหลัง เพราะการ refactor แอปพลิเคชันจำนวนมากกลางการย้ายระบบจัดการยาก การ rehost มักเป็นก้าวแรกของเส้นทางที่ยาวกว่า: lift and shift ตอนนี้ให้ทันเส้นตาย replatform database อีกไม่กี่เดือนต่อมา แล้วค่อย refactor ส่วนที่กลายเป็นเรื่องสำคัญ workload ที่ retain ไว้จะกลับมาให้ทบทวน และ product ที่ repurchase มา วันหนึ่งก็อาจถูกเปลี่ยนเหมือนกัน คำแนะนำฝั่งตรงข้ามก็จริงด้วย: Cloud Adoption Framework ของ Microsoft บอกให้ rehost แค่ workload ที่มั่นใจว่าจะไม่ต้อง modernise ไปอีกราวสองปี จะได้ไม่ต้องจ่ายค่าย้ายระบบเดียวกันสองรอบ

ชื่ออื่นของแนวคิดเดียวกัน

รายการของแต่ละ provider ไม่เหมือนกัน (เช็กเมื่อตุลาคม 2026) เลยต้องเทียบที่ความหมาย ไม่ใช่ที่ชื่อ

• Microsoft Cloud Adoption Framework มีแปดกลยุทธ์: retire, rehost, replatform, refactor, rearchitect, replace, rebuild และ retain มันแยก refactor ของ AWS ออกเป็นสอง: refactor เปลี่ยนโค้ด (เพื่อลด technical debt หรือใช้ Azure SDK) ส่วน rearchitect เปลี่ยน architecture (เช่น แยก monolith) Replace คือ repurchase ของ AWS และ rebuild หมายถึงพัฒนา workload ใหม่ตั้งแต่ศูนย์เป็น cloud-native solution มันไม่มี relocate แยกต่างหาก
• Google Cloud ใน Migrate to Google Cloud: Get started มีการย้ายหกแบบ: rehost (lift and shift), replatform (lift and optimize), refactor (move and improve), re-architect (continue to modernize), rebuild (remove and replace หรือเรียกว่า rip and replace) และ repurchase ในรายการนี้ไม่มี retire กับ retain คู่มือนี้ครอบทั้งหมดไว้ในสี่เฟส: assess, plan, deploy และ optimize
• คำเดียวกันหมายถึงได้สามอย่าง refactor ของ Gartner คือการย้ายไป PaaS ส่วน refactor ของ AWS คือการ re-architect และ refactor ของ Microsoft คือการแก้โค้ดโดยคง architecture ไว้

ใช้ตอนไหนดี

• การย้ายระบบที่มี workload มากกว่าไม่กี่ตัว: ออกจาก data centre หมดสัญญา co-location หรือ outsourcing เปลี่ยน hardware ตามรอบ ควบรวมกิจการ หรือย้ายจาก cloud หนึ่งไปอีก cloud หนึ่ง (ยกตัวอย่าง Cloud Adoption Framework นับการย้าย AWS EC2 instance ไปเป็น Azure virtual machine ว่าเป็น rehost)
• หลังย้ายเสร็จ ใช้เป็นการทบทวน portfolio เป็นประจำ: workload ที่ retain หรือ rehost ไว้ควรได้กลับมาดูอีกรอบ เมื่อ landing zone และทักษะของทีมโตขึ้นแล้ว
• ตอนที่ไม่ควรย้าย workload นั้นเลย การเก็บไว้ที่เดิมหรือปิดทิ้งถือเป็นผลลัพธ์ที่ถูกต้อง ไม่ใช่ความล้มเหลวของโครงการ
  • อีกไม่นานมันก็จะถูก retire หรือเปลี่ยนอยู่แล้ว ถ้าย้ายก่อนก็แค่เสียเงินสองรอบ
  • กฎระเบียบหรือกฎ data residency ทำตามไม่ได้ใน region ที่มีให้ใช้
  • มันพึ่ง hardware ที่ไม่มีของเทียบเท่าบน cloud หรือต้องอยู่ติดกับอุปกรณ์ในพื้นที่ เช่น เครื่องจักรในโรงงาน
  • hardware ที่มันรันอยู่เพิ่งเปลี่ยนใหม่ และยังใช้ได้อีกหลายปี
  • การย้ายจะแพงกว่าที่ประหยัดได้ในช่วงเวลาที่วางแผนไว้ และ workload ก็นิ่งและตอบโจทย์ธุรกิจอยู่แล้ว
  • มันเป็น mainframe หรือระบบ mid-range ที่ยังไม่มีแผนย้ายของตัวเอง การย้ายระบบพวกนี้เป็นโปรเจกต์ในตัวมันเอง

ได้อะไร เสียอะไร

• ความเร็วแลกกับประโยชน์ Relocate กับ rehost ทันเส้นตายเร็วที่สุดและเปลี่ยนน้อยที่สุด เลยให้ประโยชน์น้อยที่สุดนอกจากการได้ออกจาก data centre ส่วน refactor ให้ประโยชน์มากที่สุดแต่ช้าและเสี่ยงที่สุด แล้ว replatform กับ repurchase ก็อยู่ตรงกลาง และ portfolio ส่วนใหญ่ก็ใช้ครบทุกตัว
• Rehost ทุกอย่างแล้วจ่ายแพงขึ้น server ที่ตั้งขนาดไว้รับ peak เมื่อห้าปีก่อน ก็อปมาแบบหนึ่งต่อหนึ่ง แล้วเปิดทิ้งไว้ตลอดวันตลอดคืนด้วยราคา on-demand อาจแพงบน cloud กว่าตอนอยู่ใน data centre ให้ right-size จากข้อมูล utilisation ปิด environment ที่ไม่ใช่ production ตอนไม่มีใครใช้ commit กับ capacity ที่ใช้คงที่ และวางแผน replatform ที่ rehost เลื่อนออกไป
• Refactor มากเกินไปพร้อมกัน การ re-architect แอปพลิเคชันเป็นสิบ ๆ ตัวระหว่างย้ายระบบ ทำให้โปรเจกต์ที่มีเส้นตายกลายเป็นการเขียนใหม่ที่ไม่มีวันจบ AWS แนะนำว่าไม่ควร refactor เป็นส่วนหนึ่งของการย้ายขนาดใหญ่ และให้เลือกมันก็ต่อเมื่อไม่มีกลยุทธ์อื่นที่รับได้ เก็บมันไว้ใช้กับไม่กี่ระบบที่เห็นประโยชน์ทางธุรกิจชัด แล้วค่อย ๆ เปลี่ยนทีละส่วน
• มองข้ามเรื่อง licence licence ตัดสิน business case ได้ด้วยตัวเอง: บางตัวย้ายไป cloud host ที่ใช้ร่วมกันไม่ได้ บางตัวคิดราคาต่อ core ในแบบที่เปลี่ยนไปตาม instance type และบางตัวก็รวมสิทธิ์ให้รันที่อื่นได้ เช็กทุก operating system, database, middleware และ product สำเร็จรูปก่อนเลือก R การ relocate VMware คือตัวอย่างล่าสุด (ดูข้างล่าง)
• มองข้าม dependency ย้ายแอปพลิเคชันไปโดยไม่ย้าย database ของมัน หรือย้าย database ไปโดยไม่ย้าย report ที่อ่านมันทุกคืน ทำให้เกิด latency, job พัง และต้องแก้ firewall แบบฉุกเฉิน IP address ที่ hard-code ไว้, file system ที่ใช้ร่วมกัน และ licence server คือของที่มักโผล่มาให้ตกใจ
• Retain มีค่ารันต่อเนื่อง workload ทุกตัวที่ retain ไว้ทำให้ data centre บางส่วนต้องเปิดต่อ บวกกับ network link และ operating model ชุดที่สองที่ estate แบบ hybrid ต้องมี กำหนดวันทบทวนให้ทุกตัว

ข้อควรรู้ตอนลงมือทำ

• สร้าง landing zone ก่อน ก่อน wave แรก ให้เตรียมปลายทางไว้: โครงสร้าง account หรือ subscription, networking และ connectivity กลับไปที่ data centre, identity, security guardrail, logging และรายงานค่าใช้จ่าย ตัวอย่างเช่น landing zone ที่ตั้งด้วย AWS Control Tower, Azure landing zone และแนวทาง landing zone design ของ Google Cloud หลังจากนั้นทุก wave ก็จะลงไปในที่ที่มี governance อยู่แล้ว
• ย้ายข้อมูลขณะที่ระบบยังรันอยู่ database ขนาดใหญ่หยุดรอการก็อปที่ใช้เวลาหลายวันไม่ได้ database migration service จะก็อปข้อมูลที่มีอยู่ก่อน แล้วคอย stream การเปลี่ยนแปลงต่อไปจนถึง cutover: AWS DMS (ย้ายครั้งเดียวหรือ replicate ต่อเนื่อง), Azure Database Migration Service (ย้ายแบบ online ไปที่ Azure SQL Managed Instance หรือ SQL Server บน Azure virtual machine) และ Database Migration Service ของ Google Cloud (ย้ายต่อเนื่องหลัง dump และ load รอบแรก) นี่คือ change data capture ที่เอามาใช้กับการย้ายระบบ ส่วนการย้ายทั้ง server ตัว AWS Transform MGN จะ replicate disk ต่อเนื่องในระดับ block ทำให้ช่วง cutover ปกติใช้แค่ไม่กี่นาที
• Cutover อย่างปลอดภัย launch และทดสอบสำเนาที่ย้ายไปแล้วก่อน cutover ด้วยข้อมูลจริงและ dependency จริงของมัน ถ้าเป็นระบบที่ตอบผิดแล้วเสียหายแพง ให้รันของเก่ากับของใหม่คู่กันด้วย input เดียวกัน แล้วเทียบผลด้วย parallel run ส่วนตอนสลับ traffic ก็ให้สลับแบบที่สลับกลับได้: เก็บ environment เก่าไว้ครบ ๆ จะเป็นแบบ read-only ก็ได้ถ้าจำเป็น จนกว่าตัวใหม่จะพิสูจน์ตัวเองได้ แบบเดียวกับ blue-green deployment แล้วก็เขียนเกณฑ์ rollback ไว้ก่อนถึงช่วง cutover ไม่ใช่ระหว่างนั้น
• ป้องกันของใหม่จากของเก่า การย้ายระบบใช้เวลาเป็นปี ทำให้ cloud-native service ใหม่ต้องคุยกับระบบ legacy ที่ยังอยู่ on premises เช่น mainframe ที่ retain ไว้ใน diagram ให้วาง anti-corruption layer ไว้ระหว่างกัน data model ของ legacy จะได้ไม่รั่วเข้ามาใน design ใหม่ ถ้าจะ refactor ระบบใหญ่โดยไม่เขียนใหม่ทีเดียวทั้งก้อน ให้ route traffic ของมันผ่าน facade แล้วเปลี่ยนทีละความสามารถ แบบ pattern strangler fig
• Relocate VMware ในปี 2026 ตั้งแต่ Broadcom ซื้อ VMware ไป VMware service บน cloud ก็เปลี่ยนไปในแบบที่กระทบ business case:
  • AWS เลิกขายต่อ VMware Cloud on AWS ตั้งแต่ 30 เมษายน 2024 ตอนนี้ Broadcom กับ reseller ของมันเป็นคนขาย ส่วน service ของ AWS เอง Amazon Elastic VMware Service เปิดให้ใช้ทั่วไปตั้งแต่ 5 สิงหาคม 2025 มันรัน VMware Cloud Foundation (VCF) ใน VPC ของเราเอง และเราต้องเอา VCF subscription ที่ย้าย licence ได้มาเอง ส่วน licence vSphere แบบ perpetual ใช้ไม่ได้
  • เมื่อพฤศจิกายน 2025 Broadcom ให้ hyperscaler ทุกเจ้าเปลี่ยนเป็นแบบ bring-your-own VCF subscription ตัว Azure VMware Solution ยังให้บริการต่อโดยใช้ VCF ที่ลูกค้าเอามาเอง: SKU แบบ licence-included pay-as-you-go จะ retire วันที่ 31 ตุลาคม 2026 และ reserved instance แบบ licence-included จะ retire วันที่ 30 สิงหาคม 2027 ส่วน Google Cloud VMware Engine เลิกขาย node แบบ licence-included หลัง 15 ตุลาคม 2025 และ node ของมันต้องใช้ VCF subscription แบบย้ายได้ตั้งแต่ 1 พฤศจิกายน 2025
  • ตอนนี้ relocate เลยหมายถึงบิลสองใบ: ค่า node บน cloud และ VCF subscription จาก Broadcom ให้เทียบกับการ rehost virtual machine ชุดเดียวกันไปบน compute ของ cloud โดยตรง งานนี้เครื่องมืออย่าง AWS Transform for VMware, Azure Migrate และ Migrate to Virtual Machines ทำให้อัตโนมัติได้ Relocate ก็ยังเป็นก้าวแรกที่ถูกต้องได้ สำหรับ estate ขนาดใหญ่ที่มีเส้นตายตายตัว
• รู้ชื่อเครื่องมือปัจจุบัน AWS Application Migration Service เปลี่ยนชื่อเป็น AWS Transform MGN เมื่อ 8 มิถุนายน 2026 ให้ตรงกับบทบาทที่เป็น replication engine อยู่เบื้องหลัง AWS Transform มันสั่งงานได้ทั้งจาก console ของตัวเอง และจาก workflow แบบ agentic ของ AWS Transform ส่วน Azure Migrate ตอนนี้มี migration agent ของ Azure Copilot (ยังเป็น preview) ไว้ช่วยวางแผน ชื่อ product ในเรื่องนี้เปลี่ยนบ่อย เลยต้องเช็กอีกทีตอนวางแผน
• ปิด wave ให้จบ decommission server ต้นทางเมื่อ workload ย้ายไปแล้ว ไม่งั้นก็ต้องจ่ายสองรอบ เทียบค่าใช้จ่ายจริงกับ business case แล้วจดวันทบทวนให้ทุก workload ที่ retain ไว้หรือแค่ rehost