Legacy System คืออะไร? ตัวอย่างและทางเลือก

Legacy System (มักเรียกกันว่าระบบเก่า) คือซอฟต์แวร์หรือระบบที่องค์กรยังใช้ในงานสำคัญ แต่สร้างบนเทคโนโลยีที่ผู้ผลิตเลิกสนับสนุนหรือหาคนดูแลยาก ทำให้แก้ไข เชื่อมต่อ หรือรักษาความปลอดภัยได้ยากขึ้นเรื่อย ๆ

มีระบบหนึ่งในองค์กรของคุณที่ทุกคนรู้จักดี — ไม่ใช่เพราะมันดี แต่เพราะไม่มีใครกล้าแตะ คนที่เขียนมันลาออกไปนานแล้ว documentation ไม่มีหรือมีแต่อ่านไม่รู้เรื่อง และทุกครั้งที่ต้องแก้ bug เล็ก ๆ ก็ต้องอธิษฐานก่อนกด deploy บางระบบยังรันอยู่บน Windows Server 2003 ซึ่ง Microsoft สิ้นสุด extended support ไปตั้งแต่เดือนกรกฎาคม 2015 บาง codebase เขียนด้วย COBOL หรือ VB6 ซึ่งหาคนที่มีทักษะมาดูแลได้ยากขึ้น สถานการณ์แบบนี้พบได้ในหลายองค์กร

Legacy System คืออะไรกันแน่

คำว่า "ระบบเก่า" เป็นคำที่ใช้เรียกกันทั่วไป แต่อายุอย่างเดียวไม่ได้ทำให้ระบบเป็น legacy ระบบที่เก่า 10 ปีแต่ยังรองรับ load ได้ดี ยังมี support จากผู้ผลิต และยังแก้ไขได้ง่าย ไม่ถือเป็น legacy ในความหมายที่แท้จริง

ในทางปฏิบัติ ระบบจะกลายเป็น legacy เมื่อตอบสนองความต้องการทางธุรกิจได้น้อยลงเรื่อย ๆ เมื่อเทียบกับต้นทุนในการดูแลรักษา ไม่ว่าจะเป็นเทคโนโลยีที่ถึง end-of-life แล้ว ไม่สามารถ integrate กับระบบใหม่ได้โดยไม่ต้อง workaround ซับซ้อน หรือต้องการทักษะที่หายากเกินไปในตลาด

กล่าวง่าย ๆ คือ legacy system คือ ระบบที่กลายเป็นภาระมากกว่าจะเป็นสินทรัพย์

ตัวอย่าง Legacy System ที่พบบ่อยในองค์กร

Legacy System ไม่ได้ผูกกับภาษาหรือยี่ห้อใดโดยเฉพาะ ตัวอย่างที่พบบ่อยแบ่งตามประเภทเทคโนโลยีได้ดังนี้ (วันที่หมดการสนับสนุนอ้างจากหน้า lifecycle ของผู้ผลิต ตรวจเมื่อตุลาคม 2026)

