Skip to Content

A smooth migration project!!! Does it really exist?

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 🙂 , 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


You must be Logged on to comment or reply to a post.
  • Hi Mohammed,

    Indeed, Basis/Netweaver administrator will have to agree with you. I think the process can be smoother if one has a good understanding of the business operation and try to plan ahead to cover some of the expected problems like batch jobs and printing.



    • Hi Annie,

      The issue is that during the test migrations sometimes the end users dont test all the functionalities because they have their system up & running else where... But when we do the final one and hand over, they do a thorough test(should have been done during the test migrations) and come up with issue... 🙂

      But its real fun, having to work in these situations... It can teach you a lot of stuff!



      • Hi Mohammed,

        I'm at the customer end so I would say communication with the in-house Basis to cover those areas that can help. At least you have preempt it and it's up to customers how they want to take it from there.

        Just my 2 cents.


  • Yes, a smooth migration project exists. When there is a proper script, test migrations and user/interface testing before the productive migration takes place.

    No, in all other cases.

    Cheers Michael

  • Also, we need to pay extra attention if hostname/IP changed after migration, an a great impact on customer system landscape, especially PI....

    We need to identify either hostname or IP is used for customer landscape to communicate with each other.


    Nicholas Chang

  • Great blog Mohammed, thanks Mohammed

    We are in the process of migrating the whole SAP infrastructure from one location to another.

    Production migration is planned for this summer, we have migrated so far most of our DEV/QA systems and franckly I am not really reassured, I am afraid we will experience unxepected issues ;

    Two examples :

    PRD environnements are based on HA architecture (cluster failover), DEV and QA are standard central systems ...

    Hundreds of printer queues are defined on PRD environement, it is techincally impossible

    to reproduce the printer settings on DEV/QA

    Not to mention that someone decided it was a great idea to upgrade Solution Manager to 7.1 just before the migrations started ... don't do that ...

    • Hi Raoul,

      I am thinking in my head if it is possible for you to direct your DEV/QA printing to the printers configured in PRD environment.