Migration strategies from 5.0 to 6.0

[BenG]

G'day All,
We are planning our migration from 5 to 6, and have read through all of the documentation etc, so are happy with doing a backup and performing an inplace upgrade.
However what does concern me is that if we find a major bug, say missing subfolders or backups are not robust for example. Something that takes a few hours/days/weeks to notice.
We will have a situation where we can't roll back to 5 easily, because there will be a lot of email processed in the interim.
So ideally if we had a way to copy all inbound/outbound email into a "standby" queue, and effectively "replay" these back if we had to restore 5.0.
The process would look something like this(We use VMware):
Shutdown server
Do complete backup of the VM.
Disable the NIC to stop network traffic.
Start the VM.
Configure the standby Queues. (perhaps postfix always_bcc?)
Re-enable the NIC.
Send a few test emails and verify they go into the standby queues.
Run a full zm backup
Perform the upgrade.
Sit back and wait for the accolades from users.......yeah I know I am dreaming here....
Then in the unlikely event of a major issue.
Roll back the zm backup, (or copy the queues and then restore the full VM.)
Copy the contents of the standby queues back into the inbound queue.
Let 5.0 reprocess the mail.

Now having just thought this through, that is only going to work for inbound emails, and not for outbound.... sigh.

So, does anyone have a solution for this?

Cheers Ben

[sereose]

I'm faced with the same problem .
Trying to migrate my zimbra 5.x to totally new server with zimbra 6.0
Does any one have a well documented How-to of a Migration process from 5.0 to 6.0.
Please share it here.

[mlcdigital]

I've been trying procedure after procedure to move from Debian4-Zimbra5 to Debian5-Zimbra6.
If you're not working in a VM environment then I'd suggest using a program like Acronis to backup the system to an image file and then restore that image file on another computer to test your procedures and make sure all services/features work before breaking a live environment.

These steps are straight forward to not only upgrade Zimbra but Debian. If all you are trying to do is upgrade Zimbra you can stop after step 3 and verify the install.
Upgrade path from Zimbra 5 on Debian 4 to Zimbra 6 on Debian 5 | Nothing here. Move along.

Once I upgrade from Debian4-Zimbra5 to Debian4-Zimbra6 the CPUs spike, IMAP/CalDAV aren't accessible, and in the admin interface some of the queue and stats don't load correctly.

zimbra@mailserver:~$ zmcontrol status
Host mailserver.domain.tld
antispam Running
antivirus Running
imapproxy Running
ldap Running
logger Running
mailbox Running
memcached Running
mta Running
snmp Running
spell Running
stats Running

Hopefully you have better luck...

[BenG]

G'day,

We managed to upgrade from 5.21-6.03 fine.
The server was running under ESX, so we backed up,blocked smtp ect took a snapshot and ran the upgrade with no real major issues.
Couple of minor ones re modifications to postfix etc I think, but certainly nothing big.
Under Ubuntu 804 LTS. No plans to uprade the OS.

We chose to do it on a Saturday night, yeah no life, so that our clients would be less likely to be impacted, and then hoped that no major issues arose.
It still worries me that we don't have a way to reliably "replay" it if something happened that took a while to manifest itself.

Rgds Ben

[gubolo]

I have big problem when upgrade from 5.0.18 to 6.0.5.
It makes lost any users, aliases, and distribution lists.
Does anyone can help me with this?

[ArcaneMagus]

From the sounds of it you didn't upgrade, but rather re-installed. During setup it would have detected your current install and asked you if you wanted to upgrade. If you answered no at this point it would have wiped all user data and created a fresh install.