Skip to Content

This blog is a continuation of my earlier blog (Upgrade Planning – Part 1), I have tried to add some more areas which falls under any release Upgrade project planning.

 

Plan for Database Archiving –

Archiving can significantly reduce the duration of the upgrade project and any associated downtime, reduce consulting costs as a result of shorter upgrade project times and reduce the hardware storage costs through data compression and the ability to leverage lower-cost media. Archiving reduces downtime needed for database backups and recovery as well as for database reorganization. Accelerates business processes and operational reporting, and hence increases user adoption and satisfaction due to improved system response Using archiving solutions, customers can often reduce the size of their SAP production database by 30% to 50%.

 

Dual Maintenance

Dual maintenance plays an important role during upgrade project and even more critical for a project where number of ongoing in-flight projects. We need to plan for parallel landscape to ensure minimal impact on the in-flight projects due to upgrade and vice-versa.  The parallel landscape will lead to a requirement of extra hardware which needs to be factored during hardware planning. Generally dual maintenance begins from the date the upgrade activity starts on the development environment.

The following areas need to be considered when it comes to managing multiple projects during upgrade window:

  • Dual maintenance
  • Code and configuration replications and repetitive testing
  • Code freeze
  • Aligning integration tests
  • Aligning UAT
  • Aligning go-lives

 

Training

The user training effort very much depends on the upgrade’s functional scope and the extent of application adjustments. The effort involved also depends on your company’s organizational readiness to deal with this topic (for example, by using accurate and complete training material). A purely technical upgrade has limited impact on the interfaces employees are using. Where the source release is SAP R/3 4.6C or higher, an upgrade to SAP ERP 6.0 will barely affect users, since SAP ERP 6.0 employs the same user interface. For releases below SAP R/3 4.6C, the impact could be considerably higher, because some crucial SAP transactions were redesigned in SAP R/3 4.6C.

 

Risk Management Planning & Identification

 Risk management planning is part of the overall project planning. The risk management plan may also include the methodology used for risk management, roles and responsibilities of the risk management team, in addition to establishing a budget for project risk management.

We will ensure that all the following categories of risks are considered:

  • Identification of risks, classification of risk, risk mitigation time frame.
  • Analysis of the identified risks — qualitatively and quantitatively.
  • Planning the response to identified risks — mitigation and contingency.
  • Defining the process of risk monitoring and control during the project life cycle.

 

Organizing delta workshops –

IT departments organize workshops showing the difference, or delta, between releases with SAP software experts. These focused delta workshops allow business process experts to assess the value potential of new SAP software functions in more detail and also help them understand the possible implications of these functions on business operations.

Solution Browser Tool for SAP ERP this tool allows you to identify new features and functions and their business benefits in a given release of the SAP ERP application and enhancement packages. It gives business process experts the opportunity to map current business requirements with the latest functions available in SAP ERP. You can access the tool directly at http://erp.fmpmedia.com or from www.service.sap.com/upgrade.

 

Upgrading or Migrating Your Operating System and Database Platform

This might be a potential prerequisite for performing a technical upgrade. Furthermore, some customers see the upgrade project as an opportunity to change their operating system or database vendor to reduce their cost of operations.

 

Planning for Unicode Conversion along with Upgrade (CU&UC)

When you are upgrading your system to SAP ERP 6.0 (including all EhP) and your system is non-Unicode, you will be asked by the upgrade tool whether you want to convert to Unicode or not. In case you have an MDMP configuration, you must convert to Unicode because ERP 6.0 and higher (including all EhP) does not support MDMP.

In short: You can perform Upgrade and Unicode Conversion as one single project. This procedure is support for source release R/3 4.6C, Web AS 6.20, NW 2004. The target release MUST BE ERP 6.0 or higher.

 

If you are converting to Unicode with the going-live phase of the upgrade project, you need to consider additional sizing requirements such as those described in the below mentioned Standard SAP Notes. These notes also explain the reasons for a Unicode conversion.

 

SAP Note 79991: “Multilanguage and Unicode Support of SAP Applications”

SAP Note 1139642: “Hardware Requirements in Unicode Systems”

SAP Note 928729: “Combined Unicode Conversion and Upgrade”

SAP Note 959698: “Twin Upgrade and Unicode Conversion”

SAP Note 857081: “Unicode Conversion: Downtime Estimate”

 

NZDT –

The near zero Downtime method designed to minimize the downtime related to SAP software updates. It covers major release upgrades, implementation of enhancement Packages and installation of Support Package Stacks. With NZDT also a Unicode conversion can be performed alone or in combination with the software update mentioned above. The major target is to minimize business downtime in the areas not available for the standard methods. With the NZDT method the overall number of downtimes can be reduced through a combination of multiple maintenance events without having to extend the total downtime. You need to start planning ahead of time if you wish to use NZDT.

 

Proof of concept –

You may want to treat your Sandbox system as a platform to create PoC. This will give business an opportunity to see how the system will look like after Upgrade. This will be even a great opportunity for the technical team to assess the impact ahead of time & geared up for the real Upgrade project. The all activities & action items mentioned in my both blogs can be tested & assessed with the PoC system. The only thing needs to plan is how early you want to execute it, which might depend on the availability of resources.

 

The following are some of the best practices one should follow if planning for Upgrade project.

 

  • Plan and manage upgrades as carefully, such as by establishing comprehensive project standards and procedures along with dependencies.
  • Cleaning up modifications and performing selective archiving can reduce the effort of an upgrade considerably.
  • Get prepared by doing at least one test upgrade in the early planning phase to identify potential risks, technical challenges and limitations, and cost drivers.
  • Perform a technical upgrade first, and then implement new functions or business innovations in subsequent projects.
  • Do not underestimate the effort involved in testing. Testing effort will be determined mainly by the need for application adjustment and the functional scope of the upgrade.
  • The need for user training depends on how much new functionality is implemented. Consider using alternative training concepts such as e-learning or a train-the trainer approach.
  • Plan for multiple mock runs (Production like environment) to make sure we don’t face any unexpected issues during production system Upgrade
  • Need to have a change management board to control dual maintenance during Upgrade project.
To report this post you need to login first.

Be the first to leave a comment

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

Leave a Reply