Best Practice to migrate existing Message/Central Instance to new hardware?

I've done some searching for this, but it all seems to be fairly old (I found one decent thread from 2008, but it just seemed outdated).  I would like to get some updated info & suggestions on a process to follow for this task.
Here is some info about the current config:
I have an existing SAP ERP 6.0 EHP5 system.  SID "XYZ"
Everything is currently running on Windows x64.
ABAP only config.
It is currently setup as a distributed system.
DB server is SQL, which is running on its own hardware as a dedicated DB server.  I don't need to touch this.
Uses logon groups to distribute the load between 3 App servers.
One of the App Servers is setup as the Message/CI server. This is what I am wanting to move to VM hardware.
The other two App Servers are setup just as Dialog Instances.  VM already.  I don't need to touch these.
What I am wanting to do:
I am wanting to migrate the existing Message/CI server to VM hardware to get the current Message/CI system off of very old hardware.
I need to keep the system with the same name & IP.
I do not need/want to mess with the DB server at all. 
Need to minimize downtime as much as possible.
I do NOT want to go to an HA environment.  That is a different project for the future.
Suggestions? I would like to hear what some of you have done.
Minimize downtime?  I have a short maintenance window of a few hours coming up in the next few months, and would like to do this changeover during that downtime.
How do I handle setting this up on the new hardware using the same name & IP, especially with the existing system still running.
What I think I need to do: (Some of these may be out of order, which is why I'm asking for suggestions)
Setup new Windows VM server, named differently than current Message/CI server (Done already).
Run SAPINST to run Global Host Preparation on the new Windows VM server.
Run SAPINST to setup ASCS Instance on the new Windows VM server.
Skip the Database Instance installation, since I already have one running.
Run SAPINST to setup Central Instance on the new Windows VM server.
Copy all of the appropriate profile parameters that were on the old server.
Start SAP and make sure everything is running and working correctly.
Copy all job, spool files, etc. from the old server.
What needs to be done in between those steps for the server rename & IP changes?
Which of these steps can I do in advance of my maintenance downtime window, without it affecting the currently running system?
I have a test environment that I am going to test this with.  I'm just trying to get a jump start on my instructions, so that I can hopefully do this quickly and easily.  I'm very comfortable doing the installs.  Just needing some guidance on how to handle this case.
I'm open to suggestions, and any links you can send my way that show some more recent success at doing this.  Everything I keep finding talks about doing the migration for the DB.  I am not migrating my DB.  It is staying where it is.  I'm just wanting to migrate my Message/Central Instance to a VM, without affecting the users, and hopefully them never noticing the changes.

If you're using VMWare, there is a tool provided to virtualize existing systems.  Basically it makes a copy of the old system (while it is down) and recreates it as a VM with the same name, IP, etc.  I haven't double-checked to see if this process is 'officially' supported by SAP, and I don't know the technical details about how it's done or how long it will take (VMWare is managed by the Network Operations group in my team, so as the SAP sysadmin I'm basically a customer of theirs).  However, we have virtualized a few smaller systems that needed to get off failing hardware in a hurry and it worked very well, so I would expect it would for an SAP dialog instance as well.  As you're not copying a database, just the app server, it probably would fit within your maintenance window.
If this route works for you, then there is no need to actually install the SAP system on the VM instance... you just copy the old server as-is, then make any adjustments required due to no longer needing old drivers, etc, plus potentially having different memory parameters.