SAP Migration to Windows Question

[Former Member]

We are in need of some technical direction in performing a SAP migration from UNIX to Windows. We are running SAP ECC 5.0 (ABAP only) on Sun Solaris UNIX with an Oracle 10g database. The UNIX database server contains both the SAP Central Instance and the Oracle database. Our production environment also contains three separate UNIX servers that contain secondary SAP ECC 5.0 Application Server Instances. We must move all of the SAP Instances, including the Central Instance, to new Windows servers. But, the Oracle 10g database will remain in its current location on the UNIX server and will not be migrated. This is not a straight forward migration since the database is not being moved. We cannot find any official SAP documentation that covers this particular situation.

As a side note, we will be performing a SAP upgrade from ECC 5.0 to ECC 6.0 in conjunction with the migration of our SAP instances. This can be viewed as two separate projects, but we must perform the downtime portion of both tasks during the same weekend. The ECC 6.0 upgrade will be performed using a u201CSystem Switch Upgradeu201D strategy (Downtime minimized) that utilizes a shadow instance and repository switch. Therefore, a large portion of the upgrade will be performed while the system is available during the week and then the downtime part will be performed on the weekend.

Does anyone have any recommendations on how best to approach migrating just the SAP instances from UNIX to Windows (keeping in mind that the database is not moving and we are also performing an upgrade to ECC 6.0 along with the migration)?

Here are some specific scenarios that we have been discussing:

Scenario 1 (New Installation of SAP Windows Instances pointing to Existing Oracle/UNIX database)

Shutdown all SAP instances on UNIX. Perform a new distributed SAP installation on Windows, but skip the database instance portion of the procedure. We would need to identify and manually perform any items (such as profile modifications and kernel extractions) that would have been performed during the database instance installation. How is the best way to identify the manual steps that we would need to perform (in place of running the database instance installation step)?

Scenario 2 (System Copy)

We cannot find a SAP procedure that covers the combination of performing a Heterogeneous System Copy with the Database-Specific method. The SAP System Copy guide only discusses Heterogeneous System Copy with the Database-Independent method. Is it possible to perform a System Copy for this particular situation without unloading/loading the database?

Also, we are wondering if it would be best to migrate the SAP Instances to Windows before or after the upgrade to ECC 6.0 (given the fact that both will need to be done on the same weekend)?

Thanks in advance for any thoughts and/or recommendations that can be provided.

[Former Member]

Hello,

Follow Note 1067221 - Composite note for heterogeneous installation.

and https://websmp208.sap-ag.de/osdbmigration

I suggest you to treat your two (migration & upgrade) activity separate.

cheers,

-Sunil

[Former Member]

Only one weekend? WOW thats too much stress :-).

Let's see, if you run prepare in Unix and then you go to move upgrade files and directories to Windows then nothing will work because in /usr/sap/put directory there are files that indicates the OS and DB versions, also contain paths and a lot more of things. Prepare will not only import to database, it will also look for environment problems, comunication problems, file version problems, etc so I don´t see how can you do that in Unix and then move it to Windows.

So, I would do upgrade and then migrate because you can begin downtime, complete upgrade and post upgrade then go to migration which should be faster (in case you already know how to do it without export/import the DB).

That will be an interesting project so keep posting here about the progress

Good Luck

[former_member204746]

you are changing too many things at the same time. if you get problems after go-live, you will have a hard time pinpointing the culprit.. will it be the migration of OS or the upgrade?

use a 2-weekend strategy. This is what I did, I converted from 32-bit to 64-bit, then, 2 weeks later, made the upgrade.

[Former Member]

I couldn´t agree more! doing things in a hurry always explode at some point.

To add to what Eric said, always during an upgrade you need to have time to go back to the original system because something can get very wrong and that takes time. In this case I don't see a gap for this kinds of problems and that is too much risk for my taste.

But if you will go ahead, just post here the experience.

[Former Member]

Hi,

My opinion is also to use 2 weekends.

It is much too dangerous to make this "big bang" all together.

It may even be impossible due to time constraints.

My only advice : practice several times on test systems which are database copies of the production system. And after that make the final decision.

Best Regards,

Olivier