Susan Cannington

3 Challenges with a separate SAP project landscape

Susan Cannington | July 28, 2021

No SAP customer is the same. The different sizes and complexities of their landscapes reflect this contrast. However, organizations do have in common a desire to manage their landscapes safely and effectively. 

Creating a separate landscape, commonly referred to as an N+1 landscape, for large SAP project work, requires some consideration.

When deciding to spend the time and money, you need to think about:

  1. Project scope – if the planned duration of the SAP project is beyond 2-3 months and the anticipated impact of object changes are vast, you should do this in a separate Development/QA landscape from your production support changes.
  2. Previous conflict issues – if in earlier projects, production support changes have encountered a large number of conflicts with project changes, resulting in overtake/overwrite and hypercare issues, then it is best to perform your subsequent project work in a separate SAP project landscape 
  3. SAP Upgrade – if the SAP project includes an SAP version change, this is typically performed in a separate landscape, allowing the current version to be supported in the existing production support landscape.

So now you’ve decided to use a separate landscape, what’s next? 

There are several challenges when you have two development instances sending changes into a single production instance. However, Rev-Trac functionality can help you keep the objects in sync during your dual landscape work-mode, report on parallel developed objects, and control the start of parallel development. 

Object Version Management

Since each development system can have different versions of the same object in flight in different transports, it can be easy to get changes migrated and find that one development transport has overwritten the other landscape’s changes.   

With Rev-Trac cloning/retrofit functionality along with Rev-Trac OOPS (Overtake and Overwrite Protection System), you can prevent this challenge before it happens! Rev-Trac is already aware of the source system of the current active version in the Production system.

Before migrating a transport, the OOPS checking will alert you that you are about to overwrite with a change sourced from a different development system than the current active version. If you migrate a new version to the production system, it must be updated in the other development system, so both developments systems are on the same version as production. Rev-Trac Cloning will automate this synchronization requirement –  providing a workflow to sync the object changes with existing project changes underway. 

Reporting  with SAP project landscape

Rev-Trac’s In-flight Parallel Development report lets you view and inform your development community what objects are in flight across both landscapes.  This helps your project managers to plan their object development with little to no re-work due to production support fix changes happening in tandem with the project work. 

Parallel Development

With Rev-Trac’s Extended Locking feature, you can allow your project managers to control when to allow parallel development for objects encountering a Rev-Trac Lock message due to other changes in flight.  This will enable them to understand and control their project object development properly. 

Being informed and prepared when starting any SAP project will undoubtedly help you deliver your project on time and on budget with significantly reduced hypercare issues! 

If you have any questions or would like to discuss change/transport approaches for your next SAP project, feel free to reach out to us.