Managed to run the dry-run. But what is it that dry run omits? It did produce the command script to be run on the target server, but log file shows lots of stuff missing that is normal for dry run. For example Code: [WARN] Could not resolve 300 to new web domain id. This is normal on dry runs Is that command script produced by dry-run OK to execute on the target server? Also, at one point migrate tells me Code: Be sure that the SOURCE has the domain module active and all domains in there! I am not sure I have domain module active. Is it the ISPConfig DNS tab? But that I think is always active and is there when ISPConfig get installed, which makes me assume this is about something else. jboud asked good questions in https://www.howtoforge.com/community/threads/ispconfig-migration-tool.75295/#post-354513 and got excellent answers. From that discussion I learned I can keep the source server running in production while trying out migration. The target server has different IP addresses now, but what are pros and cons in 1) keeping the ip addresses or 2) changing them to the addresses of the source after the successful migration? This is a multiserver setup, where I am migrating the old master to a new blank server. Does migration tool work this way, i.e. the slave servers appear after the migration in the target server?
These errors are ok for a dry run, they mus happen as the dry run does not import any data, so it can not resolve domains on the new server. The script is ok, but you can not execute it on the real server. You have to do a real migration run first! The domain module can be enabled and disabled under System > Interface > main config. It is not the DNS module. If you keep the new IP, then you will have to change the DNS records of your domains to the new IP. If you use the IP of the source server after migration, then you don't have to change dns. You have to run the migration tool on each node of the old multiserver setup, not just on the master. The migration tool connects to the remote API of the new master server and will show you a list of available nodes on the target system then so you can select to which node the data shall be imported.
Just a side-note. If the master itself does not contain any data like websites, databases etc. you do not have to run the migtool on that server but only on each slave to avoid duplicate entries.
There are websites and stuff on the master. Some websites are on a slave server. Are you saying migration tool makes duplicate entries when run in this situation? Seems strange, how could migration tool work at all in multiserver setups if that is the case?
No. He just said that you do not need to run the tool on the master in case that the master does not host any websites. But this dos not applies to you according to your comment.