• Mainframe และโปรแกรม COBOL: ระบบงานธุรกรรมหลักที่ยังรันได้ แต่หาคนเขียนและดูแล COBOL ได้ยากขึ้น และ business rule มักอยู่ในโค้ดกับคนไม่กี่คน
• AS/400 (IBM i) และโปรแกรม RPG: ปัญหามักไม่ได้อยู่ที่ตัวแพลตฟอร์ม แต่อยู่ที่โปรแกรม RPG รุ่นเก่า OS release ที่ไม่ได้อัปเกรด หรือฮาร์ดแวร์ที่ใช้มานาน
• VB6 และ FoxPro: โปรแกรม desktop หรือ client-server ที่เขียนไว้นานแล้ว Microsoft เลิกสนับสนุน IDE ของ Visual Basic 6.0 ตั้งแต่ 8 เมษายน 2008 แม้ runtime ยังได้รับการสนับสนุนตามอายุของ Windows ที่ยังรองรับ (เฉพาะปัญหาร้ายแรงและช่องโหว่สำคัญ) โปรแกรมจึงยังรันได้ แต่ไม่มีเครื่องมือพัฒนาที่ได้รับการสนับสนุนสำหรับแก้ไขต่อ
• ERP รุ่นเก่า: ERP ที่ปรับแต่งไว้มากจนอัปเกรดตามเวอร์ชันของผู้ผลิตไม่ได้ หรือเป็นเวอร์ชันที่ผู้ผลิตเลิกสนับสนุนแล้ว ต้องตรวจวันหมด support กับผู้ผลิตของแต่ละระบบ
• เว็บแอป PHP 5: PHP 5.6 ซึ่งเป็น branch สุดท้ายของ PHP 5 หมดอายุ (end of life) ตั้งแต่ 31 ธันวาคม 2018 ระบบที่ยังผูกกับ PHP 5 มักติดอยู่กับ framework หรือ library รุ่นเก่าที่ต้องอัปเกรดไปพร้อมกัน
• Windows Server 2003–2012: Windows Server 2003 สิ้นสุด extended support ในเดือนกรกฎาคม 2015 Windows Server 2008 ในเดือนมกราคม 2020 ส่วน Windows Server 2012 และ 2012 R2 สิ้นสุด extended support เมื่อ 10 ตุลาคม 2023 และ Extended Security Updates แบบเสียค่าใช้จ่ายปีที่ 3 สิ้นสุดเมื่อ 13 ตุลาคม 2026 เครื่องที่ยังรันรุ่นเหล่านี้จึงไม่ได้รับ security update จาก Microsoft แล้ว
• CentOS 7: CentOS Linux 7 หมดอายุ (EOL) เมื่อ 30 มิถุนายน 2024 เซิร์ฟเวอร์แอปหรือฐานข้อมูลที่ยังรัน CentOS 7 จึงไม่ได้รับ update จากโครงการแล้ว

Legacy System กับ Legacy Application ต่างกันอย่างไร: legacy application หมายถึงตัวโปรแกรมหรือโค้ด ส่วน legacy system มักหมายถึงทั้งชุด ตั้งแต่แอปพลิเคชัน ฐานข้อมูล ระบบปฏิบัติการ ฮาร์ดแวร์ ไปจนถึงการเชื่อมต่อกับระบบอื่น ในทางปฏิบัติสองคำนี้มักใช้แทนกัน แต่การแยกให้ออกช่วยบอกว่าต้องแก้ที่ชั้นไหน เช่น ถ้าแอปยังดีแต่ระบบปฏิบัติการหมด support อาจแก้ด้วยการย้ายแพลตฟอร์มโดยไม่ต้องเขียนแอปใหม่

ถ้าระบบเหล่านี้ยังย้ายไม่ได้ทันที อ่าน วิธีดูแลระบบเก่าที่หมด support ให้ใช้งานต่ออย่างปลอดภัย และถ้าระบบไม่มีเอกสารหรือคนเขียนไม่อยู่แล้ว ดู การรับช่วงระบบเก่าที่ไม่มีเอกสาร ส่วนหน่วยงานที่ต้องจ้างผู้รับจ้างมาดูแลระบบเดิม ดูข้อกำหนดที่ควรมีใน TOR จ้างดูแลระบบเดิม

6 สัญญาณที่บอกว่าระบบของคุณกำลัง Legacy

ไม่แน่ใจว่าระบบของคุณถึงจุดนั้นแล้วหรือยัง? ลองตรวจสอบด้วย checklist นี้:

• หา vendor support ไม่ได้แล้ว — ผู้ผลิต software หรือ OS ประกาศ end-of-life แต่ระบบยังต้องรันต่อ
• ไม่มีใครในทีมรู้จัก codebase ทั้งหมด — ความรู้กระจุกตัวอยู่ที่คนเดียว หรือหายไปพร้อมกับพนักงานที่ลาออก
• การเพิ่ม feature ใหม่ใช้เวลานานผิดปกติ — ตัวอย่างสมมติ: งานที่ควรใช้เวลา 2 สัปดาห์กลายเป็น 3 เดือน เพราะต้องระวัง side effect ทุกจุด
• Integration กับระบบอื่นต้องใช้ middleware แปลก ๆ — มีชั้น adapter ซ้อนกันหลายชั้นเพียงเพื่อให้ระบบ 2 ตัวคุยกันได้
• มีเฉพาะ binary ไม่มี source code — deploy ได้ แต่แก้ไม่ได้ หรือมี source แต่ไม่รู้ว่า version ไหนตรงกับ production
• ทีมกลัวที่จะ deploy ใกล้วันหยุด — ไม่มีใคร confident พอที่จะ release โดยไม่ต้อง standby ทั้งคืน

