Hi, I've used the excellent ISP Config migration tool a few times now and it really is super brilliant. However on this occasion, I have migrated some 50 odd websites and their DB's to a new ISP Config 3.1.13 server but there is a real problem. There is only 1 client but all 50 websites are associated with this client. The target server has the WRONG client ID (4 instead of 5) so none of the sites work as the dir structuires, symlinks etc are all looking for client5 as they were on the source server. How can I change the client ID from '4' to '5' on the new 'target' server? This is a nightmare but hopefully an easy fix? Many thanks!
The client_id is not a fixed value, it can change when you migrate sites to another server as the client_id is an auto increment value of the MySQL database and MySQL chooses the next free value when inserting a new record, also client_id's might be in use on a new server already when you merge different systems. The Migration tool takes care that the sites and other records get attached to the right client, independent of the ID. The website symlinks (e.g the domain.tld symlink in /var/www ) in ISPConfig get set automatically to use the correct new ID as well. If you want to copy an ISPConfig server to a new server while keeping the exact ID's and paths for all assets, then the ISPCopy program (which is part of the migration Toolkit as well) might be the better choice. And the result when using the Migration Tool instead of ISPCopy depends also on the migration tool version that you use, the new Migration Tool 2.x tries to keep ID's when possible and overrides the MySQL defaults while the old 1.x tool did not had such a function. To help you with your issue in detail, please contact the Migration Tool support here: https://www.ispconfig.org/get-support/?type=migration
Thanks till, I sent a ticket in to the Migration Tool Support guys and they were very quick to respond. They have advised that I can't change the ID but I should manually change all the client4 dirs/symlinks to client5. Should be able to do this easily enough with a bit of bash. I now know the reason why the target server had the wrong ID. Originally I started the migration from an SSH terminal on my laptop. As it was going to take a long time and I needed to take my laptop home soon after, I cancelled the migration then started it again in a screen session (so the migration would continue after I closed my laptop to take home with me). It looks like the 2nd time I ran the migration, because the ID was already taken from the 1st attempt and therefore already used, it used ID 5 instead!
