Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

Hello everyone,

Just want to share the experience of a migration project. I work in the SAP hosting division of a company as a Netweaver consultant and activities such as go-lives', migrations, restore-recovery etc are very common on our menu. Having been involved in quite a few of these dreadful weekends, I thought it would be a good idea to write a blog about it. So here goes...

Once a customer decides that it wants to move its systems from one datacenter to another or from one hosting provider to another or just for kicks :smile: , this is the point where a migration project begins. Netweaver consultants are required to gather the necessary data and also perform test migrations before the real migration weekend. What exactly do i mean by necessary data?. One example is database size, let's say the source database is 2 TB and the target server has 2TB for the database, 4 months from now (for the real migration) the source database would have grown and we need to take that into account. Another example is custom file systems, we always need to do a thorough inspection of the source server to see if there is anything non-standard and try to replicate the same on the target server.

Perhaps the best example is operating system & database versions of source and target. If the source and target are same, then we do a homogeneous copy with a database backup. If the source and target are different, then we need to perform an export-import with the sapinst tool. An export-import can be time consuming if the database is huge and we would then need to come up with techniques that speed up the process and reduce downtime such as table-splitting. With the help of MIGMON, we can split large tables and assign a greater number of CPU's and parallel jobs for importing and exporting the ABAP dump. We can also have a common file system between the 2 servers and perform the export-import in parallel. During a test migration we need to at all times collect data, How long did it take to export-import a particular table?, What was the CPU utilization during the import ABAP phase?, Can i increase the CPU's and parallel jobs without overloading the host?. All these help for the final migration. Using MIGTIME we can analyze the time each package took & make changes to the number of splits or the groups per job during the next test migration.

Also once we have finished the import, we need to make sure that the profiles, job logs, transport files etc are all in synchronization with the source, only then can we hand over the system. Think it's over? Sorry not yet! Once users start to login, there can be memory bottle necks and all sorts of issues. Contrary to what you may think, this is my favorite part of the project. E-mails just keep flying around saying, "We are getting 2000 short dumps", "Our batch jobs are failing", "We are not able to view or import transports", "Our audit logs are missing", "We are not able to print in Chinese" etc. But a week after the handover, things start to settle down and the migration comes to an end.

Hope you enjoyed reading

Also eager to know the opinions of fellow Netweaver consultants

Regards,  

10 Comments
Labels in this area