Skip to Content

Planning plays crucial role in any Upgrade & Unicode conversion project. So the planning phase should start ahead of time to make sure we included all the items needs to be catered during the project. Below are some of the action items you should start looking at if you are planning for Upgrade.  


Plan additional hardware availability ahead of project start

Every Upgrade project will require additional hardware in terms of maintaining dual landscape, hardware for SandBox system, hardware for mock executions (Production like environment) & extra hardware for parallel export/import to reduce downtime during cutover. Need to plan the availability of the same hardware ahead of time so that we don’t hit any delays.


Plan for OS/DB/SP Upgrade in separate window (Prerequisite)

OS/DB/SP Upgrade might be required as a prerequisite for Upgrade & Unicode conversion project. You should plan the same in separate downtime window. If you plan to perform it during Upgrade downtime window then it may add-up on your business downtime requirement.


Business downtime planning

Business downtime is probably the biggest challenge for any SAP Upgrade & Unicode conversion project. Now SAP is providing quite a lot tools which can be used to reduce the downtime & risk involved during the project cutover. You may want to refer my earlier blog on how to minimize the downtime during Upgrade & Unicode conversion projects.


SAP Server sizing

In general, the impact on existing IT infrastructure depends on the following criteria:

  • Unicode conversion planned along with Upgrade
  • Short or long transition path (the difference between the current and target release)
  • Scope of functional enhancements in the target release
  • Extent of utilization of existing IT infrastructure (such as number of users)

With the help of SAP standard application benchmarks (results at, you can get a good estimate of CPU and memory consumption of particular SAP ERP components. In all cases, you should plan to conduct a hardware requirements analysis. You should also contact your hardware vendor to verify if your current hardware will support the upgrade.


Third party/Other SAP system Compatibility check

Should plan for performing impact analysis and defining a detailed approach for handling interfaces, this should be a joint efforts from Upgrade team & the third party vendor team. Need to prepare a compatibility matrix for each of the SAP or non-SAP systems that are currently interfacing with existing environment. Need to take proactive approach & plan ahead of time to upgrade the respective systems.


Solution Manager Implementation

SAP Solution Manager serves as a central platform for the implementation and continuous improvement of an SAP solution. It contains specific upgrade features that provide direct access to the latest available SAP Upgrade Road Map version. The SAP Upgrade Road Map is part of SAP Solution Manager and provides SAP’s standard methodology to plan and execute an SAP upgrade project. It contains best practices and templates for project management, as well as functional and technical aspects facilitating key tasks of the entire project team. In order to use the SAP Upgrade Road Map with SAP Solution Manager, access transaction RMMAIN. The tool facilitates key project activities such as application adjustments (upgrade/delta customizing), testing and end-user training.

Note: SAP Solution Manager is technically required to perform an upgrade.


Identify right people for Upgrade project

It’s very important that you chose right people for your Upgrade project, the team should have good Upgrade background & good experience in the system. An upgrade project team usually consists of the following stakeholders at the customer:

  • Project lead
  • Developers
  • Key users / business process experts who Have a wide business process knowledge
  • SAP Basis / technology team
  • End users who perform the acceptance tests
  • Experts for the interfaces between SAP and legacy systems
  • External project members, for example, consultants, third-party software vendors, project sponsor, and other members of the customer’s management team


Plan unused code retirement

In general about 30 – 40% of the custom code is unused at most of the customers. Hence should plan this activity before start of the upgrade to reduce the upgrade remediation and testing efforts. In addition to that the new ERP 6.0 system will be clean going forward. After identifying the custom objects which should be retired, the subsequent step will be the deletion of these custom objects from the Development System.


SAP Business function prediction service

SAP Business Function Prediction service for customers to help them with Functional innovation for their roadmap. This service helps Prediction of relevant EHP functionality based on your existing system usage. This is a free of cost service. This can be requested in the project preparation phase.


Plan SAP involvement for Upgrade check

There are a number of services categorized as Continuous Quality Checks provided by SAP ( However, in the context of Upgrade, we should plan for the following.

  • SAP Functional Go Live Check
  • SAP Technical Go Live Check


Fall-back plan

I hope you would not need to execute the fall back plan during the project, but to prepare for the worst case scenario we should have one handy. Every customer will have its own fall back plan or DRS plan. The same plan can be used during the Upgrade as well. It’s recommended to try the execution once in mock environment to check on the process.


Part2 – Coming soon ๐Ÿ™‚  

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Chris Kernaghan
    As a fellow Upgrade an Unicode specialist I read your blog with interest to compare against my own experiences. I have a few points to discuss –

    1. Hardware provisioning – I have hit this issue so many times, and to be honest I am looking to migrate BAU systems and sandboxes into the Amazon Cloud to reduce the infrastructure requirements and speed of deployment.

    2. OS/DB upgrades – recently I have been doing Combined Upgrade and Unicode conversions on systems larger than 1TB. The downtime windows have enforced the parallel Export/Import method. This has the added benefit that O/S and DB upgrades are not required as long as the Upgraded Non-Unicode release supports them, the Import can be performed on the target releases of O/S, DB and SAP application. This vastly reduces project complexity, downtime and requirements. I did a cost analysis for a customer, it was cheaper to buy another £750K in hardware to support the Export/Import than incurr a days downtime for a DB upgrade.

    3. I was not aware that Solution Manager was a pre-requisite for an upgrade, an EhP for sure, but not an upgrade – can you supply more details.

    4. The right people are critical, the technology can let you down in so many ways but it is the people who get you through.

    5. The SAP Business function prediction service is something I cannot rate highly enough and it takes much of the customer guess work out of their EhP deployments. SAP need to get this service in front of customers

    6. Customers should engage their account managers to check what services their license agreement entitles them to

    7. In upgrades I stay away from DR systems as a fallback scenario due to the expense and complication of reverting to Normal production and then retrying the upgrade. A fallback is distinctly different to a DR, it is a failure of a process, nothing more and should be treated as a special case. Scoping and designing it will require the combined input of Infrastructure and Operations teams


    1. Former Member Post author
      Hi Chris,

      Really appreciate your inputs & comments.

      Plese find below my response to it.

      1. – That’s the reason I recommended planning it ahead of time. These days many customers are planning to move on cloud or virtualized environment to get rid of hardware restriction & to optimize the resource usage.

      2. Really good point, even we have recently followed the same approach for one of the customer. We will be not able to combine the same at most of the places due to compatibility restrictions, so we don’t have left with too many options then perform it ahead of release project timelines.

      We have done DB Upgrades in just 8 to 10 hours of Production downtime (DB size around 1TB to 4TB). The overall project timelines was just 4 weeks for all the systems in landscape.

      3. Solution manager is mandatory only for generating solution manager key during Upgrade. We can use solution manager for many other things as mentioned in my blog.

      5. You can use this service as a reference to help business understand the benefits of Upgrade, we can also use solution browser tool to get delta between source & target release.

      7. Yes the fallback plan should be developed having involved Infrastructure, Operations & application team.

      Best Regards,


Leave a Reply