มีระบบหนึ่งในองค์กรของคุณที่ทุกคนรู้จักดี — ไม่ใช่เพราะมันดี แต่เพราะไม่มีใครกล้าแตะ คนที่เขียนมันลาออกไปนานแล้ว documentation ไม่มีหรือมีแต่อ่านไม่รู้เรื่อง และทุกครั้งที่ต้องแก้ bug เล็ก ๆ ก็ต้องอธิษฐานก่อนกด deploy บางองค์กรยังรันอยู่บน Windows Server 2003 บาง codebase เขียนด้วย COBOL หรือ VB6 ที่หาคนดูแลแทบไม่ได้แล้วในตลาด นี่คือความเป็นจริงของ IT ในองค์กรไทยจำนวนมาก และมันมีชื่อเรียกที่ชัดเจนว่า Legacy System
Legacy System คืออะไรกันแน่
หลายคนเข้าใจว่า legacy system คือ "ระบบเก่า" แต่นิยามนั้นไม่แม่นยำพอ ระบบที่เก่า 10 ปีแต่ยังรองรับ load ได้ดี ยังมี support จากผู้ผลิต และยังแก้ไขได้ง่าย ไม่ถือเป็น legacy ในความหมายที่แท้จริง
Legacy system คือระบบที่ตอบสนองความต้องการทางธุรกิจได้น้อยลงเรื่อย ๆ เมื่อเทียบกับต้นทุนในการดูแลรักษา ไม่ว่าจะเป็นเทคโนโลยีที่ถึง end-of-life แล้ว ไม่สามารถ integrate กับระบบใหม่ได้โดยไม่ต้อง workaround ซับซ้อน หรือต้องการทักษะที่หายากเกินไปในตลาด
"A legacy system is not defined by its age, but by its inability to evolve with the business."
— คำอธิบายจาก Gartner ที่นักวิเคราะห์ด้าน IT architecture อ้างถึงบ่อยครั้ง
กล่าวง่าย ๆ คือ legacy system คือ ระบบที่กลายเป็นภาระมากกว่าจะเป็นสินทรัพย์
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 อย่างจริงจังแล้ว
ทำไมองค์กรไทยถึงอัปเกรดไม่ได้สักที
นี่คือหัวข้อที่ละเอียดอ่อนที่สุด เพราะหลายคนเข้าใจผิดว่าปัญหา legacy system เกิดจากความประมาทหรือการมองการณ์ไม่ไกล แต่ความเป็นจริงซับซ้อนกว่านั้นมาก
1. ความเสี่ยงที่รับรู้ได้สูงกว่าผลประโยชน์ที่มองเห็น
การเปลี่ยนระบบที่ "พอใช้ได้" ให้ผู้บริหารอนุมัติงบไม่ใช่เรื่องง่าย เพราะระบบเก่าที่ยังรันอยู่ให้ภาพของ "ไม่มีปัญหา" การลงทุนใน modernization จึงต้องแข่งกับโปรเจกต์อื่นที่ผลประโยชน์จับต้องได้ชัดกว่า เช่น ระบบ CRM ใหม่ หรือแอปมือถือที่ลูกค้าเห็น
2. ความรู้ติดอยู่กับคน ไม่ใช่กับเอกสาร
ในองค์กรไทยหลายแห่ง business logic ที่ซับซ้อนถูกเขียนฝังไว้ใน stored procedure ที่ไม่มี comment หรือใน Excel macro ที่ฝ่ายบัญชีใช้มา 15 ปี เมื่อจะเริ่ม migrate ทีมพบว่าไม่มีใครรู้แน่ชัดว่าระบบทำอะไรบ้าง และไม่กล้าเขียนใหม่เพราะกลัวทำบางอย่างหาย
3. งบประมาณแบบ CAPEX-heavy ของภาครัฐและ regulated industries
องค์กรในกลุ่ม government, banking และ telecom มักผูกกับรอบงบประมาณประจำปี โปรเจกต์ modernization ที่ใช้เวลา 18–24 เดือนยากที่จะผ่านกระบวนการจัดซื้อที่ออกแบบมาสำหรับงานที่จบใน 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 อีกต่อไป ช่องโหว่ที่ค้นพบใหม่จะไม่มีวันถูกปิด และ attacker ทราบดีว่าองค์กรใดบ้างที่ยังใช้ระบบเหล่านี้
Compliance และ regulatory risk: สำหรับองค์กรในกลุ่ม banking ที่อยู่ภายใต้การกำกับดูแลของ ธปท. หรือองค์กรที่ต้องปฏิบัติตาม PDPA ระบบ legacy ที่ไม่สามารถ audit trail ได้ครบถ้วน หรือไม่รองรับการเข้ารหัสข้อมูลตามมาตรฐานปัจจุบัน อาจนำไปสู่บทลงโทษที่รุนแรง
Hidden operational cost: ต้นทุนแฝงที่หลายองค์กรมองข้ามคือเวลาของทีม IT ที่ต้องทุ่มไปกับการดูแลระบบเก่าแทนที่จะสร้างสิ่งใหม่ รวมถึงค่า license ของ legacy software ที่มักแพงกว่าทางเลือกสมัยใหม่ และต้นทุนโอกาสจากฟีเจอร์ที่แข่งขันไม่ได้เพราะระบบไม่รองรับ
Talent retention: นักพัฒนารุ่นใหม่ไม่ต้องการทำงานกับ COBOL หรือ PowerBuilder ยิ่งระบบ legacy อยู่นาน ยิ่งยากที่จะหาและรักษาคนที่จะดูแลมันไว้
แนวทาง Modernization มีกี่แบบ
ไม่มีสูตรสำเร็จเดียวสำหรับ legacy modernization การเลือกแนวทางขึ้นอยู่กับ business criticality, budget, timeline และระดับความซับซ้อนของระบบ โดยทั่วไปแบ่งได้เป็น 4 แนวทางหลัก:
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
Rebuild (Replace)
ทำอะไร: สร้างระบบใหม่ทั้งหมดโดยอาจนำ business requirement เดิมมาใช้ แต่ไม่ใช้ codebase เดิม
เหมาะกับ: ระบบที่ technical debt สะสมจนถึงจุดที่ refactor ต่อไปไม่คุ้มค่า หรือ requirement เปลี่ยนไปมากจนระบบเดิมใช้เป็น reference ไม่ได้แล้ว
ข้อควรระวัง: ความเสี่ยงสูงสุด ใช้เวลานานที่สุด ต้องการ business stakeholder ที่ engage ตลอดโปรเจกต์
ทีมงานของ UNIXDEV มีประสบการณ์ดูแลและ modernize ระบบใน 4 แนวทางนี้มาตลอด 12+ ปี จาก 308+ โปรเจกต์ในกลุ่มอุตสาหกรรม government, banking, telecom และ media เราเข้าใจดีว่าองค์กรแต่ละแห่งมีบริบทต่างกัน และไม่มีคำตอบเดียวที่ถูกสำหรับทุกคน สิ่งที่เราทำคือช่วยประเมินสถานะระบบ วิเคราะห์ความเสี่ยง และออกแบบ migration path ที่ deliver ได้จริงภายใต้ข้อจำกัดขององค์กรคุณ
สรุป
Legacy system ไม่ได้เกิดจากความประมาท แต่เกิดจากการตัดสินใจที่สมเหตุสมผลในบริบทของเวลานั้น ปัญหาคือโลกเปลี่ยน แต่ระบบไม่ได้เปลี่ยนตาม และในที่สุดช่องว่างระหว่างสิ่งที่ระบบทำได้กับสิ่งที่ธุรกิจต้องการก็กว้างขึ้นเรื่อย ๆ จนถึงจุดที่ต้นทุนของการ "ไม่ทำ" สูงกว่าต้นทุนของการ "ทำ"
การ modernize ระบบ legacy ไม่จำเป็นต้องเป็น "big bang" migration ที่น่ากลัว ด้วยแนวทางที่เหมาะสมและทีมที่มีประสบการณ์ สามารถ migrate ทีละส่วน ลดความเสี่ยง และรักษา business continuity ได้ตลอดกระบวนการ
พร้อมประเมินสถานะระบบของคุณ?
UNIXDEV ให้บริการ Legacy Application Maintenance และ Modernization สำหรับองค์กรในทุกขนาด ตั้งแต่การ audit ระบบเพื่อประเมิน technical debt ไปจนถึงการวางแผนและดำเนินการ migration เต็มรูปแบบ ทีมของเรา certified ISO 9001:2015 และ ISO/IEC 29110-4-1:2018 พร้อมประสบการณ์จากองค์กรกว่า 71 แห่ง
บทความโดย UNIXDEV Team · unixdev.co.th
