Transition from one server to another.

[deano-dovecot at areyes.com]

I've done this a couple of times, and there are a couple of things you 
can do to help make it go smoothly.  I did it not too long ago to move 
to a new single server, and am getting ready to do it again to a fully 
redundant setup (3 nodes for percona clustering, 2 of the nodes as 
dovecot with sync).

* Set your current MX records TTL to the lowest you can, usually 30 
minutes.  This will make it quicker to do the final transition when you 
do.
* Create an A record in DNS for the new server, but no MX records for it 
just yet.
* If you're using SPF, add your new server IP address to the TXT record.

Get your new server up and ready and *tested*.  Verify everything works. 
  Web access to roundcube/squirrelmail/whatever, imaps access from 
thunderbird/outlook/whatever and so on, sending mail from the new 
server.  The works.

Get bi-directional replication going between the two servers.  This 
doesn't have to be dovecot dsync, you can use offlineimap too.  
Whatever, get sync going.  The aim is to be sure that any changes on one 
server are synced to the other one.  Test it - use swaks to create mail 
on the new server, make sure it shows up cleanly on the old (that people 
are still using).

* NOW, add an MX record of higher (lower number) priority pointing to 
the new server.  Remove the MX record for the old server.

Point clients to the new server.  This can be done gradually, as mail 
will be replicated between the two systems.

All new mail should now be going to the new server, while some systems 
with cached DNS will still use the old one.  Any mail they deliver to 
the old server will replicate to the new one.  The cached MX records 
should expire fairly soon (remember the 30 minute TTL you set) but 
sometimes they don't for a while.

Wait a few hours.

* Disable inbound smtp on the old server.

Now any connections coming into the old will fail, and the source 
systems should spool the mail for retry later, delivering to the new 
server.  Clients can still use the old server, and even send mail from 
it.

Wait a day or so and watch the old server.  Pretty quickly you should 
see no more connections coming into it.  "tshark port 25 or port 587" is 
your friend here.

Finally decommission the old server once you have all clients moved over 
to the new server.

If anyone is interested, that redundant setup is part of an automated 
installer I've been working on.  You can set up a 3-node environment on 
cheap VPS', two 2gig ram nodes for the 
dovecot/exim4/roundcube/spamassassin/clamav and a 512meg ram one for the 
3rd Percona cluster DB node (to make a quorum).  Everything replicates 
via encrypted vpn, so you can point to either main node for roundcube or 
imaps.  Works fine in Amazon AWS too, though that's a little pricier 
than the cheap VPS providers.



On 2014-07-14 16:22, Anders Wegge Keller wrote:
> A frind of mine and I are running a dedicated server, that among
> other things host mail for ourselves and friends and families. All in
> all about 15 different domains with 35-40 users. The machine in
> question is old, so we are doing a slow transition from the old server
> to the new one. So far, we've managed to move web hosts
> seamlessly. Due to the technical capabilities at some of the user
> base, it would be nice to get to a setup, where we can move individual
> users imaps from the old server to the new one, as we get the time to
> visit them.
> 
>  I have an idea how such a transition could go:
> 
>  1. Upgrade the old dovecot 1.2.15 to 2.1.whateveritis from debian
>     squeeze backports.
> 
>  2. Set dsync up to replicate mails from the old server to the new
>     server. I know that 2.2 is recommended, but with a limited amount
>     of user, I'm willing to take a performance hit.
> 
>  3. Migrate my parents &c to use the new server.
> 
>  4. When all users have been moved on to using the new server, upgrade
>     MX records for the domain to point at the new server.
> 
>  5. When all MX records are updated, decalre success.
> 
> 
>  Is this feasible, and what would the risks be. For instance, during
> step 4, mails are bound to arrive at bothe the old and new server for
> some time. Will this cause problems?
> 
>  Is there a simpler solution to the problem?