General Considerations for Converting a Three-System Landscape

The SAP S/4HANA conversion of a standard three-system landscape can be performed as follows:

Make early experiences in the sandbox system: technical conversion procedure, modification adjustment, test of customer developments, check functionality, test of core business processes.
Reduce dual maintenance period: do high-effort work in a sandbox system before converting the actual landscape, to reduce the time between conversion of development (DEV), quality assurance (QAS) and production (PRD) system.
Reasons for a sandbox system:
Test technical conversion procedure.
Learn about the specifics of your SAP system.
Test of customer developments in SAP S/4HANA Server.
Understand and plan custom development changes in detail.
Start modification and custom development adjustment.
Limit efforts by focusing on objects in production.
Reduce double maintenance and code-freeze period.
Perform first tests of core business processes in the SAP S/4HANA server.
Understand and plan integration tests requirements.
Perform the first checks of new functions.
Obtain insight in the SAP S/4HANA server and plan future functional rollouts.
Obtain first test results of technical conversion downtime.
Understand and plan downtime-optimization requirements.

A temporary maintenance landscape is set up during the project to ensure the maintenance of the production system on the old release until it's converted. The SAP systems will be removed after the completion of the conversion project.
Always set up a three system landscape for maintenance – only emergency corrections allowed.
Plan and communicate code-freeze time.






Lessons Learned: Project Management
- Make early experiences in the sandbox system:
- Technical conversion procedure.
- Modification adjustment.
- Test of customer developments.
- Customizing.
- Check functionality of processes.
- Test of core business processes.
- Reduce dual maintenance period:
- Do additional work in a sandbox system before the conversion of the actual system landscape.
- Reduce the time window between conversion of DEV and PRD system.
- Involvement and commitment.
Early involvement of key users and management commitment are key success factors.
Plan and communicate code-freeze time.
Lessons Learned: Functional Aspects
- Good housekeeping drives efficiency of conversion:
- Archiving and cleansing of unused custom code and SAP modifications.
- Document table changes thoroughly and their usage in custom programs.
- The older the release, the more money spent on training.
Use computer-based training: easy to distribute and review at the convenience of the user.
- Industry solutions.
Customers with industry solutions should review the specific information.
- Tackle custom developments as early as possible.
The faster the development team can have access, the faster business-process issues can get resolved.
- Modification adjustments and testing are key cost drivers.
The better the documentation and existing test procedures, the easier and less time consuming those project tasks will be.
Note
For SAP S/4HANA Conversion to private cloud see information on DMOVE2S4: "DMO move to SAP S/4HANA (on hyperscaler)" in blog https://blogs.sap.com/2023/05/31/two-major-news-with-sum-2.0-sp-17/.
Best Practices for Transitioning a Three-System Landscape to SAP S/4HANA Cloud
Note
While this SAP Certification provides foundational knowledge, please note that a private cloud migration can be a complex process, with many teams involved, timelines, systems, processes.
We expect our PartnerEdge Sell and Service partners providing migration services to have comprehensive experience using SAP tools and to be aware of the processes involved and that is why we also highly encourage you to consume the following resources:
https://support.sap.com/en/product/onboarding-resource-center/rise.html
The project-plan for transitioning to SAP S/4HANA Cloud doesn't differ from the general approach as depicted previously. As in a typical on-premise transition, it starts with the transition of the sandbox (SBX), which is the first contact with the transition process and tooling. After that, the development system is transitioned, building on the experiences of the SBX. The quality system is covered next, refining the process once again through repetition.
The crucial part for a successful go-live is the PRD dry run. This step is carried out on production kit to replicate go-live conditions as accurately as possible. It helps to get precise timings, accurately predict the necessary outage window for business downtime, and target actions to coincide with appropriate lessons learned. The PRD dry run is like a final rehearsal before the big show. It verifies that the entire PRD system can be migrated successfully in the available window, and any migration errors encountered are thoroughly documented. This meticulous approach ensures a smooth transition, minimizing risks and maximizing the effectiveness of the migration process.

A standard SAP S/4HANA Cloud Private Edition contract offers additional test runs with the option to add more as a billable service if required.
One for migration scenarios:
1. Additional test run of the production (PRD) system.
Two for SAP S/4HANA conversion scenarios:
1. Non-production (QAS, DEV, and so on) system.
2. PRD system.
If PRD hardware is used for dry runs, there's no need to rebuild the target system for the final run. The migration partner can simply drop the database and continue migration. Multiple dry runs can be performed using the Migration VM process, but ECS post-migration and build activities are limited as per roles and responsibilities. For an SBX run, QAS or PRD tier resources can be reused if no standalone SBX is included in the contract.