Let's be honest - upgrading a SAP Commerce (Hybris) platform is a task that nobody loves. Often you start the project under pressure, forced by expiring version support. And since real business benefits through the upgrade are hard to achieve, it's hard to find a budget. Unfortunately, there are no reasonable ways around it, so all you can do is to focus on getting the job done smoothly and quickly. In this article, we will discuss the prerequisites of a successful SAP Commerce (Hybris) version upgrade with the least amount of effort and risk for the organization using proper strategy, planning and efficiency of execution. From our text, you will learn that: SAP Commerce upgrade is a project with unique characteristics
- It may bring your business great value if planned properly
- Respective software versions have caveats significantly affecting risk and effort
- Thorough analysis and quality assurance is key to eventual success
- Skilled and experienced teams are of immense help
What is an SAP Hybris upgrade? We talk about an upgrade project when a commerce project built on top of SAP Commerce is expected to use a higher version of its core component - the platform. Based on our experience, customers rarely engage in upgrades and prefer to maintain the proven old core of their system for as long as possible. Thus, from a system maintenance perspective, the upgrade can be considered a typical but rather infrequent hygienic activity.
New version may bring value to the business New features released by SAP are always described in release notes and the documentation. But customers are rarely following those sources and thus can’t benefit from new functionality. Some improvements affect areas which may help business right away, or with just a slight degree of integration effort. Checking all new versions for potential value for the business is a proactive approach which helps in finding budgets for the task. Still, the main driver for starting an upgrade project are:
- Security concerns related to deprecated technologies
- Company policies dictating the use of particular stable software versions
- Expiring vendor support
Include upgrades in your long-term road map While SAP clearly communicates the benefits of new versions, they are also relatively clear about their support periods. It's no secret when a respective version’s support expires, and this is a piece of essential information when maintaining a SAP Commerce - based software platform. You don't want your upgrade task to pop up on your priority list at the last minute before the support expiry. Notably, since upgrades bear a highly varying level of complexity. What if you end up embarking on a fewcmonths-long project just to regain vendor support? Now, frankly, this scenario has not occurred very frequently in the past - SAP proved to be somewhat lenient when it came to extending the support period. However, and that's extremely important to note, recently we have been observing a significant change in SAP's attitude. The dates are considered more and more final, accelerated mainly by the strong push to the cloud. Thinking of upgrades in advance, analyzing the impact and including it in your overall project mitigates the risk of running into unpleasant surprises as far as the scope of the project upgrade is concerned.
Plan an upgrade like a regular delivery project Upgrading a SAP Commerce engine for a complex commerce platform doesn't sound like a simple task. It is a real project, and it should be structured as such. It requires careful planning, a skilled team, flawless execution and reliable quality assurance. However, the upgrade project has its unique characteristics that you should account for. Firstly, it seems to fit perfectly into agile delivery models, as initially there is a much higher level of uncertainty which only gradually clears up as the project progresses. Secondly, attention needs to be given to synchronizing the upgrade work with potential functional development, possibly performed by other teams. Often those activities are performed in parallel and affect the same codebase and infrastructure.
Be aware of the caveats in your go-to version When it comes to the complexity of an upgrade, it depends mainly on the respective versions to be skipped or reached. The total effort spans from a few days to likely more than a hundred. Often, exchanging the platform is a relatively straightforward task, which can be handled efficiently provided sufficient testing. On other occasions, it ends up being a real hassle. Imagine your system relies heavily on the old promotions engine which has been disabled in 1905 and likely will be removed in a future version. It effectively means you will need to reconfigure all your promotions and re-implement the extensions. Or what if most of your backend processes are based on the old hmc and cockpits? As we all know, it has been destined for end-of-life for years, but SAP had not pulled the plug for a long time. After they finally did, many customers found themselves forced to quickly configure and customize replacements, during their next upgrade to version 1811 or above. Changes may be so far-flung, that they introduce new business processes and users have to adapt to new ways of working which requires new training. That's a big impact for a simple core library upgrade!
Extend the life of legacy back office As we have touched on this topic, at ENGINIETY, we have developed a solution which would allow you to extend the life of old backend applications despite the necessity of migrating to 1811. If you face the challenge of this particular upgrade and want to stick with your proven back office (hmc/cockpits) for some more time, we would be happy to help you achieve this.
Knowing precisely what has changed in any new version is essential to the success of the upgrade project. We recommend the analysis and planning to be already considered at the stage of road mapping.
Perform a thorough analysis and estimate the effort What makes upgrades different from a regular project is the inherent uncertainty of the effort and complexity. In automotive industry the term “marriage” describes an essential milestone in car manufacturing - it is the moment when a motor is connected to the chassis. Now, think of an SAP Hybris upgrade as of a “marriage” of your long-lasting complex project chassis to a new and unknown product engine. The risks and challenges are evident.
Some of them can be read out of release notes, or documentation but effectively the process will remain a venture. You can’t assure the plugs are going to fit in, before you actually attempt to connect them. Thus, it is not viable to perform an effort estimation before engaging in a closer code-level analysis. Considering that we recommend splitting the upgrade project in two parts.
The first stage is about identifying all technical, and business-related challenges of the upgrade. The result is a series of quick-and-dirty prototypes, backlog of actual tasks and rough effort estimation. Executing this part requires decent tooling and mature methodology. When it comes to particular project knowledge, our experience shows it is less critical. Apart from the basic knowledge of functionality that needs to be tested, of course.
The second stage, likely the more time-consuming one, is performing the actual upgrade. While in the first part work-arounds and dummies have been built and only rough testing was performed this part’s objective is the creation of solid production-ready code. Development and quality assurance play major roles in this stage. Make sure the project team has upgrade experience What we've said so far paints a clear picture - the inherent risk of an upgrade project is way higher than, let's say, a regular functional extension. Even effort estimation is so much more difficult for an upgrade. Thus, the best way of coping with all those challenges involves an experienced team. The upgrade activities, when executed repeatedly, become a standard-like process. Experiences are gathered and stacked, tools and methodologies are established. There is only a limited set of problems one has to face when doing an upgrade - mostly it's the incompatibilities on the level of code, database or whole modules. Having a solution for most of those issues right away makes the task much more predictable. And if there is no easy fix, the experience from other projects will help create reasonable workarounds.
Assure quality on multiple levels At the end of the day, an upgrade can be considered successful if the project ran on time and on budget, and ideally generated some additional business value. Not insignificantly important is the fact that the system does what it did before, without any flaws. It needs to be assured that the entire scope of functionality is not affected by the version change. There are various ways of achieving this goal. We always strongly advocate creating and maintaining a broad suite of automated tests. Apart from improving the overall quality and productivity, those are of unparalleled assistance to ensure a successful upgrade. If not available, manual tests have to cover for their lack, but make sure those are based on sufficient and well-managed test plans. A "smoke test" approach is risky as upgrades may cause issues on the edges and corners of a system, usually not covered by any smoke test. Make best use of test environments A crucial aspect to consider is the final deployment to the production infrastructure. As expected, the implementation of a platform upgrade is more likely to fail than a regular one. This happens due to the extent of the changes. It must be thus tested on systems which are analogous to production both in terms of infrastructure and data, usually called "acceptance" or "pre-prod". Preparing for upgrade deployment makes for an excellent opportunity to review those systems’ configurations and disaster recovery procedures so that they ideally match production.
SAP Commerce upgrade is a complex process that takes a lot of necessary steps and may involve serious risk for your business, in particular, that you inevitably come across unexpected pitfalls in the process.
In our opinion, this is key that you should find a partner that will guide you through the upgrade of your SAP Commerce in a well planned and structured way, with all the specific characteristics of your business in mind.
We hold a SAP Recognized Expertise Certificate in SAP Cloud for Customer as only one of the 25 companies worldwide.
We have a vast experience in commerce technologies and an expertise you want to find in your technology partner.
Hence, we can provide you with a thorough analysis of new versions, carefully planned execution and a solid quality assurance.
My name is Krzysztof Molin. I am the CEO of Enginiety and an author of this article. If it happens that you're thinking about SAP Commerce Upgrade but don't know where to start or you have already got stuck in the process, drop me a line.
I will reply you personally.