Zimbra 8.8.15/9 หมดซัพพอร์ต: เช็กลิสต์อัปเกรดเป็น 10.1 สำหรับองค์กร

การอัปเกรด Zimbra เป็น 10.1 คือการย้าย Zimbra Collaboration Suite (ZCS) จากรุ่น 8.8.15, 9.0 หรือ 10.0 ที่ผู้ผลิตหยุดออกแพตช์แล้ว ไปยังสาย 10.1 (Daffodil) ซึ่งมี General Support ถึง 31 ธันวาคม 2027 งานหลักไม่ใช่การรันตัวติดตั้ง แต่คือการเตรียม license key แบบใหม่ วางแผนเรื่องข้อมูลโมดูล NG ตรวจระบบปฏิบัติการ และวางแผน rollback ให้พร้อมก่อนวันจริง

บทความนี้เขียนสำหรับผู้ดูแลระบบอีเมลและ IT Manager ที่ใช้ Zimbra อยู่แล้ว และต้องวางแผนว่าจะอัปเกรดอย่างไร เริ่มจากสถานะซัพพอร์ตของแต่ละรุ่น ความต่างของ edition สิ่งที่ต้องเตรียม การเลือกระหว่างอัปเกรดในเครื่องเดิมกับย้ายเครื่องใหม่ และสัญญาณว่าควรพิจารณาย้ายไประบบอื่น ข้อมูลผลิตภัณฑ์อ้างอิงเอกสารของ Zimbra ณ วันที่ 1 พฤศจิกายน 2026

Zimbra รุ่นไหนยังได้รับซัพพอร์ต และ 8.8.15 หมดเมื่อไร?

ณ 1 พฤศจิกายน 2026 สายเดียวที่ยังได้รับแพตช์คือ 10.1.x ส่วน 8.8.15 สิ้นสุด Technical Guidance เมื่อ 31 ธันวาคม 2024, 9.0 เมื่อ 30 มิถุนายน 2025 และ 10.0 เมื่อ 31 ธันวาคม 2025 ตามหน้า Product Lifecycle และ Zimbra Releases wiki

General Support กับ Technical Guidance ต่างกันอย่างไร?

ตามนโยบายของ Zimbra ช่วง General Support ยาวสามปีนับจากวัน GA ของ major release ครอบคลุม bug fix แพตช์ความปลอดภัย และ technical support ส่วนช่วง Technical Guidance ผู้ผลิตระบุว่าไม่มี release ใหม่ ไม่มี bug fix และไม่มีแพตช์ความปลอดภัย เหลือเพียง technical support และช่องทางช่วยเหลือตัวเอง เช่น forum, Bugzilla และ wiki ระยะ General Support สามปีแบบเป็นทางการเริ่มใช้ตั้งแต่ Daffodil (v10)

ผลในทางปฏิบัติมีสองข้อ ข้อแรก รุ่นที่อยู่ในช่วง Technical Guidance ก็ไม่ได้แพตช์แล้ว จึงไม่ควรนับว่า "ยังซัพพอร์ต" ข้อสอง หลังอัปเกรดเป็น 10.1 แล้ว ควรวางรอบอัปเกรดครั้งถัดไปไว้ก่อนสิ้นสุด General Support ในวันที่ 31 ธันวาคม 2027

อีกเรื่องที่มักสับสนคือชื่อ Daffodil ซึ่งเป็นชื่อสาย release ของ 10.x ไม่ใช่ชื่อ edition ในตาราง lifecycle แถว "Zimbra Daffodil (v10.1.x)" ระบุว่ารวมรุ่น 10.x ในอนาคตด้วย ถ้ายังใช้รุ่นที่หมดซัพพอร์ตและต้องใช้เวลาวางแผน ให้ลดความเสี่ยงระหว่างนี้ตามแนวทางใน ดูแลระบบเก่าให้ทำงานต่ออย่างปลอดภัย

Zimbra Open Source กับ Standard และ Professional ต่างกันอย่างไร?

สำหรับ Zimbra 10.x ผู้ผลิตขายสอง edition คือ Standard และ Professional และ หน้าเทียบรุ่น ระบุว่าต้องมีไลเซนส์จึงใช้ Daffodil (v10) ได้ ตารางนั้นไม่มี Open Source Edition (OSE) ส่วนรุ่น open source ที่หลายองค์กรเคยติดตั้งฟรีคือสาย 8.8.15 ซึ่งพ้นระยะ Technical Guidance แล้ว

