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

[Former Member]

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)

1. Setup new Windows VM server, named differently than current Message/CI server (Done already).
2. Run SAPINST to run Global Host Preparation on the new Windows VM server.
3. Run SAPINST to setup ASCS Instance on the new Windows VM server.
4. Skip the Database Instance installation, since I already have one running.
5. Run SAPINST to setup Central Instance on the new Windows VM server.
6. Copy all of the appropriate profile parameters that were on the old server.
7. Start SAP and make sure everything is running and working correctly.
8. 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.

Thanks!

[Former Member · Accepted solution]

Hi Butch,

Your planned steps are correct, but you need the complete downtime (Whole installation and configuration time) as the hostname and IP's are same. And you are working with live database so turn of the current Ci host. Otherwise it will conflict. I have done homogeneous system copy bot not like this scenario.

Thanks

Asad

[Former Member · Accepted solution]

Yeah, I have a feeling that a complete shutdown will be the only way to do it.  I have my test system setup and will play with it for the next few weeks to see how quickly I can do all of this.  The installs don't take that long when you don't have to do the DB setup. 

[Former Member]

this step below only works with freshly installed database from SAP install tool whether it is a fresh install or a sap system copy.

Run SAPINST to setup Central Instance on the new Windows VM server.

So it is not applicable for your scenario.

Basically this is a clone of old system with new hardware not an OS/DB migration. Imho, the OS copy method plus adjustment suggested by Matt is actually more applicable.

[Former Member]

Henry - Not sure I understand what you are saying.  I've just installed a CI pointing to an existing DB under my test environment.  Seemed to work fine.  It doesn't need to be a fresh installed DB.  Did you mean something different?

[Former Member]

You understood it correctly. In the past, I tried to do it but failed with some notices. Maybe I did it wrong and misunderstood.

I have tried it again just now. It seems you are correct. I did not meet any error other than it tried to access sap* user in client 066 which was locked in my system. It also did not update the newly created profile with database host name parameter.

My apologize, this step can be done actually regardless the database is freshly installed or a running one.

[Former Member]

Thanks for testing.  Nice to hear that it does work as I expected.

As for the profile missing the DB Host Name parameter, I haven't run into that with the test I ran this morning, but since I will be transferring the existing profile info over, that shouldn't be an issue for me hopefully.

I will continue testing from my end, and wait to see if anyone else has any input on my question.  I've got a little time before I need to proceed, so I am not in a huge rush at this point.

[Matt_Fraser]

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.

[Former Member]

Thanks Matt - We thought about doing the P2V conversion, but have heard that it is not officially supported by SAP, plus, when we tested it once with our Sandbox system, it took over 5 hours, so that was out of the question for minimizing downtime.

We are using vmware though.  We have been following their best practices for SAP systems.

EDIT:  Forgot to say that since we are not doing the P2V, we are also going to go ahead and install this to a 2008 OS.  Currently it is on 2003.  All of the other systems are already on 2008.  This was the only one we had left to get converted to 2008.

Message was edited by: Butch Handy