Investing in, and implementing, Enterprise software platforms such as SAP CX represents a significant business decision for an organisation. Software licenses, implementation and development costs, and building the infrastructure and systems integration required can be a substantial capital investment. But this is not the end of the story, and organisations need to recognise and balance the ongoing Total Cost of Ownership from maintaining and enhancing these platforms throughout their lifetime.
SAP CX Commerce (formerly known as SAP Hybris), as with any software system, features an upgrade roadmap for major and minor software upgrades, as well as ad-hoc and scheduled patches intended to resolve bugs, fix security issues and provide new features for businesses. SAP CX versions have a defined lifecycle that includes and end of maintenance and support window, after which patches and updates are no longer provided, after which users are expected to update and upgrade to a newer version.
Meeting the Challenge
Staying up to date with any upgrade schedule is a challenge. Knowing when urgent or critical patches are issued, and then planning those into the business, understanding how disruptive implementing them will be (in terms of testing, downtime, and the risk of failure) takes time and effort. Keeping up to date with the latest versions, especially for an IT department that has all kinds of systems and infrastructure to maintain, can feel like being in an uphill battle in the middle of a snowstorm.
Many businesses simply lack the budget, and the time to focus on keeping every system up to date, especially when set against business priorities that will often place investment in new, revenue-generating activity over spend on existing items or on risk reduction.
Conflicting Priorities
The solution for dealing with all the noise and conflicting priorities is to establish an Upgrade Strategy that clearly sets out vendor roadmap & schedules, your internal capacity and the business risk for each of your major systems. Perhaps contrary to logic, this strategy should be in place even if (and in fact especially if) you do not plan to carry out any major upgrades at all. If the business is ready to accept that its SAP CX platform will continue to operate beyond the standard window of vendor support, then articulating that within an Upgrade Strategy enables the IT department and other stakeholders in the business to take any appropriate mitigation measures to reduce risk and manage systems.
SAP CX Commerce Upgrade Schedule
SAP now operates an overall versioning upgrade schedule based on releasing new major versions of the SAP CX Commerce product each year (previously this was every 6 months). Each version of SAP CX Commerce remains supported with patches and minor updates for 2 years, after which that version ceases to be officially maintained by SAP.
| Release Version | General Availability | End of Mainstream Maintenance |
| 2205 | May 25, 2022 | May 31, 2024 |
| 2105 | July 28, 2021 | August 19, 2023 |
| 2011 | November 11, 2020 | February 11, 2023 |
| 2005 | May 13, 2020 | August 13, 2022 |
| 1905 | May 29, 2019 | August 29, 2022 |
| 1811 | December 12, 2018 | August 29, 2021 |
| 1808 | August 8, 2018 | August 29, 2021 |
| 6.7 | April 11, 2018 | August 8, 2020 |
| 6.6 | December 13, 2017 | April 11, 2020 |
| 6.5 | August 30, 2017 | December 13, 2019 |
| 6.4 | May 31, 2017 | August 30, 2019 |
| 6.3 | January 25, 2017 | May 31, 2019 |
| 6.2 | October 19, 2016 | January 25, 2019 |
| 6.1 | July 27, 2016 | October 19, 2018 |
| 6 | April 13, 2016 | July 27, 2018 |
| 5.7 | October 8, 2015 | April 13, 2018 |
| 5.6 | August 4, 2015 | October 8, 2017 |
In addition to this schedule, SAP currently supports 3 variants of CX Commerce deployment.
- SAP Commerce On-premise solution formerly known as SAP Hybris, implemented by customers on their own hardware infrastructure
- SAP Commerce Cloud on SAP Infrastructure (CCV1), a private cloud implementation with managed services
- SAP Commerce Cloud in the Public Cloud (CCV2), a Kubernetes-based, self-managed platform
In line with the general SaaS market, SAP is encouraging users to move from on-premise SAP Hybris to Commerce Cloud Public Cloud (CCV2), and while on-premise support may continue for some time, new customers will be expected to adopt SAP Commerce on CCV2 by default.
SAP Commerce version numbering
In mid 2018 SAP changed the format of the versioning system for SAP CX Commerce to be in line with other SAP products, using the format YYMM, making the next release after SAP Hybris 6.7, in August 2018, SAP Commerce 1808.
Prior to this, major releases were numbered consecutively 6.5, 6.6, 6.7 etc. with patches released usually monthly and numbered using 4 digits ending with the last patch available for that version release; for example, for SAP Hybris 6.7, the final patched version is numbered 6.7.0.31 released on July 17, 2020.
After the release of 1808, SAP Commerce patches are indicated by a single decimal place, so for example for SAP Commerce 1808, the latest, and last, patch released was 1808.41, available on August 12, 2021.
Upgrades and Patches
During the Mainstream Maintenance period for any SAP Commerce version, SAP will release software patches, usually monthly.
Individual Patches
Individual patches are generally straightforward to implement and contain fixes and updates that resolve potential security risks and performance improvements. Installing a patch release does not normally involve code changes outside of the core platform, resulting in faster and simplified testing.
Major Upgrades
Major upgrades are more of a challenge of course, especially for customers with significant customised implementations of SAP Commerce. In addition to the effort involved in deploying and testing a new version in a like-for-like scenario, the new version of SAP Commerce will undoubtably come with new capabilities and functionality that can either replace the customisations currently implemented or enable customers to launch new features that add value and provide new experiences for customers.
SAP Major Release considerations
Each new release of SAP Commerce contains changes and new features which can have an impact on platform use and implementation.
New Features – new releases of SAP Commerce may include completely new functionality that can be utilised to extend the capability of your e-Commerce storefront
Improved Systems Integration – changes and improvements to the methods available for integrating SAP Commerce to back-office systems such as ERP and CRM systems
Simplified Code – potentially out-of-the-box features that allow customers to replace existing custom code with standard capabilities available in SAP Commerce
Deprecated Code – an upgrade may remove features that were included in previous versions, for example accelerators, modules or cockpits may be deprecated and no longer be available in the package of the new version
Selecting an Upgrade Strategy
Whether you are planning or considering implementing SAP Commerce as your e-Commerce platform, or you are already running SAP as your selected solution, building an ongoing Upgrade Strategy is essential to balancing operational need and risk against TOC and ROI.
Option 1: Continuous upgrading to the latest version
If you are newly implementing SAP CX Commerce Cloud or have already moved to Commerce Cloud (on the CCV2 platform) then this is the likely default scenario and implies that your business is running on version 2105 or newer.
Your IT teams will already be aligned to developing CX Commerce for the CCV2 environment and you will be able to utilize the automation functions of Commerce Cloud to develop, test and deploy new versions of SAP Commerce as they are released by SAP.
Changing Strategy
If your business is on an older version of SAP Commerce, is on CCV1 or on-premise, then moving to a strategy of continuous upgrading will require a change of your existing strategy and potentially a considerable initial effort to get into this position, depending on what version of SAP Commerce you are running now. Upgrading to CCV2 is a major project involving all the stakeholders in your business and will require specialist help from an SAP Partner and/or SAP itself. The effort required will depend on multiple factors, including the degree of customisation implemented on the current platform, the number of storefronts running, and the complexity of back-end integrations and 3rd party systems connected to the SAP Commerce platform.
Impact of Cloud Operations
What you may need to factor into your upgrade strategy from CCV2 on, is that many upgrade and maintenance tasks are more aligned to a DevOps approach than you may have operated previously. This could have an impact on your IT teams’ structure and skillset, as you migrate away from a on-premise infrastructure and move towards a more continuous development and delivery model.
The advantages of continuous upgrading are obvious from a security and reliability standpoint; your SAP Commerce platform will be continually supported by SAP, your business will have access to all the latest features and functionality, and you will have access to security hotfixes and patches to ensure that your commerce store remains compliant with industry standards including PCI DSS. It does mean that you need to build in this cost and effort from the outset (or from the point of migrating to the Cloud), but ultimately the investment required is more smoothed and less challenging than trying to budget for larger scale upgrades every few years.
Option 2: Upgrade only when necessary
Most businesses tend to fall into this strategic pattern as a balance between the risk of running out of date and unsupported systems, and the perceived risk of being an early adopter of untried and untested software. It also becomes a standard approach when organisations and teams have gone through the stress and expense of a large-scale platform rollout project and in effect, want to draw breath before considering doing it all over again.
For SAP CX Commerce this strategy implies holding off on any upgrades until the organisation is one or two (or more) major versions behind the current release; the result is that the business must face the decision to carry out a significant upgrade project every 2 years, based on the support lifecycle from SAP. How large that upgrade will be will depend on how much the versions of SAP CX Commerce have diverged, how much the core code has altered, and how much customisation has been undertaken in the intervening time.
The risk is that without a stated and agreed upgrade strategy, and without setting aside the budget in advance, large scale upgrade projects like these tend to be relegated to a low business priority, meaning that it’s easy for this year’s upgrade to be pushed back to the next; and when next year comes around, the platform is out-of-support and end of life. At that point the Option 2 strategy looks a lot like Option 3; the cost and effort of upgrading spirals upwards, the current platform has further diverged from the newest releases, and the willingness to invest in upgrading has receded. It takes strong discipline to maintain an ‘upgrade only when necessary’ strategy in the long term, but it can be done if the strategy is stated clearly, and the business understands the risks, and the likely costs of undertaking these upgrades and the factors that impact that cost.
Option 3: Stay on the implemented version
This may feel like the default strategy for many businesses, and certainly avoids making the decision, or the investment, in the effort involved in upgrading. It can feel like the tempting solution for businesses that have gone through the potentially costly process of implementing an enterprise software solution like SAP Commercee
Whilst the platform version remains within the maintenance window then remaining on the installed version makes sense; so long as security patches and hotfixes are being released regularly, then the platform will remain secure and compliant, and your commerce store will remain reliable.
End of Maintenance
The problems will start to surface once end of maintenance passes, and the version in operation by the business becomes more and more of a legacy product. Not only does the version of the product become older and unsupported, it is likely that the underlying code and infrastructure also becomes dated, for example, with the release of SAP Commerce 1905 came support for Java 11 and Spring framework 5; these issues might not impact the currently deployed platform, but can add complexity and costs, in retraining or redeploying developers and support engineers, and in refactoring custom functionality that may have been developed in code that is no longer supported.
In short, the longer you wait, the higher the cost to upgrade, and the harder the decision comes.
Security Risks
What may drive your decision-making process are security concerns. Any business that processes credit or debit card payments online must comply with PCI DSS; the security standards set by the payment card industry. Failure to comply with these standards is considerably risky; both from the risk of fines (or even refusal of your bank to permit you to take payments online) and from the reputational fallout from the theft of customer’s money or data.
PCI DSS includes some specific requirements around ensuring that Commerce platforms are supported and updated, so remaining on an unsupported version of SAP CX Commerce without an adequate mitigation strategy in place can be a critical threat to your business. Added to PCI DSS, almost every country operates some form of data protection legislation, such as GDPR or CCPA; older versions of SAP Hybris may not be in compliance with such legislation, and as data protection legislation requires customer personal data secure, an outdated, unsupported platform by default may fail to provide that level of data security.
Risk Mitigations
If the strategic decision is made to not upgrade after the maintenance window closes, then the business will need to put in place mitigations to reduce the risks involved. There are a number of possible actions that an organisation can take if upgrading is not an option:
1. Beef up security to better shield your outdated software systems; this might mean adding additional tools and resources to protect your vulnerable storefront such as a robust cybersecurity system that can provide real-time intrusion detection and monitor for vulnerable or hacked code and CDN services in front of your store to provide a buffer between the outside world and the commerce platform.
2. Put in place hardened security policies that reflect the risks; increase password security and encrypt data as far as possible, increase the frequency of backups and implement two-factor authentication where you can.
3. Bring in a specialist cybersecurity firm to monitor and manage security on your site, or resource your internal IT team to be able to dedicate specialists to maintaining security.
4. If you are currently operating on-premise, migrate your existing platform to a more secure Cloud-based infrastructure such as Azure or AWS that can provide a more compliant and resilient base.
These strategies operate largely as a stopgap and can help you reduce risk and put off the decision to upgrade to another day.
Composable Architectures
There’s also one more significant option that allows your business to continue operating your existing platform as is over a longer time period, and it’s a strategy that can both reduce security risks by reducing the attack surface available to cyber criminals and can provide future proofing improvements to the customer experience of your storefront; by decoupling your back-end commerce platform from the front end storefront.
This is what has become known as ‘headless commerce’ and has been a trending concept in e-commerce for some time. In effect, the front-end website/store becomes an entirely separate system from the back-end platform and logic, with the two halves communicating via a middle-ware API layer such as one based on REST.
From an experience viewpoint headless commerce provides a powerful way to create rich, dynamic customer experiences, sites and apps that work for any device or audience, and apps that can be built, and changed, rapidly. SAP provides an out-of-the-box framework for SAP CX Commerce & Hybris called Spartacus, built on Angular code; but there are also multiple alternatives including Adobe’s AEM or Contentstack CMS. Going Headless also provides a long-term security solution as the potentially vulnerable back end is removed from direct access to the exposed front-end.
A truly headless architecture can allow your business to continue operating the solid engineering and processing features of SAP Hybris for managing product data and your product catalog, orders and order processing, and the integration to your back-office systems, while at the same time breathing new life into the front end. Going headless of course requires investment and carries a cost; but in most situations this is going to be considerably less than a major platform upgrade and may be a more palatable spend for any organisation that may be more ready to expend money on new features or development vs. upgrades and maintenance. Moving to a headless architecture allows organisations to future proof existing systems, reduce dependency on single monolithic platforms, and create new customer experiences.
Establishing a Commerce Strategy with Techwave
If you are interested in finding out more about how Techwave’s Customer Experience practice can help you to establish a long-term strategy to support your current investment in SAP CX Commerce, or you are considering SAP CX as your potential platform for future commerce, reach out to us here