migrating mail accounts from cPanel to DA using rsync?

Hello,
i'm moving a domain from cPanel (CentOS 7, Dovecot v2.3.13) to DirectAdmin (CentOS 8, Dovecot v2.3.15), there are very few email accounts, but each account is immense (over 60GB).
i'll start off with my concern, and work backwards..
My main concern is that my client's email software (all Apple) will re-download all the emails if the UIDs are not preserved in the transfer..

i was going to use imapsync, but my understanding is that it cannot preserve UIDs because Dovecot itself manages them.

sooooo...
my idea is this:
Since both servers use Dovecot 2.3.x..
create all the same email accounts on the new server, using the same addresses and credentials..
and then just use rsync to overwrite the contents of each account on the new server in <domain>/mail/<domain>/<each_user>

once rsync is done, switch the DNS over to the new server and none is the wiser..

any thoughts are greatly appreciated!!
Thank you!
 
I'm pretty sure we've tried various methods of this and nothing was ever able to be performed as seamless as what we had wanted it too.

In both situations, regardless of how it was done -- I believe the mail client downloaded emails regardless simply because the method cPanel handles Dovecot and the way DirectAdmin handles Dovecot is just distinctly different.

Whereas cPanel dovecot has files that index where everything is and that doesn't get carried over to DirectAdmin, so.. your mileage may vary.

While I do believe your idea would work, I believe that any IMAP sync connection may still try to re-download all of the emails.

The worst instance we had with this was around 3TB of email. The other issue being that DirectAdmin Dovecot doesn't utilize hardlinks like what cPanel Dovecot does.

So if email accounts 1-5 have the same email, cPanel hardlinks to conserve space so those 5 accounts don't all have the same 10mb email -- whereas DirectAdmin shows as 50mb since there's no hardlinking

However, I wouldn't hold my breath and I would plan for the worst when dealing with such transitions.
 
Thank you so much for your reply!
i have a little time until the migration, so i might do some tests..
But from what you say about the hardlink and the index issues, i might just play it safe and use imapsync..
Thank you so much!!
 
Hello, sorry for reviving an old thread, but i need to ask your advice on something very much related to this..

i did the above migration, from cPanel to DA, with imapsync, using the following commands at the end:
--addheader --delete2

everything worked fine, except for one thing:
the Sent, Draft and Trash folders were no longer seen by Apple Mail on the new server; they had been transferred just fine, but Apple Mail went ahead and created all new Sent, Draft and Trash folders..
i had to remove the path 'INBOX' from the mail clients to be able to see the original folders..

The alternative was to completely remove the account from Apple Mail, and re-configure them..

There must be some sort of identifier that Apple Mail uses, aside from just their name, to verify that these special IMAP folders are the same, and this identifier must not have been copied along to the new server..

i'm not sure i'm explaining myself correctly, i hope i am..

Basically, my question is:
Have you encountered this issue before, and is there a way to ensure that the special folders (Sent, Draft, Junk, Trash) are recognized correctly by Apple Mail after a transfer from cPanel to DA?

Thank you so much for all your help!
 
Sorry for monologuing here, but i think i just figured out why my imapsync migration got all messed up!
in DirectAdmin, Dovecot is configured as follows, in /etc/dovecot/conf/namespace_private.conf or /usr/local/directadmin/custombuild/configure/dovecot/conf/namespace_private.conf
Code:
namespace inbox {
    type = private
    separator = .
    prefix =
    inbox = yes

Whereas, in cPanel, you'll find Dovecot configured with:
Code:
prefix = INBOX.

i'm pretty sure this is what caused all of my client's mailboxes to get all messed up..
 
So, i'm sorry i keep reviving this thread, but i can now confirm that the issue and fix described in the previous post solved it!
first, copied
/usr/local/directadmin/custombuild/configure/dovecot/conf/namespace_private.conf
to
/usr/local/directadmin/custombuild/custom/dovecot/conf/namespace_private.conf
and edited the latter to change the 'prefix' setting to:
Code:
prefix = INBOX.

Then rebuild the Dovecot conf:
./build dovecot_conf
 
Top