Clients locate servers using the signature of the specific server instance, and contact the server and ask it to prove its identity. Ideally they do both these jobs in a single multicast packet they send out, although if your network is not multicast-capable then it takes longer, but both steps are important.
The clients know the identity of the server they are bound to based on the PUBKEY.CRT file stored in the client; the server they are bound to has a corresponding file called PRIVKEY.CRT containing a hidden secret key corresponding to the public key.
As the backups created by the scripts are simple .CAB format archives, you can open them up in Windows and inspect their contents; the PRIVKEY.CRT file is there, along with the console's database and another piece of secret data, the passwords for the console database which are also randomly generated at server install time, and which are normally kept in an encrypted section of the machine registry so they can't be seen by anything except the NGSERVER.EXE service which contains the management server proper.
will my clients automatically bind to the new server?
They can; whether they will immediately is a little complex to explain. Once clients have discovered a server at a specific IP address they do tend to stick with trying to use that address; however, if for any reason they lose contact with a server they will fall back to searching for their bound server more generally, to attempt to discover it at a different IP addesss in case it has moved or network conditions have changed.
As long as the new server has the right PRIVKEY.CRT file then the clients should bind to it, but they won't necessarily contact the new server until "nudged" to do so by the old server becoming unavailable, even if only temporarily (which I'll explain more below).
If i do this do i need to disable my old Ghost console immediatly?
Nothing will go permanently wrong if you leave the old server active; however, clients which are currently active and communicating with the old server will continue talking to it as long as it's running, and whenever a client machine is searching for a server, if there are two servers with the same PRIVKEY.CRT then the client's won't know which to prefer - this can disrupt active task execution, so it's not a normal state of affairs, but as soon as there's only one server around everything should be fine again.
So, one good practice is this: once you have restore the console state in the new location, stop the NGSERVER.EXE service from the Services control panel applet on the original server - in the SERVICES.MSC MMC snap-in, the service contained in the NGSERVER.EXE executable is titled "Symantec Ghost Configuration Server". Stopping the service temporarily disables the management system, but it's still easy to re-enable it just by restarting the service - during this time you can validate that the new server is working, and can still re-enable the original if things aren't working as they should be.
Without the NGSERVER.EXE service running, the management clients over a timeframe of a few minutes detect it becoming unavailable and will be searching for it, at which point they should detect the new instance; at this time you can verify on the new server instance that the clients can and are detecting it correctly, and if they are then you know you can safely remove the old server instance permanently.