At the request of mmorse in this thread Great job zimbra, I'm posting here about my recent experiences in an emergency migration off of hsphere for email hosting. We had about 500+ mail accounts and 78 domains.
In our situation the hsphere server that had housed the mail components had completely crashed. There was no backup really to go to, and we needed to migrate to zimbra anyway. Fortunately the Control Panel (cp server) didnt crash. It turns out that hsphere stores account information in a postgres database on the cp server. We found that we could access the postgres database directly on the cp server from commandline. We had to find the password to the database, and some googling showed that the password is stored in clear text in this file:
It stores the mailbox information in 3 tables. One for regular Mailboxes, One for aliases and one for forwards. The Mailbox database even has the user passwords in it stored in clear text. After dumping each of those databases, I imported them into excel so that I could use some excel concatenation commands to create the commands needed by 'zmprov' to import the users into zimbra. You could probably do this with other tools, I just used what I was already familar with.
Hsphere deals with aliases and forwards differently than zimbra, so those had to be handled specifically. Neither one of these really stores the full email address in association with the record. For aliases we didn't have very many, so I did those by hand in Zimbra. For forwards we had 100+ but we weren't sure what the full email address was of the account they were associated with was. Someone had to go in and manually check each domain to figure that out, although I bet a script could be written to compare the username with a list of usernames and then return the domain name to give you the full email address for the associated forward. Once we had documented the full email address, again it was a matter of using excel to create the zmprov commands to add the forward email commands to the zimbra database. I ended up using a command like the following for each forward:
zmprov ca email@example.com ptcf0rward displayName will description Forward-Account zimbraPrefMailForwardingAddress firstname.lastname@example.org zimbraPrefMailLocalDeliveryDisabled TRUE
This created the account, sets a password, sets the forward and then turns off local email storage for the account. I batched these using the zmprov batch method detailed in the zimbra documentation.
Once I had the accounts setup it was a matter of swapping the IP address on the server to be the same as the old hsphere mail server. While not optimal for various reasons, it was by far the easiest way to do it.
We never really allowed customers to auto-configure their own hsphere stuff, we always managed it for them. We never used many of the hsphere features and had even disabled stuff like quotas. The other components of hsphere are going to have to be migrated seperately, DNS, webhosting, etc. Again in this case our support staff did all the DNS changes, so going to a centrally administrated DNS solution will work fine. We did only some webhosting, but they'll be happy with a apache virtual setup. I've yet to do these steps but they are next. If we were using hsphere the way it was meant to be used, I might have gone a different route, and tried to maintain a system which would tie everything together in one admin console.
- All mailbox data was lost. This caused some pain I'm sure, but it sure simplified the migration process.
- zimbra doesn't do pop before smtp like hsphere did. We had to switch all the users that use us as the SMTP server to SMTP Auth and SMTP SSL. It was painful for a few days while we fielded the calls, but in the end it's a better and more secure configuration anyway.
- Need to register a commercial SSL cert so that Outlook won't complain. Working on that now.
- Need to migrate DNS and Webhosting separately. In progress.