ถ้าตอบว่า "ใช่" ตั้งแต่ 3 ข้อขึ้นไป ระบบของคุณน่าจะถึงเวลาที่ต้องพิจารณา modernization อย่างจริงจังแล้ว (ตัวเลข 3 ข้อเป็นเกณฑ์คร่าว ๆ สำหรับเริ่มประเมิน ไม่ใช่มาตรฐานที่เป็นทางการ)

ทำไมองค์กรไทยถึงอัปเกรดไม่ได้สักที

นี่เป็นหัวข้อที่ละเอียดอ่อน เพราะหลายคนเข้าใจผิดว่าปัญหา legacy system เกิดจากความประมาทหรือการมองการณ์ไม่ไกล แต่ความเป็นจริงซับซ้อนกว่านั้นมาก

1. ความเสี่ยงที่รับรู้ได้สูงกว่าผลประโยชน์ที่มองเห็น

การเปลี่ยนระบบที่ "พอใช้ได้" ให้ผู้บริหารอนุมัติงบไม่ใช่เรื่องง่าย เพราะระบบเก่าที่ยังรันอยู่ให้ภาพของ "ไม่มีปัญหา" การลงทุนใน modernization จึงต้องแข่งกับโปรเจกต์อื่นที่ผลประโยชน์จับต้องได้ชัดกว่า เช่น ระบบ CRM ใหม่ หรือแอปมือถือที่ลูกค้าเห็น

2. ความรู้ติดอยู่กับคน ไม่ใช่กับเอกสาร

ในหลายองค์กร business logic ที่ซับซ้อนถูกเขียนฝังไว้ใน stored procedure ที่ไม่มี comment หรือใน Excel macro ที่ฝ่ายบัญชีใช้ต่อกันมาหลายปี เมื่อจะเริ่ม migrate ทีมพบว่าไม่มีใครรู้แน่ชัดว่าระบบทำอะไรบ้าง และไม่กล้าเขียนใหม่เพราะกลัวทำบางอย่างหาย

3. งบประมาณที่ผูกกับรอบปีงบประมาณ

องค์กรจำนวนไม่น้อย โดยเฉพาะหน่วยงานภาครัฐ มักผูกการลงทุนกับรอบงบประมาณประจำปี โปรเจกต์ modernization ที่ต้องทำต่อเนื่องหลายปีงบประมาณจึงอาจต้องแบ่งเป็นหลายเฟสและขออนุมัติหลายรอบ ทำให้เริ่มต้นได้ยากกว่างานที่จบได้ใน fiscal year เดียว

4. ขาด internal champion ที่มีอำนาจเพียงพอ

IT manager รู้ดีว่าต้องทำ แต่ไม่มี mandate จาก C-level CTO รู้ว่าควรทำ แต่ไม่มีเวลาสร้าง business case ที่แข็งแรงพอ ในหลายองค์กรจึงเกิดสภาวะ "ทุกคนรู้ แต่ไม่มีใครทำ" ซึ่งยิ่งยืดนานออกไป technical debt ก็ยิ่งสะสม

5. ความกลัวว่าจะทำให้ระบบล่มระหว่าง migration

ความกังวลข้อนี้สมเหตุสมผลมาก โดยเฉพาะสำหรับระบบที่รองรับ transaction ทางการเงินหรือข้อมูลของภาครัฐ การ cutover ผิดพลาดสักครั้งอาจสร้างความเสียหายที่เกินกว่าจะรับผิดชอบได้ ความกลัวนี้จึงทำให้หลายองค์กรเลือก "อยู่กับปัญหาที่รู้จัก" แทนที่จะเผชิญกับ "ความเสี่ยงที่ยังไม่รู้"