• 8.8.15: FAQ ของ Zimbra ปี 2020 ระบุว่า 8.8.15 ยังเป็น open source
• 9.0: FAQ เดียวกันระบุว่า binary ของ Zimbra 9 มีให้เฉพาะผู้ถือไลเซนส์ Network Edition และไม่มี binary แบบ FOSS ส่วน Modern UI ใช้ไลเซนส์เชิงพาณิชย์
• 10.x: repository Zimbra/zm-build มีวิธี build 10.1.0 และแพตช์ของ 10.0.x แบบ FOSS แต่ หน้าดาวน์โหลด มีเฉพาะ build แบบ Network Edition พร้อม trial license

แปลว่าซอร์สโค้ดยังเปิด แต่ผู้ใช้ต้อง build เอง มีผู้ให้บริการภายนอกบางรายที่ build binary จากซอร์สที่เผยแพร่ แต่ผู้ผลิตไม่ได้ประกาศ lifecycle สำหรับ build แบบ FOSS และ build เหล่านี้ไม่อยู่ในซัพพอร์ตของผู้ผลิต ถ้าเลือกทางนี้ องค์กรต้องรับผิดชอบการ build การทดสอบ และการติดตามแพตช์ความปลอดภัยเอง ซึ่งเป็นต้นทุนของทีมที่ควรนับรวมตอนเทียบกับค่าไลเซนส์

วิธีเลือก edition ที่ตรงที่สุดคือดูจากการใช้งานจริงของระบบเดิม ถ้าผู้ใช้ซิงก์มือถือผ่าน ActiveSync ใช้ Outlook บน Windows ผ่าน ZCO หรือองค์กรต้องเก็บอีเมลเพื่อการตรวจสอบ ฟีเจอร์เหล่านี้อยู่ในรุ่น Professional ตามตารางเทียบรุ่น ส่วนผู้ใช้ Outlook for Mac ต้องใช้ EWS ซึ่งซื้อเพิ่ม

ต้องเตรียมอะไรก่อนอัปเกรดเป็น Zimbra 10.1?

ต้องเตรียมหกเรื่องตามหัวข้อย่อยด้านล่าง ได้แก่ (1) สำรวจระบบเดิม (2) license key ใหม่ (3) ข้อมูลโมดูล NG (4) แชท (5) ระบบปฏิบัติการและพื้นที่ดิสก์ (6) backup และ staging รายการทั้งหมดสรุปจาก Upgrade Guide ของ Zimbra 10 และเอกสารที่เกี่ยวข้อง ซึ่งระบุว่าใช้กับ 10.0 และ 10.1.0 ก่อนลงมือควรอ่าน release notes ของ build ปลายทางประกอบด้วย

1. สำรวจระบบเดิม

• รุ่นและแพตช์ที่ใช้อยู่ (ตรวจได้ด้วย zmcontrol -v) ถ้ายังไม่อยู่บนแพตช์ล่าสุดของรุ่นนั้น ให้ลงแพตช์ล่าสุดก่อน เพราะการย้ายข้อมูลโมดูล NG รองรับเฉพาะ 8.8.15 และ 9.0.0 ที่อยู่บนแพตช์ล่าสุด
• เป็นเซิร์ฟเวอร์เดี่ยวหรือหลายเครื่อง แต่ละเครื่องทำหน้าที่อะไร (LDAP, MTA, Proxy, mailstore)
• โมดูล NG ที่เปิดใช้ และปริมาณข้อมูลของแต่ละโมดูล
• ระบบที่เชื่อมอยู่ เช่น LDAP หรือ Active Directory ภายนอก SAML หรือ SPNEGO แอปที่ส่งอีเมลผ่าน SMTP relay และอุปกรณ์ scan-to-email
• ไคลเอนต์ที่ผู้ใช้ใช้จริง: webmail, Outlook ผ่าน ZCO (รุ่นไหน) และมือถือผ่าน ActiveSync

2. ขอ license key ของ 10.1 ก่อนเริ่ม

