≡

In this post, we set out our intentions for rolling out the recently announced Zimbra 8.8 release onto our shared Zimbra hosting platform.

Zimbra 8.8 was made Generally Available to the public on 13th December 2017 – see this post for more details. The 8.8 release marks a huge undertaking from Synacor to bring Zimbra Collaboration Suite up to date. A massive amount of work has gone into it, including:

  • Refactored code (meaning that third party developers can checkout the ZCS source code from Github and build a development install of Zimbra in just an hour or so);
  • Major backend (platform) enhancements which put in place some of the building blocks for future high availability releases;
  • Integration of the tried and tested Zextras modules for enhanced collaboration such as a new version of Zimbra Mobile which now supports shared contacts and calendars, Zimbra Chat and ‘dropbox’ like file syncing using Nextcloud.

There are a lot of changes.

Update June 2018

Since this post went live in December, we’ve been carefully monitoring the quality and performance of Zimbra 8.8. We successfully upgraded our test environment which mimics our production environment as closely as possible. Naturally we’ve done lots of testing too. We’ve also participated in many detailed technical discussions about Zimbra 8.8 stability and best practices for migration with the Zimbra open source community, Zimbra staff and other Zimbra hosting partners, during the weekly Zeta Alliance community phone call. As well as a number of incremental updates to Zimbra since the December release, Zimbra recently released version 8.8.8 which contains further improvements and enhancements including Zimbra Talk v2. This is the version we’ve decided to move forward with. Overall we’re really pleased with the progress Zimbra has been making, even though there is plenty more work still to do.

Zimbra 8.8.8 Migration – Phase 1 Date

We will be upgrading Zimbra Proxy, LDAP and MTA servers on Sunday 1st July 2018 during the following maintenance window. Although we will be performing some mailbox maintenance during this window, we will not be upgrading any mailbox servers to 8.8.8 and therefore none of the 8.8.8 features will be available and users should not experience any changes to Zimbra after this phase of the upgrade. This is the first phase of our Zimbra 8.8.8 migration.

Please subscribe to our new status page to keep up to date with all maintenance announcements

Once we’ve finished this migration, we’ll be building new Zimbra 8.8.8 mailbox servers and we’ll also be replacing each of the upgraded Proxy, LDAP and MTA servers with new builds. This work should be transparent and non user impacting as all of the servers are already redundant. Once we’ve completed all of this work, we’ll be ready to migrate mailboxes.

Zimbra 8.8.8 Migration – Phase 2 Date

Date not yet scheduled – expected July 2018

During phase 2, we will be migrating existing mailboxes to Zimbra 8.8.8 mailbox servers. We will publish more details of what to expect during and after the migration.

Our Approach to Zimbra Upgrades

Our primary concern is the stability and integrity of our shared Zimbra hosting platform.

Zimbra does not support 100% ‘always on’ mailboxes – that feature is coming in a future version of Zimbra. Despite that fact, for more than 11 years, we’ve successfully maintained a very high level of reliability and data integrity with very little interruption of service for our many thousands of users around the world. We feel that our cautious approach is key to our success in this regard.

Upgrading an email system which is in constant use is very challenging because once the upgrade is complete and new emails start flowing to the upgraded system, it’s very difficult to roll back to the previous version. So, before we commit to an upgrade, we need to be as sure as is practical that any new version of Zimbra is tried, tested and free of critical bugs which could cause interruption of service or loss of data. Then, once we’ve planned an upgrade, we take a number of steps to safeguard mailbox data which gives us the option to be able to back out of the upgrade at the last minute. None the less, we do prefer to give new releases plenty of time to ‘bake in’ out in the real world and for this reason, we never install the latest major releases of Zimbra until we’re satisfied.

In this particular case, we know that there’s been a lot of change to the source code. We’re extremely optimistic that the changes are very high quality – read why. None the less, we are especially cautious this time around. To arrive at a final upgrade date, here’s what we will be up to:

  • We have been beta testing Zimbra 8.8 since the summer of 2017 and now that we have a released version, we’ll carry out more extensive and real world testing on our multi-server test platform which mimics as closely as possible our production Zimbra installation. This includes putting the test platform under as much stress as possible to simulate the production system.
  • We stay in close contact with Zimbra support and we’ll closely monitor feedback from the community.
  • As part of our commitment to the Zeta Alliance we participate in a weekly call where we and other partners share updates and technical information.

The Zimbra 8.8 Migration

As well as being generally cautious about upgrading to new versions of Zimbra, in the case of Zimbra 8.8 we are keen to adopt a migration instead of an upgrade. As mentioned above in “Our Approach to Zimbra Upgrades”, our shared Zimbra hosting platform has been running since 2006 and has undergone quite a number of upgrades. Each time an upgrade happens, the old system is upgraded ‘in place’. This time, we would prefer to build a fresh Zimbra 8.8 platform and migrate mailboxes over so that we start completely afresh.

In an ideal world, we would build the new platform, test with our own mailboxes, then migrate those of you who want to be early adopters one by one. Sadly, at the current time, this won’t be possible because we cannot currently operate two separate platforms using the same host name (incoming server name). Most users have many devices configured with the incoming server name and so a wholesale name change, at the same time as a major upgrade, would be a recipe for disaster, not to mention a real hassle for you and your users.

We’re working with Zimbra to see whether they can create a modification to Zimbra to allow two platforms to co-exist under the same host name. We’re also evaluating other migration methods. Once we have arrived at the final solution, we’ll share the plans here.

 

Posted on December 14th, 2017  and last modified on October 23rd, 2024.