Current File : //proc/thread-self/root/usr/share/doc/imapsync/FAQ.d/FAQ.Migration_Plan.txt
#!/bin/cat
$Id: FAQ.Migration_Plan.txt,v 1.9 2021/12/19 10:00:32 gilles Exp gilles $
This document is also available online at
https://imapsync.lamiral.info/FAQ.d/
https://imapsync.lamiral.info/FAQ.d/FAQ.Migration_Plan.txt
=====================================================================
Imapsync. Suggestions for a good, low impact on users,
well-executed email migration plan.
=====================================================================
There are two main different scenarios. Choosing which one fits your
context depends on the response to the following question:
Will the imap software tools used by the users use the same
credentials triplet for both imap servers, the old server host1 and
the new server host2?
The credentials triplet is hostname/username/password.
If the answer is yes, ie, clients' email tools use the same triplet
credentials, then it is possible to perform a migration without
changing anything on the users' side. This may be a very time-saving
option. But it's a rare condition so I'll describe this scenario later
in this document.
=====================================================================
Classical scenario, credentials triplets are different on both sides
=====================================================================
* Decrease the TTL of the MX, to 5 minutes (or even less). See
FAQ.TTL.txt to understand why it's an advantage. If you can't
decrease the TTL, the migration will span a little more but that's
ok, the situation is not that bad.
* Create the new mailboxes on the destination server host2. If the
users are already playing with the new mailboxes on host2, don't
follow this scenario.
* Pre-synchronize all the mailboxes from the old server host1 to the
new server host2. If an imap server name is going to change its IP
address, then don't use this name, use a name that will always
match the same imap servers, or use their IP addresses.
Pre-synchronizations can usefully be done with --delete2 to get an
exact synchronization. But never use the option --delete2 once the
users have started to play with their new account on host2, their
play will be lost on the next synchronization. Don't use --delete2
either when the MX is changed since INBOX will start to receive new
messages that are not on host1 and then removing them is not a good
idea.
* Decide a migration day/hour.
* Repeat the pre-synchronizations (with the --delete2 options) daily
until the migration hour. This repeated process will show how long
should take the last synchronization.
* At the migration hour, cut access to the users to the old server
host1, if you can. Or tell them to not use it anymore.
* Do the last pre-synchronization exactly like the previous ones.
* Change the MX, the new messages should start to arrive in the new
imap server host2.
* Wait for the TTL value, aka 5 minutes. Now, new messages should
not arrive at the old server host1.
* Tell the users that the old imap server host1 is down and no
longer available.
* Do a post-synchronization. A post-synchronization is a run with the
following options: --folder INBOX --delete1 --maxage 1
This post-synchronization will copy the messages arrived in the
last day (--maxage 1) in the folder INBOX (--folder INBOX) on the
source account, to the destination account. It will also delete
them on host1 (--delete1). It's --delete1, it's not --delete2.
Remember, do not use the option --delete2 in a post
synchronization, as users won't appreciate seeing their newly
arrived messages disappear because of you.
* Give access to new accounts to the users with their new credential
triplet hostname/username/password. If the way to contact users is
by email then you should give them the new credentials long before
shutting down the old server.
* Migration done.
* In case there are still messages arriving at the old imap server
host1, you can perform more post-synchronizations, ie, runs every
day with the options: --maxage 1 --delete1 --folder INBOX
* Increase the TTL of the MX back to its previous value, usually
24 hours, 86400 seconds. You don't want all your email system
to break down completely when your DNS are not available
temporarily, keeping dns values in cache for a 24h is a savvy
practice.
=====================================================================
Lucky scenario, credentials triplets are the same on both sides
=====================================================================
* Decrease the TTL of the MX, as well as the imap hostname resolution,
to 5 minutes (or even less). The document FAQ.TTL.txt explains why.
* Create the new mailboxes on the destination server host2.
* Pre-synchronize all the mailboxes from the old host1 to the new
server host2, using different names than the ones used by the imap
software clients (use their IP for example). Presyncs have to be
done with --delete2 but never use --delete2 once users have started
playing with their new account on host2.
* Decide a migration day/hour.
* Repeat the pre-synchronizations (the runs with the --delete2
options) daily until the migration hour. This repeated process will
show how long should take the last sync.
* At the migration hour, cut access to the users to the old server.
You can do this by changing the imap host1 hostname to a non-imap
server for example, or by changing their password on host1.
* Do the last run exactly like the pre-synchronizations.
* Change also the MX resolution, the new messages should start
to arrive in the new imap server very soon.
* Wait for the TTL value, aka 5 minutes. Now, new messages should
not arrive at the old server host1.
* Do a post-synchronization. A post-synchronization is a run with the
following options: --folder INBOX --delete1 --maxage 1
This post-synchronization will copy the messages arrived in the
last day (--maxage 1) in the folder INBOX (--folder INBOX) on the
source account, to the destination account. It will also delete
them on host1 (--delete1). It's --delete1, it's not --delete2.
Remember, do not use the option --delete2 in a post
synchronization, as users won't appreciate seeing their newly
arrived messages disappear because of you.
* Shut down the old imap server.
* Change the user imap hostname resolution from the old IP of host1
to the IP of the new imap server host2.
* Migration done.
* Increase the TTL of the MX back to its previous value, usually
24 hours, 86400 seconds. You don't want all your email system
to break down completely when your DNS are not available
temporarily, keeping dns values in cache for a 24h is a savvy
practice.
=======================================================================
=======================================================================
Mini Shell