• ตาม release notes ของ 10.1.0 รุ่นนี้เปลี่ยนมาใช้ License Daemon Service (LDS) กับ license key แบบตัวอักษรและตัวเลขแทนไฟล์ไลเซนส์ .xml แบบเดิม และระบุว่าไม่สามารถอัปเกรดต่อได้ถ้าไม่มี key ใหม่
• LDS ต้องติดตั้งบนเครื่องที่ออกอินเทอร์เน็ตได้ (Proxy หรือ MTA) ถ้าเครือข่ายออกอินเทอร์เน็ตไม่ได้ มีแพ็กเกจ zimbra-nalpeiron-offline-daemon สำหรับ activate แบบ offline ซึ่งควรทดสอบให้เรียบร้อยก่อนวันอัปเกรด
• ส่วนที่ว่าด้วย Zimbra Chat ใน Admin Guide ระบุว่าลูกค้าที่อยู่บน 8.8.15, 9.0.x หรือ 10.0.x ต้องย้ายไลเซนส์ v2 เป็น v3 ก่อนอัปเกรด ควรยืนยันขั้นตอนนี้กับผู้ขายไลเซนส์

3. โมดูล NG: วางแผนย้ายข้อมูล ไม่เช่นนั้นข้อมูลจะถูกลบ

Zimbra 10 ถอดโมดูล Zextras/NG ได้แก่ HSM, Backup, Mobile, ABQ, Drive, Docs, Auth, Connect และ Admin รวมถึง IMAPD ออก ถ้ายังมีโมดูลเหล่านี้ติดตั้งอยู่ ตัวติดตั้งจะเตือนว่าแพ็กเกจของโมดูล NG และข้อมูลที่เกี่ยวข้องจะถูกลบ จึงต้องวางแผนตาม เอกสาร NG migration ซึ่งรองรับเฉพาะระบบ 8.8.15 หรือ 9.0.0 ที่อยู่บนแพตช์ล่าสุดและใช้แนวทาง rolling upgrade เท่านั้น ขั้นตอนคืออัปเกรดเครื่อง LDAP, Proxy และ MTA เป็น 10 แล้วติดตั้ง mailbox server รุ่น 10 เครื่องใหม่ จากนั้นย้ายบัญชีและข้อมูลโมดูล NG จาก mailbox เดิม (ห้ามอัปเกรด mailbox เดิม) ส่วนระบบเครื่องเดียวที่ใช้โมดูล NG เอกสารระบุว่ายังไม่รองรับการย้าย ต้องปรึกษา Zimbra Support หรือผู้ขายก่อนวางแผน

ถ้าผู้ใช้เก็บข้อมูลสำคัญไว้ใน Connect ต้องตกลงกับเจ้าของข้อมูลก่อนว่าจะ export หรือยอมรับให้ข้อมูลส่วนนี้ไม่ตามมา

4. แชท: Zimbra Talk ย้ายไป Zimbra Chat ไม่ได้

• Zimbra Chat ซึ่งมาแทน Talk ใช้ได้กับ Daffodil 10.1.7 ขึ้นไป (Classic UI ตั้งแต่ 10.1.8)
• ต้องติดตั้งบนเซิร์ฟเวอร์แยกที่ใช้ร่วมกับ ZCS ไม่ได้ และรองรับเฉพาะ Ubuntu 22 และ 24
• เป็นแชทอย่างเดียว ไม่มีวิดีโอในตัว เอกสารกล่าวถึงการเชื่อมกับระบบวิดีโอแบบ open source
• Basic Chat ใช้ฟรี Advanced Chat ซื้อเพิ่ม ลูกค้าที่มีสิทธิ์ Zimbra Talk ได้ Advanced Chat ตามจำนวนบัญชี Talk เดิมจนถึงวันสิ้นสุดซัพพอร์ตของสัญญา Talk
• ไม่รองรับการย้ายข้อมูลจาก Zimbra Talk หรือบริการแชทและวิดีโอแบบ hosted
• ตาม release notes ของ 10.1.0 ตั้งแต่รุ่นนี้ แชท (และวิดีโอผ่านระบบที่เชื่อมต่อ) รองรับเฉพาะแบบติดตั้งภายในองค์กร ไม่มีแบบ hosted

ประวัติแชทเดิมจึงไม่ตามมา ควรแจ้งผู้ใช้ล่วงหน้าและกำหนดว่าจะเก็บข้อมูลเดิมไว้อย่างไร

5. ระบบปฏิบัติการ เครื่อง และพื้นที่ดิสก์

