I just came through a test where I migrated an SAP system from an old Solaris system to a newer system running on AIX. Which, on paper, seems like a simple process but yet isn't.
I have to express some frustration because the migration tools from SAP often get in the way of completing a simple project. And most of the issues that arise from these tools are often things that could have been fixed if there had been more diligent programming and better access to specific pieces of information.
One example is the migration key. I created one of these ahead of time in hopes that I could save time by not having to stop during the data import just to generate a key. Did that work? Nope. I found out the way I was generating the key was wrong (I had selected R/3 as the application type and not 620 which was the kernel). This is not mentioned in the migration guide.
When something like this fails it can be from various reasons. Is a library missing? Did I leave out an environment variable setting? I have to look through each of these potential issues when a SAP migration fails because the logging just isn't very helpful. Even worse, this error shows up late into the migration process. So the immediate thought is, should I start over? Did I just waste the last 10 hours on this only to run into a minor issue that stops the whole process? Again, this creates a huge amount of wated time that could have been saved with better programming and/or documentation.
The next issue I ran into was an issue created by the R3load program. On import, R3load created multiple entries into one table. Then the entire install crashed because it tried to create an index on a key field with duplicate entries. How stupid is that? The whole migration fails because it can't create an index on a table that I could create manually once the entire migration is completed? That's just silly. How about some restart options that would allow me to get through this? [a newer version of the R3load program did not fix the issue as mentioned in a recent SAP Note]
The other issue I was presented with was the SAPINST program itself. Creating the R3load data from the source system was easy. I just set up the system to generate the export files. But the import process was another matter. For these systems I was migrating from 4.7 to 4.7. The implementation guide states to use the latest SAPINST program to complete the system copy process. Okay. That should be easy I think to myself. So off I to to run SAPINST on the target.
Normally, what I like to do with a system migration is to install a regular version of the application first. This helps get many of the technical issues out of the way (at least that's the plan) and assists in seeing if the system is sized appropriately. Then I wipe out the DB and go back to re-install it using the exported migration data. This works fine except for some crucial problems that the new installer introduces.
First, even though I chose NOT to install the SAP kernel files the installer ignores my choice and installs them over my current (and in this case an older version) kernel folder. Same thing happens with the DB client files. I chose not to install these and yet the installer uncompresses these into a new folder (again this created a version issue since I was migrating into an Oracle 9.2 database and the client files contained the programs for Oracle 10.2). Again, I found this out during the migration process and it cost me yet more time as I had to locate an older version of the Master Installation programs to continue the process.
I was able to complete the migration and now have the process documented to the point where we will be able to repeat it several more times without the huge delays encoutered during the massing learning process outline above.
So if you have to complete any kind of migration yourself, be prepared for spending lots of time hunting down solutions based on the error messages dropped into one of many log files and not based on the information within the system copy guides.
Hope that is helpful!
Post a Comment