ความเสี่ยงจริงของการปล่อย Legacy System ทิ้งไว้

การ "ไม่ทำอะไร" ไม่ใช่ทางเลือกที่ปลอดภัย มันเป็นเพียงการเลือกแบบความเสี่ยงที่ต่างออกไป

Security vulnerabilities ที่ไม่มี patch: ระบบที่รันบน OS หรือ framework ที่ end-of-life แล้วจะไม่ได้รับ security update ตามปกติจากผู้ผลิตอีกต่อไป บางผู้ผลิตมีทางเลือกแบบเสียค่าใช้จ่ายเพิ่มเพื่อรับ patch ต่อในระยะจำกัด เช่น Extended Security Updates ของ Microsoft ซึ่ง Microsoft ระบุเองว่าเป็นทางเลือกสุดท้ายระหว่างย้ายไปแพลตฟอร์มที่ยังได้รับ support เมื่อไม่มี patch ช่องโหว่ที่ค้นพบใหม่ก็อาจไม่ได้รับการแก้ไข และต้องพึ่งมาตรการชดเชยอื่นแทน

Compliance และ regulatory risk: สำหรับองค์กรในกลุ่ม banking ที่อยู่ภายใต้การกำกับดูแลของ ธปท. หรือองค์กรที่ต้องปฏิบัติตาม PDPA ระบบ legacy ที่ไม่สามารถ audit trail ได้ครบถ้วน หรือไม่รองรับการเข้ารหัสข้อมูลตามมาตรฐานปัจจุบัน อาจทำให้ยากที่จะแสดงว่าองค์กรมีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม ทั้งนี้ พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 37 (1) กำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคลต้องจัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม และต้องทบทวนมาตรการนั้นเมื่อจำเป็นหรือเมื่อเทคโนโลยีเปลี่ยนแปลงไป การไม่ปฏิบัติตามมาตรา 37 มีโทษปรับทางปกครองตามมาตรา 83

Hidden operational cost: ต้นทุนแฝงที่หลายองค์กรมองข้ามคือเวลาของทีม IT ที่ต้องทุ่มไปกับการดูแลระบบเก่าแทนที่จะสร้างสิ่งใหม่ รวมถึงค่า license หรือค่า extended support ของ software รุ่นเก่าที่บางผู้ผลิตเรียกเก็บเพิ่มหลังหมดระยะ support ปกติ และต้นทุนโอกาสจากฟีเจอร์ที่แข่งขันไม่ได้เพราะระบบไม่รองรับ

Talent retention: ทักษะเฉพาะอย่าง COBOL หรือ PowerBuilder อาจหาได้ยากทั้งในทีมและในตลาดแรงงาน ยิ่งระบบ legacy อยู่นาน ยิ่งยากที่จะหาและรักษาคนที่จะดูแลมันไว้ และความรู้ก็ยิ่งผูกอยู่กับคนไม่กี่คน

แนวทาง Modernization มีกี่แบบ

ไม่มีสูตรสำเร็จเดียวสำหรับ legacy modernization การเลือกแนวทางขึ้นอยู่กับ business criticality, budget, timeline และระดับความซับซ้อนของระบบ บทความนี้จัดกลุ่มเป็น 4 แนวทางหลัก (บางกรอบงานแบ่งละเอียดกว่านี้ เช่น 7 Rs ของ AWS ที่รวม retire, retain, relocate และ repurchase ไว้ด้วย):

Rehost (Lift & Shift)

ทำอะไร: ย้ายระบบเดิมขึ้น cloud หรือ infrastructure ใหม่โดยไม่เปลี่ยน code

เหมาะกับ: องค์กรที่ต้องการออกจาก on-premise datacenter อย่างเร็ว หรือต้องการลด hardware cost ก่อน แล้วค่อย refactor ในเฟสถัดไป

ข้อควรระวัง: แก้ปัญหาเรื่อง infrastructure แต่ไม่แก้ปัญหา codebase ที่ brittle

Replatform (Move & Improve)

ทำอะไร: ย้ายระบบไปยัง platform ใหม่พร้อมปรับ configuration บางส่วน เช่น เปลี่ยนจาก on-prem Oracle ไปยัง managed RDS บน AWS โดยไม่เขียน application ใหม่ทั้งหมด