• ระบบปฏิบัติการ: หน้าดาวน์โหลดของ 10.1 มี build สำหรับ RHEL, Rocky Linux และ Oracle Linux 8 และ 9 และ Ubuntu 18.04, 20.04, 22.04 และ 24.04 (x86-64) โดย Ubuntu 24.04 รองรับเต็มรูปแบบตั้งแต่ 10.1.17 ส่วน RHEL, CentOS และ Oracle Linux 7 ถูกระบุว่า deprecated และ release notes ของ 10.1.21 ระบุว่า Ubuntu 18.04 จะเลิกรองรับตั้งแต่รุ่นถัดไป
• RAM และดิสก์: ตาม Single Server Installation Guide เซิร์ฟเวอร์เดี่ยวต้องมี RAM อย่างน้อย 8 GB พื้นที่สำหรับซอฟต์แวร์และ log 100 GB สำหรับ production (ไม่รวมพื้นที่ mailbox) และใช้ไฟล์ซิสเต็ม XFS, ext3 หรือ ext4
• พื้นที่ว่างก่อนอัปเกรด: ตัวติดตั้งจะหยุดถ้าพื้นที่ไม่พอ ตรวจให้เรียบร้อยก่อนเข้า maintenance window
• Package repository: ระบบปฏิบัติการต้องลงแพตช์แล้ว และเข้าถึง package server ของ Zimbra ผ่าน yum หรือ apt ได้ ถ้าใช้ RHEL ให้ติดตั้ง pax หรือ spax บนเครื่อง MTA ตามเอกสาร

6. Backup และ staging

• backup ของผู้ใช้ทุกคนที่ทดสอบกู้คืนแล้ว และถ้าเป็นเครื่อง virtual ให้ทำ snapshot ไว้ก่อนอัปเกรดด้วย
• ตรวจฐานข้อมูลด้วย zmdbintegrityreport ก่อนอัปเกรด (เอกสารระบุเป็นขั้นตอนเสริม)
• สำรองการปรับแต่ง SAML และ SPNEGO ไว้ เพราะการอัปเกรดจะเขียนทับ
• ซ้อมอัปเกรดบน staging ก่อน production ซึ่ง Zimbra แนะนำไว้ในบทความ What's New in 10.1.21 จุดที่ควรทดสอบเป็นพิเศษมีสามจุด:
  • LDAP/AD ภายนอก: 10.1.21 อัปเกรดเป็น OpenJDK 17.0.19 และปิด cipher suite แบบ TLS_RSA รุ่นเก่าเป็นค่าเริ่มต้น เซิร์ฟเวอร์ LDAP หรือ AD ที่รองรับแต่ cipher เก่าอาจยืนยันตัวตนไม่ผ่าน
  • S/MIME: ผู้ใช้ S/MIME ต้องอัปโหลดใบรับรองใหม่หลังอัปเกรดเป็น 10.1.21
  • Outlook: ตารางความเข้ากันได้ใน Admin Guide ระบุว่า ZCO รองรับ Classic Outlook 2021, 2024 และ 365 บน Windows 10 และ 11 ส่วน Outlook 2016 และ 2019 ถูก deprecate ตั้งแต่ตุลาคม 2025 (ประกาศครั้งแรกใน release notes ของ 10.1.10)

อัปเกรดในเครื่องเดิมหรือย้ายไปเครื่องใหม่?

ถ้าระบบปฏิบัติการของเครื่องเดิมยังอยู่ในรายการที่ 10.1 รองรับ การอัปเกรดในเครื่องเดิมมักง่ายที่สุด ถ้าเครื่องเดิมยังใช้ RHEL/CentOS 7 หรือ Ubuntu 18.04 หรือฮาร์ดแวร์ใกล้หมดอายุ การติดตั้ง 10.1 บนเครื่องใหม่แล้วย้ายข้อมูลมักคุ้มกว่า เพราะได้เปลี่ยนระบบปฏิบัติการพร้อมกัน และเก็บเครื่องเดิมไว้ถอยกลับได้ Upgrade Guide ของ Zimbra รองรับทั้งการอัปเกรดเซิร์ฟเวอร์เดี่ยว หลายเครื่อง และแบบ rolling upgrade

