Case Study — Migrate 8 สาขาจาก MPLS ไป SD-WAN ใน 6 เดือน บทเรียน 5 ข้อ

1. Context — ทำไมลูกค้าตัดสินใจย้าย#

ลูกค้าค้าปลีกรายหนึ่งที่มี 8 สาขาในภาคใต้ใช้ MPLS L3 VPN มาเกือบ 7 ปี โครงข่ายนี้เคยตอบโจทย์ได้ดีในยุคที่ทุกอย่างอยู่ใน data center เดียว แต่เมื่อองค์กรเริ่มใช้ SaaS หลายตัว ได้แก่ Microsoft 365, ERP บน cloud, และระบบ POS ที่ต้องการ API callback แบบ real-time ปัญหาก็เริ่มสะสม

Trigger ที่ทำให้โปรเจกต์เริ่มขึ้นจริงคือการต่ออายุสัญญา MPLS ที่กำลังจะหมดพอดีในไตรมาส 3 ของปีนั้น ค่าใช้จ่ายรายเดือนของ MPLS อยู่ที่ประมาณ 180,000 บาท/เดือนสำหรับ 8 สาขา bandwidth รวม 8×2 Mbps ซึ่งเป็น guaranteed CIR แต่แพงมากเมื่อเทียบกับ broadband ที่ราคาเดียวกันได้ 100 Mbps แบบ best-effort

ปัญหาที่ทีม IT รายงานก่อนตัดสินใจ:

• Latency SaaS สูงผิดปกติ — traffic ต้อง hairpin กลับ HQ ก่อนออก internet ทำให้ Microsoft 365 ช้า 80-120 ms เพิ่มขึ้นโดยไม่จำเป็น
• Bandwidth ขาดช่วง peak — 2 Mbps per branch ไม่พอในช่วงสิ้นเดือนที่ทุกสาขา sync รายงาน ERP พร้อมกัน
• ไม่มี redundancy — MPLS link เดียวต่อสาขา หาก provider ขัดข้องต้องรอ 4-8 ชั่วโมงกว่าจะแก้ได้

การตัดสินใจไม่ต่ออายุ MPLS และย้ายไป SD-WAN จึงเริ่มต้นจากแรงกดดันด้านต้นทุนและ performance ควบคู่กัน

2. Vendor Selection — ทำไมถึงเลือก FortiGate SD-WAN#

ทีมประเมิน 3 แพลตฟอร์มหลัก ได้แก่ FortiGate SD-WAN, Aruba EdgeConnect, และ Cisco Meraki MX

Aruba EdgeConnect มี feature orchestration ที่ครบมาก แต่ราคา licensing ต่อปีสูง และทีม IT ของลูกค้าไม่มีประสบการณ์กับ HPE/Aruba มาก่อน learning curve จึงสูงเกินไปสำหรับโปรเจกต์ที่ต้องเสร็จใน 6 เดือน

Cisco Meraki MX ใช้งานง่าย dashboard ดี แต่ราคา hardware และ license รวมกันแล้วแพงกว่าตัวอื่น และ Meraki ผูกกับ cloud management ทั้งหมด หากองค์กรต้องการ on-premise fallback หรือ custom policy ก็ทำได้ยาก

FortiGate SD-WAN ชนะในสามมิติ:

1. Total Cost — hardware + FortiCare 3 ปี ถูกกว่า Meraki ประมาณ 30%
2. Ecosystem — ลูกค้ามี FortiSwitch และ FortiAP อยู่แล้ว การรวม Security Fabric ทำได้ทันที
3. Flexibility — SD-WAN rules เขียน custom ได้ละเอียด ไม่ถูกล็อกใน template สำเร็จรูป

3. Architecture — Hub-Spoke Dual ISP พร้อม Application Steering#

โครงสร้างที่ deploy แบ่งเป็นสองชั้น:

HQ (Hub) — FortiGate ขนาด mid-range 2 ตัวในโหมด HA active-passive รับ tunnel จาก branch ทั้ง 8 แห่ง เชื่อมต่อ ISP หลักด้วย fiber 1 Gbps และ ISP รองด้วย 4G/LTE backup

Branch (Spoke) — FortiGate รุ่น entry-level 1 ตัวต่อสาขา ต่อ ISP หลัก (fiber) และ ISP รอง (fiber หรือ 4G ขึ้นอยู่กับพื้นที่) ทั้งสองลิงก์ active พร้อมกัน ไม่ใช่ active-standby

Application Steering Policy ที่ตั้ง:

• Microsoft 365, Teams → ออก internet โดยตรงจาก branch (local breakout) โดยใช้ ISP ที่มี latency ต่ำกว่า ณ ขณะนั้น
• ERP และ internal application → ผ่าน tunnel กลับ HQ เสมอ เพราะต้องการ QoS และ security inspection
• Streaming และ social media → จำกัด bandwidth ด้วย traffic shaping ไม่ให้กิน link หลัก

แต่ละ tunnel ใช้ IPsec + BGP เพื่อให้ failover อัตโนมัติและ route convergence เร็วขึ้น

4. บทเรียน 5 ข้อที่ได้เรียนจากโปรเจกต์นี้#

4.1 ISP Last-Mile คือความเสี่ยงที่ใหญ่ที่สุด#

