Zero Downtime ERP Migration — เมื่อต้องย้ายระบบ ERP ที่ใช้มา 8 ปี โดยห้ามปิดระบบแม้แต่วินาทีเดียว
"ระบบเก่ามันเหมือนระเบิดเวลา — ทุกวันที่ยังไม่ย้าย คือวันที่เรากำลังเสี่ยงกับธุรกิจ แต่ทุกวันที่ย้ายผิดพลาด คือวันที่ธุรกิจหยุดเดิน"
นี่คือประโยคแรกที่ CTO ของลูกค้าพูดกับเราในวันที่เริ่ม Kick-off Meeting
ถ้าคุณเคยอยู่ในสถานการณ์ที่ต้อง migrate ระบบ ERP ที่ "ใช้งานจริงอยู่ทุกวัน" — ระบบที่มีคน 350 คนใช้ 24/7 มี transaction วิ่งอยู่ 15,000 รายการต่อวัน แล้วบอกว่า "ห้ามปิดระบบแม้แต่วินาทีเดียว" คุณจะรู้ว่ามันไม่ใช่แค่ technical challenge แต่มันคือ เกมที่ผิดพลาดไม่ได้
นี่คือเรื่องจริงที่เกิดขึ้นในปี 2025
ปัญหา: ระบบที่กำลังจะล่ม แต่ห้ามปิด
ลูกค้าเป็นโรงงานผลิตขนาดกลาง-ใหญ่ ใช้ระบบ ERP มา 8 ปี — ซึ่งถ้าพูดแบบตรงๆ คือ ระบบนี้ "รอดมาจนถึงวันนี้ได้ก็ปาฏิหาริย์แล้ว"
สถานการณ์ที่เจอ
- Response time เฉลี่ย 4.2 วินาที — ทุก click ที่พนักงานกดในระบบ ต้องนั่งรอ 4 วิ ลองคิดดูว่าวันนึง 15,000 transactions คนนั่งรอเท่าไหร่
- Monthly downtime เฉลี่ย 12 ชั่วโมง จาก bugs ที่ "แก้แล้วกลับมาอีก" — ซึ่งในโรงงานผลิตที่ทำงาน 3 กะ 24 ชม. downtime 12 ชม./เดือน แปลว่าเสียรายได้หลักล้าน
- Customizations สะสม 200+ จุด ที่ทำกันมา 8 ปี — ไม่มี documentation ครบ บาง customization คนที่เขียนก็ลาออกไปแล้ว
- ค่า maintenance ปีละ 3.5 ล้านบาท — และยังเพิ่มขึ้นทุกปี เพราะหาคนที่ดูแลระบบเก่าได้ยากขึ้นเรื่อยๆ
- เคยลอง upgrade มาแล้ว 2 ครั้ง ในช่วง 3 ปีที่ผ่านมา — ทั้ง 2 ครั้งล้มเหลวเพราะ compatibility issues กับ customizations ที่สะสมมา
สิ่งที่ทำให้โปรเจกต์นี้ยากเป็นพิเศษ: โรงงานทำงาน 24/7 มีพนักงาน 350 คน ที่ใช้ระบบตลอดเวลา ตั้งแต่ฝ่ายผลิต คลังสินค้า จัดซื้อ จนถึงบัญชี — ไม่มีช่วง "ปิดปรับปรุง" ได้เลย
โจทย์: สิ่งที่ลูกค้าต้องการ
| เป้าหมาย |
รายละเอียด |
ระดับความยาก |
| Zero Downtime |
ห้ามปิดระบบแม้แต่วินาทีเดียวระหว่าง migration |
สูงมาก |
| Data Integrity 100% |
ข้อมูล 8 ปี 12 ล้าน records ต้องครบถ้วนไม่ขาดแม้ record เดียว |
สูงมาก |
| 350 Users ใช้งานได้ตลอด |
ไม่มีการหยุดงาน ไม่มีการ "ขอเวลาสักครู่" |
สูง |
| ย้าย 200+ Customizations |
ต้องประเมินว่าอันไหนยังจำเป็น อันไหนตัดทิ้งได้ |
ปานกลาง-สูง |
| ลด Maintenance Cost |
จากปีละ 3.5 ล้าน เป้า < 1.5 ล้าน |
ปานกลาง |
| Timeline 22 สัปดาห์ |
ลูกค้ามี budget approval แค่ 6 เดือน |
สูง |
เมื่อเห็นโจทย์แบบนี้ สิ่งแรกที่เราตัดออกคือ Big Bang Migration — การปิดระบบ Friday night แล้วเปิดระบบใหม่ Monday morning ซึ่งเป็นวิธีที่ตำราบอกว่า "ง่ายที่สุด" แต่ในโลกจริงมันคือ วิธีที่ fail บ่อยที่สุด
จากสถิติ Gartner ระบุว่า 55-75% ของ ERP projects ล้มเหลว ที่จะ deliver ตาม expectation และ Big Bang approach คือหนึ่งในสาเหตุหลัก
แนวทาง: 3 กลยุทธ์หลัก
1. Strangler Fig Pattern — ค่อยๆ แทนที่ ไม่ใช่รื้อทิ้ง
ชื่อ pattern นี้มาจากต้นไทรที่ค่อยๆ เติบโตครอบต้นไม้เดิมจนกลายเป็นต้นไม้ใหม่ — ต้นไม้เดิมค่อยๆ หายไปโดยไม่มีใครสังเกต
เราใช้แนวคิดเดียวกัน: ย้ายทีละ module ไม่ใช่ย้ายทั้งระบบพร้อมกัน เมื่อ module ใหม่พร้อม ก็ค่อยๆ สับ traffic ไป จนระบบเก่าค่อยๆ หมดหน้าที่
ข้อดีคือ ถ้า module ไหนมีปัญหา เราถอยกลับได้ทันที โดยไม่กระทบ module อื่น
2. Dual-write Pattern — เขียนข้อมูลทั้ง 2 ระบบพร้อมกัน
ระหว่างช่วงเปลี่ยนผ่าน ทุก transaction ที่เกิดขึ้นจะถูกเขียนลงทั้งระบบเก่าและระบบใหม่พร้อมกัน — เพื่อให้มั่นใจว่า ข้อมูลตรงกัน 100% ตลอดเวลา
ถ้าระบบใหม่มีปัญหา ข้อมูลทั้งหมดยังอยู่ในระบบเก่าครบถ้วน — เราแค่สับ traffic กลับ
3. Shadow Traffic — ทดสอบด้วย traffic จริง ไม่ใช่ test data
นี่คือสิ่งที่ทำให้เรามั่นใจก่อน cutover: เราส่ง traffic จริง 100% ไปให้ระบบใหม่ประมวลผล แต่ ยังใช้ผลลัพธ์จากระบบเก่าตอบกลับ user ระหว่างนั้นเราเปรียบเทียบผลลัพธ์ของทั้ง 2 ระบบอัตโนมัติทุก transaction
ถ้าผลลัพธ์ไม่ตรงกัน → alert ทันที → ทีมเข้าไปตรวจสอบ
กระบวนการ 4 Phases
Phase 1: Data Assessment & Mapping (สัปดาห์ 1-4)
สิ่งที่เราพบเมื่อเข้าไปสำรวจระบบเก่า:
- 847 tables ในฐานข้อมูล (คาดไว้ประมาณ 500)
- 23 tables มี data quality issues ร้ายแรง เช่น ข้อมูลซ้ำ, null values ในที่ที่ไม่ควร null, date format ไม่สม่ำเสมอ
- 67 tables ที่ไม่มีใครใช้แล้วแต่ยังกิน storage อยู่
- 12 ล้าน records ที่ต้อง migrate ทั้งหมด
- จาก 200+ customizations เมื่อประเมินจริงๆ พบว่า มีแค่ 127 จุด ที่ยังจำเป็น ที่เหลือเป็น workaround ของ bug เก่าที่ไม่จำเป็นในระบบใหม่
เฉพาะ Phase นี้ก็ใช้เวลา 4 สัปดาห์เต็มๆ แต่มันคือ phase ที่สำคัญที่สุด เพราะถ้าเรา map ข้อมูลผิดตั้งแต่ต้น ทุกอย่างที่ตามมาจะผิดหมด
Phase 2: Module-by-module Migration (สัปดาห์ 5-16)
เราเลือกลำดับการย้ายแบบนี้:
| ลำดับ |
Module |
จำนวน Records |
สัปดาห์ |
เหตุผลที่ย้ายก่อน-หลัง |
| 1 |
Inventory |
3.2M records |
สัปดาห์ 5-8 |
มี dependency น้อย ทดสอบ pattern ได้ |
| 2 |
Purchasing |
2.1M records |
สัปดาห์ 7-10 |
เชื่อมกับ Inventory โดยตรง |
| 3 |
Sales |
4.3M records |
สัปดาห์ 10-13 |
Module ใหญ่สุด ต้องมั่นใจก่อนย้าย |
| 4 |
Finance |
2.4M records |
สัปดาห์ 13-16 |
Critical สุด ย้ายท้ายสุดเพื่อลด risk |
สังเกตว่า timeline ซ้อนกัน — เราไม่ได้รอให้ module ก่อนหน้าเสร็จ 100% ถึงจะเริ่ม module ถัดไป แต่เราเริ่ม module ถัดไปเมื่อ module ก่อนหน้าผ่าน milestone ที่กำหนดแล้ว
Phase 3: Shadow Testing (สัปดาห์ 17-20)
4 สัปดาห์ที่ระบบใหม่ทำงานเคียงข้างระบบเก่า โดยรับ traffic จริง 100%:
- สัปดาห์ 17: พบ discrepancy 0.3% ใน Sales module — สาเหตุมาจาก rounding logic ที่ต่างกัน
- สัปดาห์ 18: แก้ไข rounding issue, discrepancy ลดเหลือ 0.008%
- สัปดาห์ 19: ทุก module discrepancy < 0.001%
- สัปดาห์ 20: Zero discrepancy ติดต่อกัน 7 วัน — เราพร้อม cutover
Phase 4: Cutover (สัปดาห์ 21-22)
นี่คือส่วนที่ทำให้เราภูมิใจที่สุด: ไม่มี user คนไหนรู้ว่า cutover เกิดขึ้น
เราค่อยๆ สับ traffic จากระบบเก่าไประบบใหม่แบบ gradual:
- วันที่ 1: 10% traffic → ระบบใหม่
- วันที่ 3: 25% traffic
- วันที่ 5: 50% traffic
- วันที่ 7: 75% traffic
- วันที่ 10: 100% traffic → ระบบใหม่ทั้งหมด
ระหว่างนั้นถ้า error rate > 0.1% เราจะ auto-rollback traffic กลับไประบบเก่าทันที — แต่ตลอด 10 วันของ cutover ไม่เคยต้อง rollback แม้แต่ครั้งเดียว
Round 1 ที่ล้มเหลว: บทเรียนราคา 4.7 ล้านบาท
เราจะไม่ทำเป็นว่าทุกอย่างราบรื่นตั้งแต่ต้น เพราะมันไม่ใช่
สัปดาห์ที่ 8 — Purchasing Module ล้มเหลว
ตอนเริ่ม Dual-write สำหรับ Purchasing module ทุกอย่างดูดีใน 3 วันแรก แต่พอวันที่ 4 ทีม Finance แจ้งว่า ตัวเลขใน PO บางรายการ "ดูแปลกๆ"
เมื่อขุดลึกลงไป เราพบว่า:
- 2.3% ของ PO ทั้งหมดมีราคาสินค้าไม่ตรงกัน ระหว่าง 2 ระบบ
- สาเหตุ: currency conversion logic ของระบบเก่าคำนวณแบบหนึ่ง ระบบใหม่คำนวณอีกแบบ — ผลต่างเล็กน้อยต่อ transaction แต่เมื่อรวมกันเป็น 4.7 ล้านบาท
- ที่น่ากลัวคือ ถ้าไม่มี Dual-write Pattern ที่เปรียบเทียบ 2 ระบบอยู่ตลอด เราอาจไม่พบ issue นี้จนกว่าจะปิดงบ
สิ่งที่เราทำ
- หยุด migration ของ Purchasing module ทันที — Inventory ที่ย้ายไปแล้วยังทำงานปกติในระบบใหม่
- ใช้เวลา 2 สัปดาห์ วิเคราะห์ทุก conversion logic ในระบบเก่า (ซึ่งไม่มี documentation เลย)
- สร้าง reconciliation layer ที่ตรวจสอบทุก PO amount โดยอัตโนมัติก่อนบันทึก
- รัน regression test กับข้อมูลย้อนหลัง 2 ปี เพื่อให้มั่นใจว่า logic ตรงกัน 100%
ผลคือ timeline เลื่อนออกไป 2 สัปดาห์ (จาก 22 เป็น 24 สัปดาห์) แต่เราไม่เสียข้อมูลแม้แต่ record เดียว และที่สำคัญ — ระบบเก่ายังทำงานปกติตลอด ไม่มีใครได้รับผลกระทบ
นี่คือเหตุผลที่เราเลือก Strangler Fig ไม่ใช่ Big Bang — ถ้าเป็น Big Bang แล้วเจอ issue นี้ตอน go-live weekend หมายถึง โรงงานทั้งโรงหยุด
ผลลัพธ์: Before vs After
| ตัวชี้วัด |
ก่อน Migration |
หลัง Migration |
การเปลี่ยนแปลง |
| Response Time เฉลี่ย |
4.2 วินาที |
380 มิลลิวินาที |
เร็วขึ้น 11 เท่า |
| Monthly Downtime |
12 ชั่วโมง |
0 ชั่วโมง (6 เดือนแรก) |
-100% |
| Data Integrity |
ไม่เคยตรวจสอบ |
12M records verified, 99.9997% match |
— |
| User Satisfaction |
3.2/10 |
8.7/10 |
+172% |
| Maintenance Cost/ปี |
3.5 ล้านบาท |
1.2 ล้านบาท |
ประหยัด 2.3 ล้าน/ปี |
| Time to Generate Report |
45 นาที |
3 นาที |
เร็วขึ้น 15 เท่า |
| Bug Tickets/เดือน |
23 tickets |
4 tickets |
-83% |
สิ่งที่น่าสนใจคือตัวเลข 99.9997% data match — หมายความว่าจาก 12 ล้าน records มี แค่ 36 records ที่มี minor discrepancy (เศษสตางค์จาก rounding) ซึ่งทีม Finance ยืนยันว่า "ยอมรับได้ และดีกว่าที่คาดไว้มาก"
Cost Analysis: ลงทุนเท่าไหร่ คุ้มเมื่อไหร่
| รายการ |
จำนวนเงิน |
| ค่า Migration ทั้งโปรเจกต์ |
8.5 ล้านบาท |
| ค่า Maintenance เดิม/ปี |
3.5 ล้านบาท |
| ค่า Maintenance ใหม่/ปี |
1.2 ล้านบาท |
| ประหยัดได้/ปี |
2.3 ล้านบาท |
| มูลค่า Downtime ที่หายไป/ปี |
~1.8 ล้านบาท (ประเมินจาก production output ที่เสียไป) |
| รวมประหยัด/ปี |
4.1 ล้านบาท |
| ROI break-even |
~25 เดือน |
ถ้ามองแค่ตัวเลข 25 เดือน อาจรู้สึกนาน แต่ต้องไม่ลืมว่าระบบเก่ามี cost ที่ซ่อนอยู่อีกเยอะ — เวลาที่พนักงานเสียไปกับการ "รอระบบ" 4 วินาทีทุก click, ข้อมูลที่ report ออกมาช้า 45 นาที (ตอนนี้ 3 นาที), โอกาสทางธุรกิจที่เสียไปเพราะระบบไม่รองรับ
บทเรียน 5 ข้อ จากสนามรบจริง
1. Strangler Fig > Big Bang ทุกครั้ง
ไม่ว่าจะเร่งแค่ไหน ไม่ว่า stakeholder จะกดดันอย่างไร อย่าทำ Big Bang Migration กับระบบที่ใช้งาน production อยู่ ความเสี่ยงสูงเกินไป และ cost of failure สูงกว่า cost of going slow เสมอ
2. Data Assessment ใช้เวลามากกว่าที่คิด — เสมอ
เราแพลนไว้ 2 สัปดาห์ ใช้จริง 4 สัปดาห์ เราเจอ 847 tables ทั้งที่คาดไว้ 500 เจอ data quality issues 23 จุดที่ไม่มีใครรู้มาก่อน ถ้าเราไม่ใช้เวลาตรงนี้ เราจะไปเจอปัญหาตอน production ซึ่งแก้ยากกว่าร้อยเท่า
3. Dual-write คือ Safety Net ที่ขาดไม่ได้
ถ้าไม่มี Dual-write เราจะไม่พบ currency conversion bug จนกว่าจะสายเกินไป 4.7 ล้านบาทที่เกือบตกหล่น คือราคาที่ Dual-write Pattern ช่วยเราประหยัดได้
4. อย่าไว้ใจ Documentation ของระบบเก่า
จาก 200+ customizations ที่ลูกค้าบอก เมื่อตรวจจริงมี 127 ที่ใช้อยู่ documentation ที่มีอยู่ outdated หมด สิ่งที่เราทำคือ สร้าง understanding จากระบบจริง ไม่ใช่จาก doc
5. Shadow Traffic = ทดสอบด้วยความจริง
Test data ไม่มีวันครอบคลุมเท่า traffic จริง เราเจอ rounding discrepancy 0.3% ใน Sales module ที่ test data ไม่เคยจับได้ เพราะ test data ไม่มี edge case ของราคาสินค้าที่มีทศนิยมหลายตำแหน่ง
สิ่งที่ยังต้องปรับปรุง
เราไม่อยากทำเป็นว่าทุกอย่างสมบูรณ์แบบ ยังมีสิ่งที่เรากำลังทำต่อ:
Multi-region Failover
ปัจจุบันระบบใหม่ยัง run อยู่ single region ซึ่งถ้า region นั้นมีปัญหาก็ยัง down ได้ เราอยู่ระหว่างวางแผน multi-region setup เพื่อให้มั่นใจว่า zero downtime ที่ทำไว้จะ sustain ไปได้ในระยะยาว
Legacy API Deprecation Timeline
ยังมีระบบภายนอก 3 ตัวที่ยัง connect กับ API ของระบบเก่าอยู่ เราต้อง migrate API consumers เหล่านี้ภายใน 6 เดือน ก่อนที่จะปิดระบบเก่าอย่างถาวร
AI-powered Anomaly Detection
ตอน migration เราสร้างระบบเปรียบเทียบข้อมูล 2 ระบบแบบ manual rules ซึ่งทำงานได้ดี แต่ในระยะยาวเราอยากใช้ AI/ML มาช่วยตรวจจับ anomaly ในข้อมูลแบบอัตโนมัติ เพื่อให้จับปัญหาได้เร็วขึ้นและครอบคลุมกว่า rule-based
สรุป
Zero Downtime ERP Migration ไม่ใช่เรื่องง่าย แต่ก็ไม่ใช่เรื่องที่เป็นไปไม่ได้ สิ่งที่ทำให้โปรเจกต์นี้สำเร็จไม่ใช่ technology ที่ใช้ แต่คือ วิธีคิดและกระบวนการ — การเลือก Strangler Fig แทน Big Bang, การใช้ Dual-write เป็น safety net, การทดสอบด้วย shadow traffic จริงก่อน cutover
ถ้าองค์กรของคุณกำลังเผชิญกับ legacy system ที่ต้อง migrate — ไม่ต้องกลัว แต่ต้องมีแผน แผนที่ดีคือแผนที่มี fallback ทุกขั้นตอน ไม่ใช่แผนที่หวังว่า "คงไม่มีอะไรผิดพลาด"
หากสนใจปรึกษาเรื่องการวางแผน ERP Migration หรือ Digital Transformation สำหรับองค์กรของคุณ ทีม Enersys ยินดีรับฟังโจทย์ครับ — พูดคุยกับเรา
แหล่งข้อมูล
