อัพเกรด vtiger CRM 7.1 สู่ 8.4 — จากระบบเก่า 10 ปี สู่ PHP รุ่นใหม่โดยไม่เสียข้อมูล

อัพเกรด vtiger CRM 7.1 สู่ 8.4 — จากระบบเก่า 10 ปี สู่ PHP รุ่นใหม่โดยไม่เสียข้อมูล

admin Article

บทความนี้เล่าประสบการณ์จริงของทีม 4 Xtreme ในการอัพเกรด vtiger CRM ของลูกค้าธุรกิจศูนย์เครื่องช่วยฟัง จากเวอร์ชัน 7.1 ที่ใช้งานมานานกว่า 8 ปี ข้ามผ่านทีละขั้นจนถึงเวอร์ชันล่าสุด 8.4 พร้อมข้อมูลจริงกว่า 34,000 Contacts และ 240,000+ Tickets โดยไม่เสียข้อมูลหรือระบบที่ลูกค้าปรับแต่งเอาไว้

ถ้าบริษัทของคุณใช้ vtiger เวอร์ชันเก่าอยู่ บทความนี้จะช่วยให้เห็นภาพว่าเส้นทางนี้เจออุปสรรคอะไรบ้าง และแต่ละจุดแก้อย่างไร

ทำไมต้องอัพเกรดทีละขั้น กระโดดทีเดียวไม่ได้หรือ

vtiger ไม่มีเส้นทางอัพเกรดข้ามเวอร์ชัน — migration ออกแบบให้ไล่ทีละขั้นเท่านั้น เพราะแต่ละเวอร์ชันมีการเปลี่ยนโครงสร้าง database และตัว migration script เองถูกเขียนให้คาดหวังเวอร์ชันก่อนหน้าอยู่ตลอด เส้นทางของเราจึงเป็น:

7.1 → 7.2 → 7.3 → 7.4 → 7.5 → 8.0 → 8.1 → 8.2 → 8.3 → 8.4

กว่า 9 ขั้นตอน เราสร้าง Docker staging แยกแต่ละขั้น (แต่ละขั้นใช้ PHP เวอร์ชันที่เหมาะกับ vtiger ตัวนั้น) แล้วไล่ migrate + ตรวจสอบข้อมูลทีละขั้น ไม่แตะต้องระบบจริงเลยจนกว่าปลายทางจะผ่านการทดสอบ — วิธีนี้ทำให้ลูกค้าใช้ระบบเดิมต่อได้ปกติระหว่างที่เราอัพเกรด

อุปสรรคที่เจอ และวิธีแก้

1. PHP รุ่นใหม่ไม่เข้ากับโค้ดเก่า

อุปสรรคใหญ่ที่สุดของงานอัพเกรด vtiger ไม่ใช่ข้อมูล แต่คือ ความเข้ากันได้ของ PHP — โค้ด vtiger 7.x เขียนไว้สมัย PHP 5.6/7.0 เมื่อข้ามไปใช้ PHP 8.x เจอปัญหาหลายรูปแบบ:

  • Syntax ที่ถูกตัดทิ้ง — เช่น เครื่องหมายปีกกาสำหรับเข้าถึงตัวอักษรในสตริง ที่ PHP 8 ไม่รองรับแล้ว → library เก่าบางตัวเรียกใช้แล้วระบบล่มทันที
  • พฤติกรรมของ mysqli ที่เปลี่ยนไป — PHP 8.1 เข้มงวดเรื่องการใช้ database result ที่ถูกปิดไปแล้ว ระบบเดิมมี config เก่าค้างอยู่ทำให้เปิด debug mode ของ database library ซึ่งไป free result ซ้ำ → หน้าเว็บแสดงผลว่างเปล่าโดยไม่มี error ให้เห็น ต้องไล่หาจาก code ลงไปถึงระดับ database driver
  • Function signature ที่ไม่ตรง — custom module เดิมประกาศ method ไม่เข้ากับ parent class ของ vtiger 8 → ต้องแก้ signature ให้เข้ากัน

บทเรียนสำคัญ: หน้าเว็บที่ขึ้น 200 แต่เนื้อหาว่างเปล่า ไม่ได้แปลว่าผ่าน — ต้องทดสอบ render จริงทุกขั้น ไม่ใช่แค่ดู HTTP status

2. ฐานข้อมูลขนาดใหญ่มาก

