What to record before migrating a production workload
ก่อนย้าย production ต้องมี baseline, dependency, owner, recovery target และ rollback criteria
Migration starts before tooling
เครื่องมือ discovery ช่วยสร้าง inventory และเก็บ utilization ได้ แต่ migration decision ยังต้องใช้ข้อมูลจากเจ้าของระบบ ผู้ใช้งาน security และ operations รายการ virtual machine เพียงอย่างเดียวไม่อธิบายว่า service สำคัญอย่างไร หยุดได้นานเท่าใด หรือ dependency ใดอยู่นอกขอบเขตที่สแกนพบ
ก่อนวาง migration wave ควรสร้าง workload record ที่เป็นแหล่งข้อมูลร่วม และระบุส่วนที่ยังไม่ทราบอย่างตรงไปตรงมา Unknown dependency เป็นความเสี่ยงที่ต้องติดตาม ไม่ใช่ช่องว่างที่ควรถูกเติมด้วยสมมติฐาน
Business record
- Service owner, technical owner และทีม support หลัง cutover
- Business criticality, user group และช่วงเวลาที่ระบบมีภาระสูง
- Allowed downtime, RTO, RPO และ data-loss tolerance
- Compliance, data residency, retention และ licensing constraint
- เหตุผลที่ย้ายและผลลัพธ์ที่ใช้ตัดสินว่าการย้ายสำเร็จ
ข้อมูลนี้กำหนดว่า workload ควร rehost, replatform, refactor, retain หรือ retire และช่วยป้องกันการเลือกวิธีจากความง่ายของเครื่องมือเพียงด้านเดียว
Technical baseline
ควรบันทึก architecture ปัจจุบัน ระบบปฏิบัติการ runtime database storage network flow identity model certificate backup schedule และ monitoring ที่ใช้งานอยู่ Metrics ควรครอบคลุมช่วงเวลาปกติและ peak เพื่อไม่ให้ sizing จากค่าเฉลี่ยที่สั้นเกินไป
ข้อมูล configuration ที่เป็น secret ไม่ควรอยู่ใน migration worksheet โดยตรง ให้บันทึกตำแหน่งจัดเก็บ เจ้าของ และวิธี rotate แทน ส่วน unsupported component หรือ version ที่หมดการสนับสนุนควรถูกแยกเป็น remediation decision ไม่ใช่ย้ายปัญหาเดิมไปยัง cloud
Dependencies and cutover
Dependency mapping ต้องรวมทั้ง connection ที่เครื่องมือพบและ business sequence ที่เจ้าของระบบทราบ เช่น batch job, file exchange, scheduled task, third-party endpoint, DNS, firewall allowlist และ manual operation ทุก dependency ควรมีวิธีทดสอบหลังย้าย
Cutover plan ควรระบุ entry criteria, freeze period, data synchronization, validation owner, communication path และ rollback trigger ที่วัดได้ การเขียนเพียงว่า “rollback หากมีปัญหา” ไม่เพียงพอ เพราะเมื่อเกิดเหตุ ทีมอาจตีความความรุนแรงไม่เหมือนกัน
Operational steps
- เปิด workload record และยืนยัน business owner, technical owner, criticality, RTO และ RPO
- เก็บ inventory, utilization baseline, dependency และข้อจำกัดที่เครื่องมือ discovery มองไม่เห็น
- เลือก migration strategy และออกแบบ target architecture ให้ผ่าน landing zone กับ workload requirement
- ทดสอบ deployment, data synchronization, access, monitoring, backup restore และ application validation
- ซ้อม cutover พร้อมเวลาที่ใช้จริง กำหนด rollback trigger และผู้มีอำนาจตัดสินใจ
- ย้าย production traffic แล้วเฝ้าระวังตาม acceptance period ก่อนปิดระบบต้นทาง
Operational acceptance
ก่อนรับ traffic จริง ต้องยืนยัน monitoring, alert routing, backup restore, access, patching, cost ownership และ escalation path ใน environment ปลายทาง Runbook ควรถูกทดสอบกับทีมที่จะใช้งาน ไม่ใช่เพียงส่งไฟล์ตอน handover
ระบบต้นทางควรถูกเก็บไว้ตาม rollback และ retention plan จน validation เสร็จ การปิดหรือยกเลิก resource เดิมเร็วเกินไปทำให้ recovery option หายไปและอาจทำลายหลักฐานที่ยังต้องใช้
Migration record ที่ดีไม่ได้ทำให้ไม่มีความเสี่ยง แต่ทำให้ทีมรู้ว่าความเสี่ยงอยู่ตรงไหนและใครเป็นผู้ตัดสินใจ