When imaging a computer to speed up the process and avoid prompts but also prevent duplicate names on the network, you will typically configure your image to pull out some unique identifier from the hardware and use that as part of the hostname. This could be the system serial number or the MAC address of the on board network controller (highly unlikely to change without a new motherboard) or something else like that.
The trouble with moving a hard drive that has been imaged this way is that it doesn't magically adopt the unique attributes from the new system, and if you reimage the old system with another drive, there is now an "evil" twin on the network, which causes no end of fun and frivolity when suddenly one becomes untrusted and you can't log into any AD accounts from it.
The solution is that immediately after moving the drive to a new computer, you should login, then unjoin the domain (requires domain admin permissions) so you can rename and rejoin once you know what unique identifier you will use in the new machine. If for some reason that isn't possible you should open a root session in Terminal sudo su - and keep it open and work in another window to detect whether you suddenly can't use sudo or do other things with your regular user account while making these changes. You will need to delete the /etc/krb5.keytab and then change the hostname sudo hostname new-hostname and update the /etc/hosts and /etc/hostname files, as well as the /etc/sssd/sssd.conf and /etc/krb5.conf and most other places (see NOTE below) that the old hostname exists. There are some other files like ~/.ICEauthority that will need removed before rebooting as well, because they contain the old hostname and applications that use it will be able to resolve the system name that was cached. Note that deleting the ~/.ICEauthority file may trigger a crash, so it is best to leave it until right before you initiate a restart.
NOTE: It may be tempting to be clever and try to use sed or grep to do a "Find-replace-all" to "fix" all occurrences of the old name across your disk, DO NOT DO THIS!!!!!. If you examine the output of a grep -ir oldname /etc you will see that if you are using LVM (logical volume manager) to manage the partitions on your disk, it defaults to naming the volumes oldname--vg-<partname> and changing this name will prevent your system from booting. These volumes are only used locally, and they are tracked in the /etc/fstab as well, so you can either try changing the fstab file to use a UUID instead, or you can just leave well enough alone and don't alter these files, if it is really that big of a deal you might be better off reimaging the system completely after backing up, as backing up and restoring files is probably less error prone, and if you mess up your fstab, you'll be doing a LiveUSB/LiveCD recovery anyways, and the recommended first step for those is BACK UP YOUR DATA.
If you use Google Chrome as your primary browser and it crashes or exits abnormally (due to spontaneous reboot mentiong above), when launched if it has any dangling locks it will prompt you whether you want to remove the locks and resume the session, this should be fairly safe if you intentionally changed the hostname.