เหมาะกับ: ระบบที่ core logic ยังดี แต่ infrastructure layer เป็นภาระ

ข้อควรระวัง: ต้องทดสอบ compatibility อย่างละเอียดก่อน cutover

Refactor (Re-architect)

ทำอะไร: เขียนใหม่บางส่วนหรือปรับโครงสร้าง code ให้ทันสมัย เช่น แยก monolith ออกเป็น microservices หรือเพิ่ม API layer เพื่อให้ integrate กับระบบอื่นได้

เหมาะกับ: ระบบที่ business logic มีคุณค่า แต่ architecture ไม่รองรับการ scale หรือ integration

ข้อควรระวัง: ใช้เวลาและทรัพยากรสูง ต้องการทีมที่เข้าใจทั้ง domain และ modern engineering

ถ้าเลือกปรับโครงสร้างและกำลังตัดสินใจว่าจะแตกเป็น microservices หรือไม่ ดูปรับระบบเก่าสู่ Cloud-Native

Rebuild (Replace)

ทำอะไร: สร้างระบบใหม่ทั้งหมดโดยอาจนำ business requirement เดิมมาใช้ แต่ไม่ใช้ codebase เดิม

เหมาะกับ: ระบบที่ technical debt สะสมจนถึงจุดที่ refactor ต่อไปไม่คุ้มค่า หรือ requirement เปลี่ยนไปมากจนระบบเดิมใช้เป็น reference ไม่ได้แล้ว

ข้อควรระวัง: มักมีความเสี่ยงสูงและใช้เวลานานที่สุดในสี่แนวทางนี้ ต้องการ business stakeholder ที่ engage ตลอดโปรเจกต์

ทีมงานของ UNIXDEV พัฒนาและดูแลระบบให้ลูกค้ามาราว 12 ปี รวมราว 308 โปรเจกต์ ทั้งหน่วยงานภาครัฐ รัฐวิสาหกิจ และองค์กรขนาดใหญ่ เราเข้าใจดีว่าองค์กรแต่ละแห่งมีบริบทต่างกัน และไม่มีคำตอบเดียวที่ถูกสำหรับทุกคน สิ่งที่เราทำคือช่วยประเมินสถานะระบบ วิเคราะห์ความเสี่ยง และออกแบบ migration path ที่ deliver ได้จริงภายใต้ข้อจำกัดขององค์กรคุณ

สรุป

Legacy system ไม่ได้เกิดจากความประมาท แต่เกิดจากการตัดสินใจที่สมเหตุสมผลในบริบทของเวลานั้น ปัญหาคือโลกเปลี่ยน แต่ระบบไม่ได้เปลี่ยนตาม และในที่สุดช่องว่างระหว่างสิ่งที่ระบบทำได้กับสิ่งที่ธุรกิจต้องการก็กว้างขึ้นเรื่อย ๆ จนถึงจุดที่ต้นทุนของการ "ไม่ทำ" สูงกว่าต้นทุนของการ "ทำ"

การ modernize ระบบ legacy ไม่จำเป็นต้องเป็น "big bang" migration ที่น่ากลัว หลายระบบสามารถ migrate ทีละส่วนเพื่อลดความเสี่ยงและรักษา business continuity ได้ แต่บางระบบอาจต้องวาง cutover window ที่วางแผนอย่างรัดกุม

UNIXDEV ให้บริการ Legacy Application Maintenance และ Modernization สำหรับหน่วยงานภาครัฐ รัฐวิสาหกิจ และองค์กร ตั้งแต่การ audit ระบบเพื่อประเมิน technical debt ไปจนถึงการวางแผนและดำเนินการ migration เต็มรูปแบบ UNIXDEV ได้รับการรับรอง ISO 9001:2015, ISO/IEC 29110-4-1:2018 และ ISO/IEC 27001:2022 (ดูรายละเอียดการรับรอง) และร่วมงานกับลูกค้ามาแล้วราว 71 องค์กร

---

บทความโดย UNIXDEV Team · unixdev.co.th