ภาพรวมระบบและสิ่งที่ยังขาด
สำรวจ source code, dependencies, วิธี deploy, ข้อมูล และผู้ถือสิทธิ์ พร้อมแยกสิ่งที่ตรวจได้กับส่วนที่ยังต้องขอข้อมูลเพิ่ม
● CRAFT · Legacy Application Maintenance
รับดูแลระบบเก่าและปรับปรุงซอฟต์แวร์องค์กร
ประเมิน codebase และความเสี่ยงของระบบเดิม วางแผนรับช่วงดูแล แก้ปัญหาที่กระทบงาน และทยอยปรับปรุงระบบ โดยเลือกแนวทางจากสภาพระบบและความต้องการของธุรกิจ
ปรึกษาการรับช่วงดูแลระบบเดิม → ประเมินก่อนรับช่วงวางแผน rollbackกำหนดขอบเขต MA
Assess code and dependency review
PHP 8.x runtime modernization
Runbook handoff and continuity
รับช่วงระบบเดิม โดยรู้ก่อนว่าจะเปลี่ยนอะไร
ไล่จากสิ่งที่มีอยู่ ไปสู่แผนที่ทดสอบและย้อนกลับได้
สำรวจของเดิม
เริ่มจากโค้ด ข้อมูล บัญชีระบบ และคนที่รู้ขั้นตอนงาน แยกสิ่งที่ตรวจแล้วออกจากสิ่งที่ยังต้องค้นหา
เตรียมทางกลับ
ตรวจ backup และวิธีกู้คืน เตรียมสภาพแวดล้อมทดสอบ ก่อนเปลี่ยนส่วนที่กระทบคนใช้งาน
ทยอยเปลี่ยน
แบ่งงานเป็นช่วงที่ตรวจรับได้ ประเมินผลกระทบ และกำหนดผู้อนุมัติการเปลี่ยน production
ดูแลต่อ
ส่งต่อเอกสารและวิธีปฏิบัติงาน พร้อมตกลงขอบเขตบำรุงรักษาและงานเพิ่มเติมให้ชัด
ก่อนเริ่มโครงการ
บริการนี้เหมาะกับโจทย์ของคุณไหม
เหมาะกับองค์กรที่ยังต้องใช้ระบบเดิม แต่ผู้พัฒนาเดิมไม่อยู่ เอกสารไม่ครบ หรือปรับแก้แต่ละครั้งมีความเสี่ยง เริ่มจากประเมินสิทธิ์เข้าถึง สภาพโค้ด และความสำคัญของระบบ เพื่อเลือกว่าจะดูแลต่อ ปรับปรุงบางส่วน หรือพัฒนาใหม่
ขอบเขตและสิ่งส่งมอบที่วางแผนร่วมกัน
รายการความเสี่ยงและลำดับแก้ไข
จัดลำดับปัญหาตามผลกระทบต่อธุรกิจ รวมถึง runtime, license, การสำรองข้อมูล และส่วนที่ยังไม่มีชุดทดสอบ
แผนรับช่วงและปรับปรุง
กำหนดขอบเขตการเปลี่ยนแปลง สภาพแวดล้อมทดสอบ แผนสำรอง/กู้คืน และผู้อนุมัติการเปลี่ยน production
เอกสารและขอบเขตดูแลต่อ
ตกลงรายการ runbook, เอกสารระบบ, การถ่ายทอดงาน และ MA/SLA โดยระบุงานแก้ปัญหา งานบำรุงรักษา และฟีเจอร์ใหม่ให้ชัด
รายละเอียดงานและเกณฑ์รับมอบจะสรุปในข้อเสนอของแต่ละโครงการ เพื่อให้ทั้งสองทีมเข้าใจขอบเขตเดียวกันก่อนเริ่มงาน
จากโจทย์เบื้องต้นสู่การเริ่มงาน
สำรวจสิ่งที่เข้าถึงได้ก่อนรับปากแก้ไข
ตรวจความเป็นเจ้าของ สิทธิ์ใช้โค้ด และระบบที่เกี่ยวข้อง หากไม่มี source code หรือ access บางส่วน ต้องประเมินทางเลือกและข้อจำกัดก่อน
สร้างฐานสำหรับเปลี่ยนแปลงอย่างปลอดภัย
วางแผน backup และ restore ตรวจขั้นตอน deploy และเลือกเส้นทางสำคัญของธุรกิจสำหรับทดสอบก่อนเริ่มแก้ระบบ
ทยอยปรับปรุงและทบทวนความคุ้มค่า
แบ่งการเปลี่ยนเป็นช่วงที่ตรวจรับได้ ติดตามผลกระทบ และประเมินซ้ำว่าควรดูแลต่อ ย้ายบางส่วน หรือสร้างระบบใหม่
อะไรมีผลต่องบประมาณและระยะเวลา
ขนาดและคุณภาพโค้ด เวอร์ชันที่หมดการสนับสนุน ความพร้อมเอกสาร/ชุดทดสอบ ระบบภายนอกที่เชื่อม และช่วงเวลาที่อนุญาตให้หยุดระบบมีผลต่องบและเวลา งานสำรวจ แก้ปัญหาเริ่มต้น และ MA ต่อเนื่องควรมีขอบเขตแยกกัน
เตรียมอะไรไว้คุยกับทีม
เตรียมรายชื่อระบบ เทคโนโลยีเท่าที่ทราบ ปัญหาที่เกิดบ่อย รายชื่อผู้ถือ source code/บัญชี hosting และช่วงเวลาที่ระบบสำคัญกับธุรกิจ เริ่มคุยได้โดยยังไม่ส่งรหัสผ่านหรือข้อมูลลูกค้าจริง
คำถามก่อนตัดสินใจ
ไม่มีเอกสารหรือผู้พัฒนาเดิมแล้ว รับช่วงได้ไหม
ประเมินได้จากสิ่งที่มี เช่น source code สิทธิ์เข้าถึง และผู้ใช้งานที่อธิบายกระบวนการได้ แต่ต้องสำรวจขอบเขตก่อนยืนยันความเป็นไปได้และราคา
จำเป็นต้องเขียนใหม่ทั้งระบบหรือไม่
ขึ้นกับสภาพระบบ ความเสี่ยง และความต้องการที่เปลี่ยนไป การแก้เฉพาะจุดหรือทยอยย้ายอาจเหมาะในบางกรณี ขณะที่บางระบบควรประเมินการพัฒนาใหม่เทียบต้นทุนระยะยาว
รับประกันว่าจะไม่กระทบ production ได้ไหม
ต้องประเมินความเสี่ยงและตกลง maintenance window แผนทดสอบ และ rollback ก่อนเปลี่ยนระบบ ไม่รับประกัน zero downtime โดยยังไม่ตรวจสถาปัตยกรรมและ dependencies
เราทำอะไรให้ระบบเก่าได้
Refactor + modernize
ขยับ PHP เก่าขึ้น 8.x · upgrade Laravel major version · ปรับ WordPress + theme + plugin ให้ปลอดภัย
Multi-year MA
SLA tier — ตอบรับเหตุ · patch · backup · monitor · quarterly review (รายละเอียดดูที่ DevOps page)
Gradual migration paths
เปลี่ยนทีละชั้น — strangler pattern · cut-over ที่มี rollback · ไม่ใช่ big-bang rewrite
Knowledge transfer
เขียน runbook · architecture-decision-record · onboard team ของลูกค้าให้รับช่วงต่อได้
Stacks ที่เราเชี่ยวชาญเป็นพิเศษ
PHP Laravel WordPress Microsoft Dynamics AX 2012 K2 CodeIgniter jQuery legacy
ระบบเดิมควรไปต่อทางไหน
บางระบบแก้เฉพาะจุดก็ใช้งานต่อได้ บางระบบควรทยอยเปลี่ยน และบางระบบอาจคุ้มกว่าถ้าพัฒนาใหม่ ต้องดูทั้งสภาพโค้ดกับงานที่ธุรกิจต้องการก่อนตัดสินใจ
ประเมินระบบและโจทย์ธุรกิจ
ฐานเดิมยังตอบโจทย์
ดูแลต่อ
แก้จุดเสี่ยง เติมเอกสารและชุดทดสอบ ให้ทีมดูแลสิ่งที่ใช้อยู่ได้ชัดเจนขึ้น
บางส่วนเริ่มเป็นข้อจำกัด
ทยอยปรับ
แยกส่วนที่จะเปลี่ยน วางจุดเชื่อมกับระบบเดิม แล้วตรวจผลทีละช่วง
โจทย์เปลี่ยนไปมาก
พัฒนาใหม่
เทียบต้นทุนระยะยาวกับการดูแลของเดิม พร้อมวางแผนย้ายข้อมูลและเปิดใช้
ผลงานที่เกี่ยวข้อง
งานประจำ
ดูแลสิ่งที่ใช้อยู่
เซิร์ฟเวอร์ ฐานข้อมูล และแพลตฟอร์มที่ทีมลูกค้าต้องใช้ทำงาน
งานปรับปรุง
ปรับสิ่งที่ต้องเปลี่ยน
งานแก้ไขและเปลี่ยนเทคโนโลยีที่เกิดขึ้นในแต่ละช่วงของโครงการ
ความต่อเนื่อง
ส่งต่อให้ดูแลได้
ขอบเขตงาน คนรับผิดชอบ และข้อมูลที่ทีมต้องใช้ในการรับช่วง
ดูแลโครงสร้างพื้นฐานและแพลตฟอร์มเนื้อหาหลายเว็บ ควบคู่กับงานบำรุงรักษาและปรับปรุงระบบเดิม
อ่านประสบการณ์งานดูแลแพลตฟอร์มเนื้อหา →
* ชื่อลูกค้าและตัวเลขสัญญา ถูกตัดออกจาก public site ตาม security/discretion policy ของเรา
แนวทางก่อนเริ่มโครงการ
Legacy System คืออะไร และทำไมองค์กรไทยถึงอัปเกรดไม่ได้สักที
Legacy system ไม่ได้แปลว่าแค่ "ระบบเก่า" แต่คือระบบที่กลายเป็นภาระทางธุรกิจ บทความนี้อธิบายนิยาม สัญญาณเตือน สาเหตุที่อัปเกรดไม่ได้ และแนวทาง modernization สำหรับองค์กรไทย
เว็บไซต์องค์กรหรือร้านค้ามีปัญหา ? ให้ UnixDev ดูแลและแก้ไขทุกปัญหาให้คุณ!
บริการดูแลเว็บบริษัท เว็บขายของ และเว็บชุมชนที่มีปัญหาทางเทคนิค เช่น malware, spam, upgrade และ performance.