SAP’s Minimized Downtime Strategy for Upgrades

Photo: Courtesy of Sterling Ely (DogFromSpace @ Flickr)

Besides the innovation brought to the SAP world with Mobility and RIAs over the 2009 – 2011 period, another major trend for this trinity is upgrades.

Fact: 4.6C is running out of support soon and many customers cannot delay it anymore.

They will have to upgrade and for manydo Unicode conversion. While many have already taken a step ahead, many are still waiting to find the right opportunity to leap.

One (of the many) major constraint for refraining the customers to upgrade is the usual associated downtime. An upgrade might result in several hours up to a couple of days of downtime. Although, CU&UC (Combined Upgrade and Unicode Conversion) helped a lot to reduce it significantly, for many businesses this is not something they can afford.

SAP has been listening, digging into the customer constraints and leverages in order to come up with a solution to reduce the downtime. As part of their ALM solutions and services, they now propose the Minimized Downtime Strategy to support the upgrade project (note:this is not the downtime minimized strategy used by sapup).

The Minimized Downtime Strategy comes as a set of  best practices to optimize the leverage of your environment (ERP, Database, Storage and other infrastructure) in order to significantly reduce the downtime linked to your upgrade; Note that this also applies to Support Packages and Enhancement Packages.

Two solutions are proposed, depending on youruse case:

• Incremental Migration and Incremental Conversion (IMIG and ICNV)
• Near Zero Downtime (NZDT)

The Incremental Migration and Incremental Conversion work pretty much the same. It will consist in identifying thelargest or longest running tables in the system, and copy these. You will then perform your migration/conversion while the source system is up and running. Meanwhile,you will copy the delta information using RFC.

Once you are done with these major tables, youenter the downtime phase during which you finalize the delta transfer of the remaining transactions on the source system and copy the rest of the tables which were not copied.

This method relies mainly on an exhaustive analysis phase prior to the migration, during which you identify the tables that need to be transferred and on which you will then activate the proper trigger for data transfer. It is then a matter of planning besides regular MIG/CNV operations.

The Near Zero Downtime Strategy is a bit more complex but relies on the same concepts. Here below are the high level steps:

• Prior to the upgrade, an analysis needs to be carried in order to identify which tables need to be frozen, those for which we will allow updates and for which we need to activate the triggers
• The source system is cloned to a similar system. The target system is isolated from source but for specific data flows
• Users continue working on the source system. Recording of transaction data is activated for all relevant tables into logging tables on this system
• Upgrade is performed on the target system
• Delta transaction data is transferred from source to target during the uptime
• Source system is frozen as we enter into the downtime phase and remaining delta replay is performed, last transports imported
• The infrastructure switch is executed in order to set the target system as the new productive system
• System is validated and reopened to the users

The Minimized Downtime Strategy comes with both pros and cons. You have to face a risk of performance degradation during the delta recording and transfer, and you will have to handle conflicts during the transfer. But on the other side, most activities are performed online. Thus even though, the available business functions are restricted, this does not result into a complete freeze of the business activity. Through a dual landscape, you are also able to leverage more contingency in case of issues, and are still able to reverse to the source system in case of problem during the cutover.

Besides the Minimized Downtime Strategy, SAP has released several other tools to support your upgrade project along the whole lifecycle from the gap analysis up to the final testing. These tools aim to furtherly prepare your operations in order to mitigate the risks during the upgrade and make sure you fit within the downtime window negociated with the business.

I invite you to watch the Virtual TechEd Session presenting the support tools for the upgrade, among which an overview on MDS: http://bit.ly/d378ne.