Plenty of SAP customers are more than just a couple of releases and service packs behind on ECC. In that era, support sunsets came relatively slowly, and there are options including 3rd party maintenance or leaving a system change-stable. Decades old code, for better or worse, still runs.
But for most S/4 customers, that kind of legacy isn’t an acceptable approach.
For S/4, the tempo of releases and sunsets is faster. S/4 instances are more likely to be in the cloud or even accessible through integrations to a public front end making security and functional patches more critical. S/4 customers know they must do better at staying current.
Yesterday’s approach to upgrades – the Production Change Freeze – isn’t practical anymore. The business can’t tolerate the downtime, especially as upgrades happen more often, and IT teams don’t exactly love weekends at the office performing cutover. And a production freeze for an upgrade isn’t practical for many businesses: 24/7 workloads are an obvious challenge, but even businesses using planned downtime may find long or especially complex upgrade projects unworkable.
SAP’s built-in approach to parallel change – known as a project landscape, parallel rail, or N+1 – can be cumbersome and even risky. Especially if changes happen in production support during an upgrade project. Preventing accidental regression at cutover often becomes a manual spreadsheet exercise of tracking and hope.
But it doesn’t have to be this way.
What if upgrades could take place over the course of weeks or months, but without a production change freeze? This would provide the time to do thorough analysis, testing, and plan cutover to production, but without the downside of freezing out regular support for the business during the project.
The parallel approach has been given a bad rap by some because it can create conflict between the project and production systems when business requirements mean changes to the same objects in both landscapes. To help with this problem, SAP introduced cross-landscape object locking, but that effectively makes the problem worse by eliminating the true purpose of the project landscape in the first place: parallel change!
If we put the issues of stock tooling around SAP aside, the benefits of the parallel approach are numerous: project and business-as-usual work continue without disruption to each other. The project can take as much time as required without consequence to production change needs or availability. Often, planned outages and long cutover periods can be avoided entirely as the upgraded environment can be fully deployed and tested before go-live, something nearly impossible to do robustly using a freeze approach.
So, what if tooling existed to mitigate the challenges of the dual track approach? If you could solve for the reconciliation of change between production support and project landscapes automatically, the horror stories of Excel spreadsheets full of object and program names would be distant memories. Keeping production and upgrade systems in sync throughout an upgrade project would be automated, confirming any conflicts or risks automatically, and continuously ensuring change, conflict detections and automated retrofit across both systems.
If easier upgrades and lower risk sounds good, consider ActiveControl from Basis Technologies. Fully parallel projects with automated retrofit and conflict detection are not beyond SAP with the right tools. For more information on this approach for your next upgrade, join our next S/4HANA webinar or contact us here for a personal demonstration or discovery session.
