Final confirmations before Migration Tool purchase

Discussion in 'Plugins/Modules/Addons' started by TonyG, Sep 3, 2022.

  1. TonyG

    TonyG Active Member

    I'm preparing for a migration of ISPConfig servers and would like some final confirmations.

    Master1 here is the current and only primary ISPConfig server. Master2 is the replacement for Master1, not a concurrent master system.
    Slave1 is the current and only secondary ISPConfig server. Slave2 will be the replacement for Slave1.

    1. Source systems are Ubuntu 20, target is also Ubuntu 20 because 22 isn't yet supported.
    2. Source systems have ISPConfig 3.2.2, targets will be the latest 3.2.8 with PHP7.4. Any issue expectd in this .2 to .8 jump?
    3. Migration Tool migrates all /var/www directories and permissions.
    4. What about Apache site config files? Any other configs under /etc/apache2?
    5. Migration Tool migrates all /var/vmail directories and permissions.
    6. For sites, mail, and DNS zones, is there one Migration Tool run per client? It would be convenient to use this again soon to migrate sites for specific client accounts to different systems.
    7. Are there issues specific to ISPConfig with a slave being disabled and not being migrated?
      1. The plan now is to not migrate Slave1 to a new Slave2, but to install a completely new Slave2... Slave1 is currently only a NS2/MX2 and does not have data to migrate.
    8. Is the following a reasonable plan to migrate mail services from Master1 to Master2?
      1. Master1 has the old v3.2.2 custom config settings. Master2 will have the new 3.2.3+ settings.
      2. The current plan is to install Master2 as a completely vanilla Postfix/Dovecot environment, do the migration which uses the new *_custom.conf.master files, and then manually migrate mail configs from Master1 into the new files in Master2.
        1. Get Master1 detail from postconf and doveconf.
        2. Diff that with the vanilla Master2.
        3. Copy all differences into custom.conf.master files - and verify as appropriate.
        4. Expectation: Master2 Postfix and Dovecot should work like Master1 because all mail changes will be in the new 99-ispconfig-custom-config.conf files.
      3. Given the way ISPConfig works and what the Migration Tool will do, is that missing any detail? I'm not positive that every Postfix/Dovecot setting gets a cascade override through the setting process, and that the 99-ispconfig file is the final override for all settings. If not then some details may still need to be in mail.cf or dovecot.conf or related files.

    If there are no issues recognized with the above, we'll purchase the Migration Tool and move forward quickly.

    Thanks!
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    The Migration Tool imports the email, website, and DNS data of an ISPConfig installation to another installation using ISPConfig remote API, this means the new ISPConfig server recreates all relevant config files based on its local settings and based on the newer that is installed on the new server. Custom config settings that you manually made are not migrated as they do not reside in ISPConfig and its database. See the Migration Tool page for details on the Migration Toolkit: https://www.ispconfig.org/add-ons/ispconfig-migration-tool/

    You can find the Migration Tool tutorial here, which also lists available command-line options to restrict which data gets migrated:

    https://www.howtoforge.com/tutorial...-confixx-plesk-to-ispconfig-31-single-server/

    The migration tool has a dry-run mode that does not require buying a license upfront, run it in dry-run mode and check the created migrate.log file afterward to see which data would get migrated with the command line options you have chosen. The dry-run mode neither alters the source nor the target server. And if you are not satisfied with the result that you find in the log, then don't buy a license.

    In a multiserver setup, the Migration Tool needs to be run on each system that shall get migrated, one after another, starting with the master. If you want to leave out a node because you don't need the services it provides anymore, that's ok.
     
    TonyG likes this.

Share This Page