Hey all, I've got to move everything out of my current data centre as quickly as possible as the provider is shutting it down. Last time I did this I did it, from what I can recall, in a very manual kind of way. This time I'm tempted to buy the migration tool and let it do the hard work, but a few things make me slightly hesitant: The requirement to have the same LetsEncrypt binaries on source and destination servers. As Certbot has been a bit of a headache over the years I'd like to get away from it and was happy to see that new installs now use acme.sh instead, which so far has proved a lot more reliable (but I suppose only time will really tell). Is there any way to work around this requirement? e.g. Perform the migration and then manually configure LetsEncrypt certs after the move. It'd be a pain, but I could just stay up one night reissuing certificates. I really don't want to have to reinstall ISPConfig on the destination server to get around this limitation, it's taken a long time to get this far! I suspect my existing ISPConfig database is a little bit messy. This installation was originally created well over 10 years ago, originally on ISPConfig 2, or maybe even before that. It's been migrated across a number of servers since then and I've found some oddities in the database (e.g. some older users cannot log in unless I manually change a couple of things in the user tables for them). Is that likely to cause the Migration Tool issues? I was hoping this migration could be a clean start for our ISPConfig network. The biggest worry I have, which is literally keeping me awake at night, is migrating the email server: 80+ domains, 100+ mailboxes, 200+ mail forwarders, hundreds of DKIM keys … manually recreating all of that and syncing the data from old server to new in a single night simply isn't going to be possible. Manually merging database data from old to new server sounds like a recipe for disaster. I think the migration tool is the only way to go here, but again the old server's on Certbot and I'd want the new server on acme.sh. But here there would only be one or two certs to regenerate so it wouldn't be a huge problem if the migration occurred without SSL certs being moved. Is that feasible? Also, with this being live user data, I can't have the mail server go down for the duration of the migration of the 0.5TB of emails that will need copying. Is there a way to migrate stuff without stopping the source server from doing its job, rsync the contents of /var/vmail/…, leave everything half-migrated for the duration of the next working day after the rsync is finished, and then switch the DNS over out of hours with one last rsync to pick up the last 24 hour of emails and push them over to the new server? That's basically what I did (manually) when I last migrated my ISPConfig mail server and it worked well. My aim is for my customers to finish work one evening and then get in the next evening, not knowing that anything has happened in spite of the fact that their emails are now on a completely different server. I've also got DNS running on the mail server, but the goal is to move that elsewhere as part of the migration. Is that possible? Most of the old servers are on very old Ubuntu (16.04), whereas the new servers are on 24.04. Is that going to be a problem? It's not clear from the Migration Tool's notes just how automated it is. The problem is I need something that does the hard work of getting the ISPConfig databases in order and ensuring the filesystem data agrees with what ISPConfig expects, but without taking away the control I have over how things currently work. Downtime during working hours, sadly, isn't an option: I need to be able to plan when things go down for out of hours! Any advice greatly appreciated.
Also, > You need to have postfix with courier or dovecot as mail server on the SOURCE server. That's only if migrating mail, right? I don't need to have a mail server installed on my web servers in order to migrate them, do I?
Tell Migration tool to skip migrating certificates, then create new certificates on the TARGET server with ISPConfig. I did it this way, except I forgot to skip the migrating certificates part, which caused a bit of extra work. If Migration toolkit supports Ubuntu 16.04 it should not be a problem. I think you should set up a test target system and see how the migration goes. If Migration tool does not complain of anything, it should be able to migrate the data so it is OK and works properly on the TARGET system. Running migration tool does not stop the SOURCE system from working, so you can practice however much you want. If you move the DNS to somewhere outside ISPConfig, migration tool does not help you. But tell Migration tool to skip DNS, that way you have TARGET system without DNS and can setup DNS somewhere else. On the other hand, if you just want DNS but not on mail server, create on TARGET system as multiserver system, with two hosts running only DNS. Then migrate DNS data to those name server hosts.
