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:
- From DE2 to UA2 to PRD the changes that business is needing (automated support via STMS).
- 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).
- 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.
Hi saptechnicalguru,
Many thanks for this Block.
I have a question.
I have 3 system landscape:
-ECC/DEV
-ECC/QAS
-ECC/PROD
For the S/4HANA migration I proceed as follows:
1. I create a systemcopy of ECC/DEV to DEV_New and migrate to S/4HANA ->(S4/DEV) (Inplace Upgrade)
2. I create a copy of ECC/PROD to QAS_New and migrate to S/4HANA ->(S4/QAS1)
3. I create a second system copy from ECC/PROD to QAS2_New and migrate to S/4HANA (S4/QAS2 )
4. I am migrating ECC/PROD to S4. (S4/PROD)
What is the transport route then?
Do I transport in ECC/DEV -> ECC/QAS -> ECC/PROD ——> ECC/PROD Migration to S4 ?
or do I transport like this:
Manual comparison between ECC/DEV and S4/DEV ->
ECC/DEV -> S4/DEV -> S/4QAS -> S4 Migration -> S4/PROD
Have I understood that correctly ? Is that the correct order?
I don’t understand how to transport from ECC to S4.
Many Thanks
Best Regards
Max
Fixes for the current landscape follow DEV –> QAS –> PROD
You cannot transport from ECC to S4. You can only redo work there. So you have to apply fixes done in regular landscape in S4/DEV by hand. This is called dual maintenance.
Fixes for S4 only: S4/DEV to S4/QAS and to S4/Prod in the migration weekend.
Bug fixes for current landscape: ECC/DEV to ECC/QAS to ECC/prod, then judge for S4, and apply manually to S4/DEV and move to S4/QAS.
Hi Saptechnicalguru,
Many thanks for your help.
Does that mean I should also create a system copy /ECC/PROD to ECC/PROD1 and then migrate (Inplace Upgrade) that system to S/4HANA (then I have 6 System) ? Or can I take a Inplace Upgrade in ECC/PROD (then I have 5 System) ?
I then have these system copies:
ECC/DEV ->system copy to ECC/DEV1->system conversion to S4DEV1
ECC/QAS->System copy to ECC/QAS1->System conversion to S4QAS1
ECC/PRD->system copy to ECC/PROD1->system conversion to S4PROD1
My transport route would then be like this:
ECC Landscape transport route:
ECC/DEV->ECC/QAS->ECC/PROD
In ECC Landscape are the changes transported to ECC/PROD.
S4 Landscape transport route:
S4/DEV1->S4/QAS1 (waiting for S4PROD1 system conversion)
In S4 landscape are these changes made manually in S4/DEV1 and transported to S4/QAS1. The changes wait in S4/QAS1 System until the S4/PROD1 (Systemconversion) to S4) system is finished.
Then this changes are transported to S4/PROD1.
Then I do an inplace upgrade to S4, from ECC/PROD1 to S4/PROD2, then my new S4 system already has all the changes in it , because they have already been transported to PROD in the ECC system landscape.
Are the changes then not duplicated in S4/PROD ? ?
Because I’m transport the changes twice:
ECC Landscape:
ECC/DEV->ECC/QAS->ECC/PROD
And in S4 landscape:
(manual changes)S4/DEV1->S4/QAS1 (after S4 sysemconversation from ECC PROD)-> S4/PROD1
many thanks
Best Regards
Whether you need a parallel landscape or not is up to you. It comes with costs and benefits. The balance is different per company.
You typically keep single production. Production is converted from ECC to S4.
Hi saptechnicalguru,
Many thanks !!!!
but I still don’t understand, aren’t the fixes in S4/PROD double then?
Double maintenance:
1. For ECC Landscape I transport the fixes like this:
ECC/DEV -> ECC/QAS > ECC/prod
2. Then I implement the fixes manually in S4/DEV
3.For S4 landscape I transport the fixes like this:
S4/DEV -> S4/QAS
4. Then I migrate ECC/PROD to /S4/PROD (the fixes are already in S4/PROD-because I do inplace upgrade from ECC/PROD)
5. During the migration (ECC/PROD->S4/PROD) in SUM I transport the fixes from S4/QAS -> S4/PROD.
Aren’t the fixes in S4/PROD double then? Because I have already transported them (1) in ECC Landscape and then (2) in SUM in the S/4HANA conversation
many thanks
Best Regards
You have to judge case by case.
Example; issue with Z program reading KNA1.
This Z coding is being adjusted already in S4 since KNA1 is replaced with BP logic.
Your fix on the Z program is moved to ECC prod.
But your fix might be needed as well in the S4 one. Or maybe not, since the whole logic is different.
In case you fix ECC Z program in ECC prod, you take the same fix to S4 Dev and QAS and upon import to S4 prod it is exactly the same version including the fix.
But: most Z programs are hit in the S4 conversion. If you don’t incorporate the fix for ECC PROD in S4 version, then upon import to S4 PROD the bug fix is lost.