I'm moving forward with a migration and still need confirmation on a couple points. Thanks. MultiServer Sources ("-s") : Ubuntu 20, ISPC 3.2.2, primary-s/ns1-s/mx1-s + secondary-s/ns2-s/mx2-s MultiServer Targets ("-t") : Ubuntu 22, ISPC 3.2.11p2, primary-t/ns1-t/mx1-t + secondary-t/ns2-t/mx2-t All clients/websites currently on primary-s, moving to primary-t. Standard apps: Apache, Postfix, Dovecot, Bind9, MariaDB 10.3, Rspamd, PostGrey, ClamAV, Roundcube, Fail2Ban, Jailkit, UFW Not using XMPP, Mailman Intent: Install primary-t and secondary-t using Perfect Server MultiServer docs. Get that working like a completely new and independent environment. Use Migration Toolklit to pull in all data. Test individual services/sites. Change target hostnames and IP addresses after migration so that the new servers replace the old. Concern1: Postfix/Dovecot configs changed in ISPC 3.2+. I trust the migration tool will load from the 3.2.2 settings and restore into 3.2.11 settings. From here I believe I need to manually copy customizations from Postfix and Dovecot config.d files, and merge them into the new ISPConfig settings. Concern2: DNS and Rspamd configs between secondary-s and primary-s are unreliable. I would prefer to install secondary-t without moving in any configs from secondary-s. Can I do that? Or should I migrate to both primary-t and secondary-t, then replace the secondary-t after the migration? Concern3: After primary-t is configured in ISPConfig for website path, website symlinks, website auto-alias, etc, when data is migrated in, does it use those settings from the source or from the target? Are those settings replaced in primary-t by the Migration Toolkit? Thanks!
The Migration Tool is not copying over any config files. It uses the ISPConfig remote API to import things into the new systems and then copies over the data (database contents, emails, website data), so all config files get created based on the settings and config file templates of the new systems. And when you configured mirroring for something on source and target, then you migrate only the primary of the mirrored system as the same mirroring will happen on the targets as well automatically (if the target systems are configured correctly before you start the migration). And always use dry-run mode first, as mentioned in migration guide, to check what gets migrated.