Export ข้อมูล production ออกมาได้ราว 700MB ตอน import เข้า MariaDB ล้มกลางทางเพราะขนาด packet เกินค่า default — แก้ด้วยการปรับ max_allowed_packet ใน database container แล้ว import ใหม่ จุดนี้เจอได้ทั่วไปในระบบที่เก็บข้อมูลมาหลายปี

3. Permission files หายหลัง migrate

หลัง migrate แต่ละขั้น vtiger ต้องสร้างไฟล์สิทธิ์ผู้ใช้ (privilege files) ใหม่ — ถ้าไม่ได้สร้าง user จะเข้าหน้าเว็บไม่ได้ทั้งที่ login ผ่าน เราต้องเรียก recalculate sharing rules หลังทุกขั้น migration เป็นขั้นตอนประจำ

4. Extension เชิงพาณิชย์ตามไม่ทัน — เคส PDFMaker

ลูกค้าใช้ PDFMaker Pro สร้างเอกสารใบรับซ่อมหลายสิบแบบ ปัญหาคือ license หมดอายุตั้งแต่ปี 2020 และ vendor ไม่มีไฟล์ดาวน์โหลดให้โดยไม่มี subscription — ร้ายกว่านั้น migration ของ vtiger 8.x ยังติดตั้ง PDFMaker รุ่นฟรีทับตัว Pro เดิม ซึ่งรุ่นฟรีจำกัดเฉพาะ inventory modules ใช้กับโมดูล HelpDesk ของลูกค้าไม่ได้เลย

ทางออกที่เราเลือก: แทนที่ library สร้าง PDF ตัวเก่า (mPDF 5.x ที่ไม่เข้ากับ PHP 8) ด้วย mPDF รุ่นใหม่ พร้อมปรับโค้ดให้เลือก template ตามที่ผู้ใช้เลือก และแกะวิธีที่ระบบเดิมจัดการ margin/header/footer มาทำให้เหมือนเดิม — ผลคือ template ทั้ง 16 ใบของ HelpDesk ออก PDF ได้ครบ ภาษาไทยและโลโก้ถูกต้อง เทียบกับของเดิมแทบไม่ต่าง

ข้อควรระวัง: template ของ PDFMaker อยู่ใน database — ข้อมูลย้ายมาครบ แต่ตัว render เป็นคนละเรื่อง ต้องทดสอบเปิด PDF จริงทีละใบ ไม่ใช่แค่เห็นว่ามี template อยู่

 

ผลลัพธ์

  • vtiger 8.4.0 รันบน PHP 8.3 ได้เต็มรูปแบบ
  • Contacts 34,300 / Tickets 243,207 / Workflows 31 ชุด / PDF Templates 50 ใบ — ครบทุกอย่าง
  • Custom modules เดิม (Servicecase, Attendance, Clientdata) และ label ที่เปลี่ยนชื่อเองยังอยู่
  • เอกสาร PDF ใบรับซ่อมพิมพ์ได้เหมือนเดิม
  • ทุกขั้นตอนมี runbook บันทึกวิธีทำ + จุดที่เคยพังไว้ ทำซ้ำได้ทุกขั้น

บทเรียนสำหรับองค์กรที่จะอัพเกรด vtiger เวอร์ชันเก่า

  1. อย่าแตะระบบจริงโดยตรง — สร้าง staging แยกทีละขั้น เพราะแต่ละขั้นมีความเสี่ยงของตัวเอง
  2. อัพเกรดทีละเวอร์ชันเท่านั้น — ไม่มีทางลัด
  3. ทดสอบของจริงทุกขั้น — ทั้ง record count, หน้า detail view, workflow, custom module ไม่ใช่แค่เห็นหน้า login
  4. เตรียมแผนสำหรับ extension ที่ซื้อมา — license/ไฟล์ติดตั้งเวอร์ชันใหม่เป็นเรื่องที่ต้องเคลียร์ก่อน go-live ไม่ใช่งานเทคนิคที่แก้ใน migration ได้
  5. งบเวลาส่วนใหญ่ไปกับ debugging ความเข้ากันได้ของ PHP มากกว่าการย้ายข้อมูลเสียอีก

ถ้าองค์กรของคุณใช้ vtiger CRM เวอร์ชันเก่าและกังวลเรื่องความปลอดภัยหรือการย้ายระบบ ทีม 4 Xtreme รับให้คำปรึกษาและดำเนินการอัพเกรดโดยรักษาข้อมูลและระบบเดิมครบถ้วน ติดต่อเราเพื่อประเมินแผนงานสำหรับระบบของคุณได้เลยครับ