Database Migration --> MaxDB to Oracle

[Former Member]

Hello,

We are planning to migrate our XI 7.0 server from MaxDB to Oracle...

I am currently reading the System Copy Documentation from SAP...

Has anyone done MaxDb --> Oracle Heterogenous Copy....

Any Input, Guidelines & Strategies will be appreciated...

Thanks,

RaHuL...

[markus_doehr2]

First start reading

http://service.sap.com/osdbmigration

--> FAQ

You'll see there, that you need to have a certified migration consultant on-site to do the migration.

If you use the latest tools (R3load, R3szchk etc.) and the correct options to load the database the migration itself should be smooth.

Markus

[Former Member]

Hi,

Thanks a lot for the answer...

I have been through that document...

Also previously i have done DB Migration from Informix --> Oracle but that was for R/3 4.6B [ Kernel 4.6D] so we used R3load and made lot of manual changes during the procedure i.e Unsorted Unload, Splitting Packages, Splitting Tables [ Informix ]...

Now we are migrating Xi 7.0 & MaxDB to Oracle.. I think we will have to use sapinst --> system copy

Can we still do manual changes or will those be given as option in the procedure itself

Thanks,

RaHuL...

[markus_doehr2]

> Can we still do manual changes or will those be given as option in the procedure itself

If you use the migration monitor manually then you can (and should) do changes, yes.

There are quite a few options for R3load, exporting and importing.

Markus

[brian_walker]

I'd like to clear up something I see in these forums quite often about performing a system migration.

If you read carefully the information at http://service.sap.com/osdbmigration you will see that you will not loose support for the migrated system if you choose not to use a certified migration consultant, even for a production system. For production you are required to have SAP perform the os/db migration check, but this is a free service just like going-live checks.

For clarification, I even opened an OSS message and worked with our SAP support rep. The only thing you may "loose" support for is for any issues encountered during the migration itself or any performance issues encountered after the migration that are clearly related to the migration or improper sizing. You can still open OSS messages and if SAP deems the problem related to not having a migration consultant then you still have the option to pay SAP support to continue to help with the problem.

We moved several different landscapes from DB2 z/OS to SQLServer last year and did not use a migration consultant for any of them. We still have support for our SAP systems. We did have a thorough migration plan and tested in sandboxes many times well before we started the moves of even the development systems. We did also have SAP perform the required migration check on the production systems. We also found an instance or two of a bug with the migration tools, opened and OSS message about it, and got fixes or workarounds from SAP -- all without a certified migration consultant onsite.

Brian

[markus_doehr2]

> If you read carefully the information at http://service.sap.com/osdbmigration you will see that you will not loose support for the migrated system if you choose not to use a certified migration consultant, even for a production system.

I have made other experiences in the past. Your mileage may vary.

According to (including the mentioned website):

Note 82478 - SAP system OS/DB migration

<...>

To execute an OS/DB migration, the following are required:

1. A technical consultant, specially certified for OS/DB migrations, executes the migration locally, irrespective of whether you are migrating a development system, a test system or a productive system. This ensures that the required "know-how" is available to deal with the complexity of the situation.

2. You use the migration check for the operating system or the database to migrate production systems.

<...>

If the prerequisites are not met, we must inform you that SAP cannot provide any SAP Support Line support for your migration.

<...>

> For clarification, I even opened an OSS message and worked with our SAP support rep. The only thing you may "loose" support for is for any issues encountered during the migration itself or any performance issues encountered after the migration that are clearly related to the migration or improper sizing. You can still open OSS messages and if SAP deems the problem related to not having a migration consultant then you still have the option to pay SAP support to continue to help with the problem.

Sure you always can do that, if you have the time to and if you want to take the risk. I'm just telling people the "least resistant way"; just read and answered too many threads because people were trying to migrate systems without having previously used R3load or know what it is about that tool.

> We moved several different landscapes from DB2 z/OS to SQLServer last year and did not use a migration consultant for any of them. We still have support for our SAP systems. We did have a thorough migration plan and tested in sandboxes many times well before we started the moves of even the development systems. We did also have SAP perform the required migration check on the production systems. We also found an instance or two of a bug with the migration tools, opened and OSS message about it, and got fixes or workarounds from SAP -- all without a certified migration consultant onsite.

I agree, everyone is free to do what he wants. I'm just quoting what's written and based on experiences. You may have made others, however, I wouldn't rely on "getting help" quickly if the prerequisites are not met. That's all I tell people.

Markus

[brian_walker]

Understood. I just think it confuses people to say "If you don't use a certified migration consultant, you won't have support". I think this causes many people to assume that they won't have support at all for the system after it is migrated, which just isn't true. The only thing you won't have support for is for any issues during the migration itself (which are not clearly a bug with the tools) and for issues after the migration (which are clearly related to a migration problem like incorrect sizing).

To me, it is a question of tolerance for risk whether or not to engage a certified migration consultant. In our migration project we did a lot of testing and validation in sandboxes before we tackled the real systems. For the few issues that came up moving the real systems, SAP support responded very quick to our OSS messages.

We actually looked into attending one of the migration classes (TADM70) to get certified ourselves, but the most recent one we saw offered (next one is scheduled for May 9, 2011) say "Course Based on Software Release SAP Web Application Server 6.40". Since the class appears not to focus on specific from/to databases, I am not sure how the certification would help use move our Netweaver 7.00 and 7.10 systems from DB2 z/OS to SQLServer. We would have had to find a certified migration consultant that had experience with such a migration, so in the end we deemed it easier to just learn in a sandbox ourselves and document everything.

Brian

[lbreddemann]

>

> ... In our migration project we did a lot of testing and validation in sandboxes before we tackled the real systems....
> Brian

And exactly this is the point where your approach moved over to the secure side.

Based on my experience with support messages for heterogeneous system copy actions, having left out a proper testing phase is the number one guarantee for failed migration projects.

Besides that, we want our customers to be successful even if they don't follow all of our recommendations. In fact that is what we do every day in SAP support.

regards,

Lars

[brian_walker]

Totally agree. I'm just trying to clear any confusion other customers may have. Not using a certified migration consultant does not mean your system will no longer be supported (which I have seen as an answer all too often in these forums). It simply means the migration process itself may not be supported or SAP support may refer the customer to SAP consulting to pay for help that they would (potentially) not have been needed if a certified migration consultant was onsite.

While some of the answers about using a certified migration consultant are surely to prevent customers who would otherwise shoot themselves in the foot from doing so, I cannot help but be somewhat cynical and think that sometimes those answers self-serving, ie. given by those who do said consulting.

Brian