Want to make your upgrades easier and lower risk? Try a dual-track approach.
Ahh, the SAP upgrade, that cherished activity we look forward to with the joys of spring. Late nights, a few extra weekends at the office and all the makings of next year’s finger crossing championship league. Who could think of any better way to spend one’s time?
SAP upgrades don’t have to be worrisome, after-hours activities. We can take some lessons from other techniques including DevOps practices to help ease the pain and risk of upgrades. And, make the job more flexible and less disruptive to our business needs as well.
It’s wintertime in production land(scape)
In another blog, I wrote about production freezes. In that article, the point was the disruption to innovation a planned calendar freeze causes; and there’s a related problem for upgrades: many SAP environments cannot concurrently perform and test an upgrade while maintaining business-as-usual production support. Doing so would cause the project and production environments to become out of sync, and so teams freeze production change during the period of an upgrade or deployment.
For relatively short upgrade projects, this works. Of course, the more complicated the project, the more likely the need for production change, breaking the freeze and causing other risk and disruption. Freeze-based projects also tend to put demand on technical teams since it means performing the cut-over to the new platform during a weekend, batch window or other planned downtime not disruptive to business hours. No one like Saturdays in the office.
Big projects and continuous business
A production freeze for an upgrade isn’t a suitable approach for many businesses. Those with 24/7 workloads are an obvious challenge, but even businesses using planned downtime may find long or especially complex upgrade projects impractical. For example, most SAP users are looking at S/4 migrations as an inevitability, and it’s highly unlikely any business could survive a production freeze long enough to complete a Brownfield or Hybrid S/4 migration plan: those are often measured in years.
There is a standard approach to this problem in SAP, known by the names Project Landscape, Parallel or Dual Track, or N+1. Using this approach, a duplicate landscape is created, typically sans production, and the upgrade and migration development is performed separately in this dual track, leaving the existing production support environment available for business as usual.
The benefits to this approach are numerous: project and business-as-usual work continue without disruption to each other. And, 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.
Taking inspiration from others
If we were having a conversation about this technique in a language like Java or C#, we would use the term “branch”, “tip” or even “version” to indicate where in the configuration management (version control) system we were working, leaving existing versions of the software untouched. In addition to neatly containing all of the project changes without disrupting existing production, this enables us to easily backout a change should that become necessary, since all previous production deployments are still available in the configuration management system.
Historically, the primary disadvantage of a dual track approach has been the reconciliation of change between production support and project landscapes. Horror stories of vile Excel spreadsheets line the halls of SAP development experiences, and rightfully so. However, this is where modern automation tools have substantially eliminated the classic issues of managing parallel tracks and brought with them all the benefits.
Taking from DevOps, one of the basic techniques is continuous integration. Instead of periodically reconciling change between project and production landscapes, do it continuously, before conflict can arise. When conflict does arise, don’t use cross-landscape locking to prevent change, but instead learn from the configuration management tools common on other platforms and simply notify each developer involved and ask for a new merged version containing the functionality of both changes.
Automation in the transport management system tracks this, so there’s no need for a nightmare on Excel street, and because the system is aware of every change in both landscapes, zero risk of accidentally introducing a regression at cut-over. In the event an unpredictable outcome from change does make it into production, one can revert the newly deployed transports back to the previous production configuration – just like redeploying a previous branch in Java or C#.
Looking to SAP S/4HANA
S/4 presents a special upgrade challenge, given typical projects are many months or years long, and customers with significant customization in ECC are unlikely to abandon specializations supporting their business. The common names Brownfield and Hybrid are given to these migrations containing customizations from the legacy system, even when they simplify some operations and business processes with functionality from the new platform.
When evaluating automation solutions for S/4 upgrades, be sure to look for the capability of moving customized code between the ECC and S/4 seamlessly, ensuring a smooth cutover with no loss of functionality or regression issues from synchronization between the systems during the upgrade project. This ability to automatically synchronize change between the existing production ECC system and the future S/4 platform will help smooth the transition for all involved as S/4 goes live.
Getting there
If easier upgrades and lower risk sounds good, take a look at modern DevOps tooling for SAP, including our ActiveControl solution. Fully automated release and transport management, retrofit and deployment are not beyond SAP with the right tools.