ก่อนโปรเจกต์ ทีมคิดว่า SD-WAN จะแก้ปัญหา ISP ได้ ความจริงคือ SD-WAN เลือกใช้ link ที่ดีกว่าได้ แต่ถ้า ISP ทุกเส้นในพื้นที่ขัดข้องพร้อมกัน ก็ไม่มีทางช่วยได้

สาขา 2 แห่งในพื้นที่ห่างไกลเจอปัญหา fiber ตัดบ่อยในช่วงมรสุม ทีมต้องเพิ่ม 4G backup และทำ AS-Path prepending เพื่อ de-prefer link ที่ flap บ่อย แทนที่จะใช้ค่า latency/jitter เพียงอย่างเดียว

4.2 Application Steering ไม่ใช่ Magic#

Policy ที่เขียนในวันแรกไม่เคยถูกตั้งแต่ต้น Microsoft 365 มี endpoint หลายร้อยรายการ ถ้า allowlist ไม่ครบ บาง service จะวิ่งผิด path ทำให้ Teams call หลุดทั้งที่ link ปกติ

บทเรียนคือต้องใช้ FortiGuard Application Control ร่วมกับ Microsoft 365 IP/URL feed อย่างเป็นระบบ และต้องมีคนนั่ง monitor traffic จริงช่วง 2 สัปดาห์แรกหลัง cutover

4.3 DR Plan ที่ทีมลืมวางแผน#

ทีมวางแผน cutover ดีมาก แต่ลืมถามว่า ถ้า FortiGate ที่ branch เสียกลางดึก จะทำอย่างไร? ไม่มีสาขาไหนมีทีม IT ประจำ

แก้โดยเตรียม spare unit ไว้ที่ HQ และทำ config backup อัตโนมัติทุกคืน export ไป cloud storage เพื่อให้สามารถส่งคนไปแทนอุปกรณ์และ restore config ได้ภายใน 2-3 ชั่วโมง แทนที่จะรอ RMA 3-5 วัน

4.4 Change Window และ Cutover Risk#

สาขาที่ทำ cutover ผิดพลาดมากที่สุดคือสาขาที่ทำในวันธรรมดาช่วงกลางวัน เพราะทีมรีบ ตรงกันข้ามกับสาขาที่ทำช่วงดึกวันเสาร์และทดสอบให้ครบก่อน go-live ซึ่งไม่มีปัญหาเลย

4.5 ทีม ISP Contact ที่ติดต่อได้จริง#

เมื่อ link มีปัญหาหลัง cutover การโทรหา call center ISP ทั่วไปเสียเวลามาก สิ่งที่ช่วยได้มากที่สุดคือการมี NOC contact หรือ account manager ของ ISP ที่รับโทรศัพท์ได้โดยตรง

ก่อนเริ่มโปรเจกต์ควรขอ escalation path จาก ISP ทุกรายเป็นลายลักษณ์อักษร และทดสอบว่าติดต่อได้จริงก่อนวันที่จะ cutover

5. Result — KPI ก่อนและหลัง#

ตัวชี้วัด	ก่อน (MPLS)	หลัง (SD-WAN)
Latency HQ → Microsoft 365	95-120 ms	18-35 ms
ค่าใช้จ่ายรายเดือน	~180,000 บาท	~85,000 บาท
Bandwidth per branch	2 Mbps CIR	100/20 Mbps (dual ISP)
Downtime ต่อเดือน (เฉลี่ย)	4.2 ชั่วโมง	0.3 ชั่วโมง
Failover time	manual / 4-8 ชั่วโมง	อัตโนมัติ < 30 วินาที

ประหยัดค่า WAN ได้ประมาณ 95,000 บาท/เดือน หรือ 1.14 ล้านบาท/ปี ซึ่ง ROI คืนทุนค่า hardware และ deployment ได้ภายใน 14 เดือน

6. สรุป และ Action Priority สำหรับองค์กรที่กำลังจะ Migrate#

ถ้าองค์กรของคุณกำลังพิจารณา migrate MPLS → SD-WAN ให้เริ่มจาก 3 สิ่งนี้ก่อน:

1. ตรวจสอบ contract renewal date — ถ้าสัญญา MPLS จะหมดใน 6-9 เดือน นี่คือ window ที่ดีที่สุด เพราะไม่ต้องจ่าย penalty
2. สำรวจ ISP last-mile ในแต่ละพื้นที่สาขา — ถ้า fiber ไม่เสถียรในพื้นที่ใด ต้องวางแผน backup ก่อน ไม่ใช่หลัง deploy
3. POC ก่อนตัดสินใจซื้อ — ขอ FortiGate demo unit หรือ cloud sandbox ทดสอบ application steering กับ traffic จริงในองค์กร อย่าเชื่อเฉพาะ benchmark ใน datasheet

SD-WAN ไม่ใช่ปุ่มวิเศษที่กดแล้วทุกอย่างดีขึ้นทันที แต่ถ้าวางแผนดีและมีทีมที่มีประสบการณ์นำทาง มันคือการลงทุนที่คุ้มค่ามากสำหรับองค์กรที่มีหลายสาขา

C9NETWORK มีประสบการณ์ออกแบบและ deploy SD-WAN สำหรับองค์กรไทยหลายสาขา ทั้ง FortiGate, Aruba และ Cisco ติดต่อทีมได้เพื่อรับคำปรึกษาและ assessment เบื้องต้นโดยไม่มีค่าใช้จ่าย เราช่วยตั้งแต่วิเคราะห์ความคุ้มค่าจนถึงวันที่ cutover เสร็จสมบูรณ์