Tag: conversion

S4HANA conversion downtime

When converting from ECC 6.0 EHP8 to S4HANA, you will have to face a significant downtime. In most cases a whole weekend or more.

To get insights into your estimated business downtime, first run the SAP S4HANA Readiness Check.

On the results website, scroll to the Planned Downtime Calculator tile:

Now the details will show the total estimated downtime split into phases:

Phases:

  • System Ramp-Down
  • Downtime Preparations
  • Technical Downtime (SUM)
  • Technical Postprocessing and Data Conversion Preparation
  • Finance and Material Ledger Data Conversion
  • Application Postprocessing
  • Business Validation
  • Go/No-Go Decision
  • System Ramp-Up
  • Fallback Buffer

Each of the phases is described and a amount of estimated hours are put into the estimation. Some are empirical, some are based on your data volume.

You can update the times in the graph by entering the number relevant for your situation and then press Save:

Set up parallel landscape for upgrades and conversions

When doing a conversion from SAP ECC towards S4HANA you will face a long period where the system is frozen for changes. In most cases business changes still need to continue. For this situation setting up a parallel landscape is a good solution. A parallel landscape might be required for other major upgrades or large data conversions.

How does a parallel landscape work?

How does the parallel landscape work? Initially we have a DEV, UAT and PRD system landscape where transports move from DEV to UAT to PRD system.

With a parallel landscape we install a second development and UAT environment of the same version as the production system. Let’s call them DE2 and UA2.

Now we can start to convert and upgrade the DEV and UAT system to the new target version.

Now 3 development moves are happening:

  1. From DE2 to UA2 to PRD the changes that business is needing (automated support via STMS).
  2. From DE2 to DEV system there is manual synchronization required (dual or double maintenance): all code changes and settings need to be redone (or in some cases even redeveloped).
  3. Transport from DEV to UAT (automated support via STMS): here is where you make your future fixes and developments and move these from DEV to UAT system for testing.

Conflicts between points 2 and 3 often need manual resolution.

At the go-live moment, all transports are imported into PRD from the UAT environment. After live the DE2 and UA2 system can be decommissioned.

Costs of a parallel landscape

Don’t underestimate the costs of a parallel landscape:

  • Your infrastructure for Development and UAT system will double.
  • If you are unlucky you also need parallel landscape for connected systems like BI and SCM.
  • You need basis resources to install, setup, monitor and update the extra systems.
  • More transports to monitor and to keep track of.
  • The double maintenance is a lot of work to be done manually. You need also extra person to keep track of administration that the double maintenance is done properly.

Tooling might exist to help, but in practice it cannot cover too many use cases. So don’t get your hopes too high on them.

Alternatives for parallel landscape

There are alternatives for a parallel landscape:

  • Accept the freeze period
  • Set up an emergency repair box: copy productive system to a special system for emergency repairs only

These alternatives can be an option for smaller landscapes and organizations.