ระบบที่ยังมีโมดูล NG: เอกสารของ Zimbra สองฉบับยังให้ข้อมูลไม่ตรงกัน ตารางใน Upgrade Guide ระบุว่าการอัปเกรดในเครื่องเดิมพร้อมโมดูล NG รองรับแบบมีเงื่อนไข แต่เอกสาร NG migration ระบุว่ายังไม่รองรับการอัปเกรดในเครื่องเดิมทั้งแบบเครื่องเดียวและหลายเครื่อง และรองรับเฉพาะ rolling upgrade ให้ยึดเอกสาร NG migration เป็นหลัก คือใช้ rolling upgrade ไปยัง mailbox server ใหม่ ส่วนระบบเครื่องเดียวที่มีโมดูล NG ยังไม่มีเส้นทางที่ผู้ผลิตรองรับ ต้องปรึกษา Zimbra Support หรือผู้ขายก่อน

ลำดับงานที่เราแนะนำ

1. สำรวจระบบเดิมตามหัวข้อก่อนหน้า กำหนดเกณฑ์ผ่าน และเงื่อนไขที่จะ rollback
2. ลงแพตช์ล่าสุดของรุ่นที่ใช้อยู่
3. ขอ license key ของ 10.1 และทดสอบการ activate (รวมถึงแบบ offline ถ้าเครือข่ายปิด)
4. สร้าง staging จากสำเนาระบบจริง แล้วซ้อมตามเส้นทางที่จะใช้จริง รวมถึงการย้ายข้อมูลโมดูล NG ถ้ามี จากนั้นทดสอบ LDAP/AD, SAML, webmail, Outlook และมือถือ
5. ทำ backup และ snapshot ของระบบจริง แล้วทดสอบกู้คืน
6. แจ้งผู้ใช้และกำหนด maintenance window จากเวลาที่วัดได้ตอนซ้อม
7. ลงมือบนระบบจริง: ถ้าไม่มีโมดูล NG ให้อัปเกรดเครื่องเดิมหรือ cutover ไปเครื่องใหม่ ถ้ามีโมดูล NG ให้อัปเกรด LDAP, Proxy และ MTA ติดตั้ง mailbox server รุ่น 10 ใหม่ แล้วย้ายบัญชีและข้อมูลตามเอกสาร NG migration
8. ตรวจหลังอัปเกรด: รับส่งอีเมลทั้งขาเข้าและขาออก webmail, Outlook, มือถือ, งาน backup และสถานะไลเซนส์
9. ติดตาม release notes ของ 10.1.x และลงแพตช์ตามรอบ

ต้องหยุดระบบนานแค่ไหน?

ผู้ผลิตไม่ได้ให้ตัวเลขกลาง และเราไม่แนะนำให้ใช้ตัวเลขจากระบบอื่น ระยะเวลาขึ้นกับขนาด mailbox และข้อมูลรวม จำนวนเซิร์ฟเวอร์ วิธีอัปเกรด (ในเครื่องเดิม rolling หรือย้ายเครื่องใหม่) ปริมาณข้อมูลโมดูล NG ที่ต้องย้าย และเวลาตรวจหลังอัปเกรด ตัวเลขที่ใช้วางแผนได้จริงมาจากการซ้อมบน staging ที่มีข้อมูลขนาดใกล้เคียงของจริง

เมื่อไรควรย้ายไประบบอื่นแทนการอัปเกรด?

ถ้าเหตุผลเดียวคือ "ระบบเดิมหมดซัพพอร์ต" การอัปเกรดเป็น 10.1 แก้ปัญหานี้ได้และมักเปลี่ยนน้อยกว่า แต่ควรเทียบกับการย้ายระบบเมื่อมีสัญญาณเหล่านี้:

• เคยใช้รุ่น open source แบบฟรี และไม่ต้องการทั้งค่าไลเซนส์และภาระ build เอง
• ฟีเจอร์ที่ผู้ใช้ต้องใช้ เช่น ActiveSync, ZCO และ archive ทำให้ต้องใช้รุ่น Professional พร้อมส่วนเสริม ซึ่งควรเทียบต้นทุนรวมกับทางเลือกอื่น
• ทีมดูแลถนัด Windows Server มากกว่า Linux หรืออยากได้บริการ Cloud ที่ผู้ผลิตดูแลให้
• ใช้ Zimbra Connect หรือ Zimbra Talk อย่างหนัก ซึ่งต้องเปลี่ยนเครื่องมือแชทอยู่แล้วไม่ว่าจะเลือกทางไหน

การเทียบ Zimbra กับทางเลือกอย่าง IceWarp และขั้นตอนย้ายอีเมลแบบมี pilot, delta sync และ rollback อยู่ในบทความ Zimbra vs IceWarp: อัปเกรดต่อหรือย้ายระบบดี (เปิดเผยข้อมูล: UNIXDEV อยู่ในไดเรกทอรีพาร์ทเนอร์ของ IceWarp ในฐานะ Certified business partner ในประเทศไทย)

