If you're not concerned about moving policies over, I'd have thought the easiest way would be to push the client installation from new server and let it overwrite the existing, so the agent then knows it's being managed by a new server. When you right-click the agent (shield icon) in the systray and go to "about", does it have the old server name or the new one? Also, try issuing an Agent Wake-Up from the ePO console, and see if that updates your sitelist.xml.
I deployed the new agent to the managed server and actually watched the McAfee\Agent directory structure on the target server build out. That was a good sign. However, the sitelist.xml file was not updated but the server file was updated. The 'About' status from the shield icon does have the new server listed. Subsequently, since the sitelist.xml file was not updated, it is not communicating with the new server. I tried to initiate a wake up from the new ePO server and it just times out.
I accessed the 4.6.8 ePO that was managing this server and it too cannot initiate a wake (as expected). The end result after the new agent was deployed is that this server seems to be in limbo and not managed. The question is how do I get the sitelist.xml file updated from here?
Hmm, I would have expected the sitelist to update. Can you open the agent status monitor and do a "Collect and Send Props" and "Check New Policies"? If these fail, there should be some sort of indication as to why, which might help figure out why it's not working.
Alternatively, I presume this procedure is what you used for attempting the transfer?
One gotcha on that I found when transferring the database to a new server was that the SQL team moved the TCP port SQL was listening on from default on the new one; that gave me lots of problems. And when you're entering the credentials right, you've copy/pasted those credentials into a SQL Server Management Studio connection or PowerShell Invoke-SqlCmd to make sure you can connect using those credentials?
Well, after further poking around, I found that the OS Host Firewall was still enabled for Guest/Public on the new ePO server. This was the root cause of the older ePO server not being able to make a database connection from the 'Registered Servers' configuration AND also the reason the new Agent Deployment was not able to communicate back to the new ePO. DARN Firewall!!!! These two things were successfully tested once the Firewall setting was disabled on the new ePO.
Thanks for your support. And yes, I really believe the preferred method is the KB you sited above and now that I made that database connection I can go that route.