เช็กลิสต์ก่อนวันอัปเกรด

• รุ่นและแพตช์: ระบบเดิมอยู่บนแพตช์ล่าสุดของรุ่นนั้น และรู้ build ปลายทางของ 10.1
• ไลเซนส์: มี key ของ 10.1 แล้ว LDS ติดตั้งบนเครื่องที่ออกอินเทอร์เน็ตได้ หรือทดสอบ activate แบบ offline แล้ว และตั้งเตือนวันต่ออายุ
• Edition: ฟีเจอร์ที่ผู้ใช้ใช้จริงอยู่ใน Standard หรือ Professional และต้องซื้อส่วนเสริมอะไร
• โมดูล NG: ระบบเข้าเงื่อนไข rolling upgrade ตามเอกสาร NG migration ซ้อมย้ายข้อมูลบน staging แล้ว และตกลงเรื่องข้อมูล Connect ที่ย้ายไม่ได้
• แชท: แผนสำหรับ Zimbra Chat บนเซิร์ฟเวอร์ Ubuntu แยก และแจ้งผู้ใช้ว่าประวัติ Talk ไม่ตามมา
• ระบบปฏิบัติการ: อยู่ในรายการที่รองรับ ไม่ใช่ RHEL/CentOS 7 หรือ Ubuntu 18.04 และมีพื้นที่ดิสก์พอ
• การเชื่อมต่อ: LDAP/AD, SAML, ZCO, มือถือ และ S/MIME ผ่านการทดสอบบน staging
• Backup และ rollback: backup ที่ทดสอบกู้คืนแล้ว snapshot และเงื่อนไขที่ชัดเจนว่าเมื่อไรจะถอยกลับ
• หลังอัปเกรด: ใครติดตาม release notes และลงแพตช์ 10.1.x ตามรอบ ระบุไว้ใน สัญญา MA ที่มีขอบเขตชัดเจน

UNIXDEV ประเมินรุ่นและสถาปัตยกรรม Zimbra ที่ใช้อยู่ วางแผนอัปเกรดเป็น 10.1 หรือย้ายระบบ ทดสอบ cutover และ rollback ร่วมกับทีมขององค์กร และดูแลต่อตามขอบเขต MA ที่ตกลงกัน ภายใต้บริการ Digital Workplace & Collaboration Platforms และ DevOps · SRE · Managed จุดเริ่มต้นที่แนะนำคือประเมินระบบปัจจุบันก่อน เพื่อให้รู้ว่างานอัปเกรดจริงมีอะไรบ้าง ส่งรุ่น แพตช์ จำนวนเครื่อง และโมดูล NG ที่ใช้อยู่ผ่านแบบฟอร์มส่งโจทย์ได้

แหล่งอ้างอิงและอ่านต่อ

• Zimbra — Product Lifecycle
• Zimbra Releases (wiki)
• Zimbra Daffodil 10.1.21 release notes
• Zimbra blog — What's New in Zimbra 10.1.21 (Daffodil)
• Zimbra Daffodil 10.1.17 release notes
• Zimbra Daffodil 10.1.10 release notes
• Zimbra Daffodil 10.1.0 release notes
• Zimbra — Edition comparison
• Zimbra — Download
• Zimbra blog — Is Zimbra open source? FAQs (2020)
• GitHub — Zimbra/zm-build
• Zimbra 10 Upgrade Guide
• Zimbra 10 NG Migration
• Zimbra 10 Administration Guide
• Zimbra 10 Single Server Installation Guide
• บทความที่เกี่ยวข้อง: Zimbra vs IceWarp
• บทความที่เกี่ยวข้อง: ดูแลระบบเก่าให้ทำงานต่ออย่างปลอดภัย
• บทความที่เกี่ยวข้อง: เช็กลิสต์สัญญา MA และ SLA
• บทความทั้งหมดในหมวด Digital Workplace

บทความโดย UNIXDEV Team · 1 พฤศจิกายน 2026 · ข้อมูลผลิตภัณฑ์อ้างอิงเอกสารของ Zimbra ณ วันที่เขียน (1 พฤศจิกายน 2026) ซึ่งอาจเปลี่ยนแปลงได้ ก่อนอัปเกรดควรตรวจ release notes ของ build ที่จะติดตั้ง