Overview

In Upgrading your SAP Commerce Solution we outline reasons to upgrading and describe the different types of upgrades. But, what does it take to complete a successful upgrade project? In this article, we answer that question by outlining 4 critical phases with corresponding activities that need to be executed.

Table of Contents

Background

As explained in Project Delivery Framework, an upgrade project follows your e-commerce solution's lifetime to maintain supportability or take advantage of new features included in the latest release. An upgrade project will be shorter than your first implementation project or longer than subsequent implementation releases, depending on how much code refactoring is required.

An upgrade project should have a definitive plan. In this section, we outline our recommended approach and we cover all the steps in the upgrade project framework and the milestones that should be achieved before moving on to the next phase. This upgrade project framework has been successfully used by our CX Expert Services team several times.

Project Phases

In the diagram below, we split the upgrade project delivery framework into 4 key phases and later we'll go in-depth to explore the tasks and responsibilities of each phase.

 

Discovery

Discovery Questionnaire

Five questions that could drive initial upgrade assessment discovery:

1. 1. Does the data model need to be redesigned?

   2. What is the level of technical debt in the code?

   3. What is the level of customization versus out of box functionality in the code?

   4. What new enhancements or features of SAP Commerce are needed?

   5. What kind of compliance and security requirements are there?

Rough Order of Magnitude (ROM) Estimate

The ROM estimate is linked to a particular type of upgrade project: Like for Like (technical upgrade), Extended (technical upgrade), or Functional upgrade. The ROM estimate can take the form of a T-shirt size with a range of effort defined for each size. For a more detailed assessment see Step-By-Step Analysis of SAP Commerce Upgrade Effort .

Planning

Initiation

The goal of the initiation activity is to let the customer and the project team to kick-off the Upgrade Project. They will work together to create a mutual understanding of what the upgrade project hopes to achieve. This means answering questions like:

• • The why  – business goals and objectives of the project
  • The what – high-level scope and prioritization ( security vs. new features)
  • The how – approach, methodology, and ways of working
  • The when – high-level project plan, milestone and resource planning
  • The cost –  estimated project costs including project team, infrastructure, licensing, and so on
  • The risks – business/project/technical risks of the project

The Initiation phase starts with a discussions between the customer and members of the project team, then moves into the preparation activity below. The goal of this activity is to introduce all stakeholders to the core practices, establish whether the customer accepts the upgrade is driven primarily to control time, quality and cost, and make sure they understand the scope is variable to allow change and manage the contingency as needed.

In addition, you should start making the following available to the members of the project team:

• • Source code
  • A copy of the SAP Commerce/media directory

  • Dump of the database

For the detailed set of questions you should answer in this activity, visit the "Questionnaire" tab of the attached Upgrade Planning Workbook .

Make sure you cover the following: 

• • The importance of reducing customizations that increase the cost of ownership over time
  • Push for minimum viable product and maximum used of OOTB capabilities for faster go-to-market 
  • Challenge every customization tand check if maybe it is on the roadmap of coming releases; maybe the cost of waiting is lower than the cost of customizing it
  • Expedite decision making 
  • Push for zero tolerance of any modification that could expand the original project scope
  • Include important considerations reduce upgrade project risks that could delay schedule or increase cost
  • Plan for contingencies
  • Treat the functional upgrade as a full cycle project that starts with a discovery where the implementation team needs to look at:
    • New capabilities
    • Creating business cases
    • Identifying enhancements needed to achieve the business goals
    • Creating a proposal that includes budget, scope, and resources
  • Make sure you have the right team and make sure they are ready to adapt to the new platform
  • Define KPIs from the beginning of the upgrade project and define what success looks like

Preparation

Once the kick-off has occurred and the high-level questions in the Initiation activity are completed, it's time to move onto the Preparation activity. The output of each activity may be covered in the  Upgrade Planning Workbook . We cover the background for each activity below.

Build Project Team

The size and responsibilities of your team will change throughout the project. It is important to evaluate what roles you need for each of the subsequent three phases (planning, execution, and closing) because it will have an impact on who you bring on the team, and when. For more details see the "roles and responsibilities" for an upgrade see Upgrading your SAP Commerce Solution . For larger upgrades, you may need a bigger project team. Keep in mind that it is possible for one person to fulfill multiple roles, but if you don't plan what you're going to do, it is hard to build the right team.

Problem List

With most upgrades, there is going to be one or more business drivers that necessitate an upgrade. To create this document, the entire team (Business Analysts, Developers, Support, Project Management, Consultants, etc.) should meet and create a simple document that outlines all the existing problems. This includes problems that are found in the platform, data, and within the processes surrounding the use of SAP Commerce. This is an opportunity for everyone to have a discussion of the issues because they could be factored into the upgrade plan. You should also document any assumptions made when discussing the problems. The items that are not addressed should be rejected or created as a backlogged item, in your issue reporting system.

Upgrade Plan

Once you've identified your problems,start thinking about a high-level upgrade plan. In this step, you need to develop the following:

• • A list of all extensions with additional information for custom extensions and how each of them is used.
  • Visualization of the extension dependency tree to understand how each of the extensions interacts with each other.
  • A list of assumptions and possible problems that could come from moving forward with an upgrade.

Once you have the information above and a complete problem list, it's time to start documenting the plan. Your plan should outline each task that may be required at a high level, including the ones that will be completed by 3rd parties. The task list should include both technical and non-technical tasks. Beside each task and its owner, you should have a short statement defining what done means and references to any other activities it might depend on.

Estimation

Now that an upgrade plan is in place, it is time to put an estimate against each task. The method of estimation should be based on a defined set of criteria that all stakeholders have agreed upon. This can be hours, story points, or some other metric. It is important to be consistent when evaluating each task in your upgrade plan. If the criteria needs to be changed during this process, you should restart and re-evaluate the other tasks to ensure they are using the same criteria. When there isn't a consensus on an estimate, the outliers should be discussed with the group and those supporting the outlying values should outline their reasoning. If a unanimous consent cannot be reached then the outlying arguments/assumptions should be documented and incorporated into the Risk Management portion of the upgrade project.

By the end of this activity, you should have a detailed plan of all potential activities along with their estimates.

Project Plan

The last step brings all previous activities into a single and cohesive plan. Now that individual tasks, dependencies, and estimates are documented, you need to complete the following steps for each task:

1. 1. Do we wish to move forward with this task? If yes, add to the project plan
   2. Using the estimate and any other dependencies document a potential start date and end date. Account for items such as weekends, holidays, training, and individual vacations.
   3. Is the task on the critical path?

You should now have a detailed project plan with an estimated start and end date that can be managed throughout the upgrade project. This project plan should be shared and approved, by at least the leads in each stakeholder group, to make sure everyone is in agreement.

Execution

Upgrade Engineering

The goal of the upgrade project activity is to take your current solution that contains custom part and platform (source version) - upgrade platform binaries to a new version (target version), perform technical migration / re-generate custom code, and perform technical migration of configuration and database, in order to be compatible with target binaries version. Before understanding the various approaches, you need to understand how your solution is structured. Depending on your solution architecture you might only be able to use one or two of the approaches available.

Non-Accelerator Based Solution

Before the Accelerators introduction a SAP Commerce deployed solution consisted of:

• • Platform binaries (core + platform extensions) - the SAP Commerce product
  • Custom code + configuration - code which was added during the implementation, which extended the standard product functionality with features specified to each implementation
  • Database - business data and type system that was created after first initialization

Once the accelerators are introduced each implementation gives the option to use the accelerator based storefront provided, or choose not to use the accelerator and create their storefront. If you decide not to use the accelerator, you are using a "non-accelerator based solution." By taking  this route, there is additional flexibility to design the storefront, which includes programming language used. However, it usually results in a longer initial implementation project, because of the work required to design and implement a storefront and its features from scratch. Some solutions that use a non-accelerator based solution use Omni Commerce Connect (OCC) to interact with the SAP Commerce Platform, though some also use the Java APIs available to implement their Java-based storefront(s). 

By using a non-accelerator based solution there is likely more initial customizations, but because of constraints put in place by the APIs available, future upgrades are easier. For non-accelerator based solutions the Technical Approach for upgrades is the only possibility.

Accelerator-Based Solution

Over the years various Accelerators (B2C, B2B, Telco, China, Financial, Travel, etc.) have been introduced to help provide a consistent foundation of code that would save many people days up-front, but it can result in more difficult upgrade projects. This is because as soon as you generate the Accelerator extensions (via ant modulegen) and make a single change to the generated code, you've created custom code. Every additional change you make to the generated Accelerator extensions increases the level of customization. So, when it's time to upgrade you must decide what is most important, as this will guide the approach to use:

• • Upgrade the SAP Commerce platform binaries and perform technical migration of custom part (Technical Approach) - In this case, you're interested in upgrading the platform binaries, likely to maintain support or take advantage of out of the box features. This is the fastest upgrade option, but you will only make changes to your custom code (including accelerator), that are required to keep your solution running correctly.  This approach does result in increased technical debt because your custom code is modified as little as possible and will not be taking advantage of new features that may now make your customizations redundant. Some important features, like performance improvements, or security mechanisms, should be implemented anyway.
  • Upgrade the SAP Commerce platform binaries and re-generate accelerator code in Target Version + port old features implemented in Source Version (Template Approach) - This option requires more work because while you are upgrading the platform binaries you are receiving e a fully upgraded Accelerator. However, your custom code in some places, might decrease because you might be able to rely on features included in SAP Commerce you previously needed customizations for.

Approaches

At a high level the following approaches can be used to make your code base, configuration, and database compatible with target binaries version:

• • Technical Approach - The focus is on upgrading the SAP Commerce platform code and only executing required changes to the custom code, configuration, and data (if applicable) + implementation of really important fundamental features like Security. The results; the platform binaries is on the target version and custom part is compatible. Regardless if you're solution was built using an accelerator or not, this custom code configuration and data will be technically migrated, with changes to allow it to build and run properly + cherry-picked important functionality (like security mechanisms).
  • Template Approach - Another method worth considering is to upgrade accelerator based solution to the latest version. F or this approach the target version of SAP Commerce is used as a base with the necessary accelerator(s) generated first, after which the custom functionalities from the source version are ported over one by one, as needed, to this target version. Now the platform and Accelerator code are on the target version. In this case you are only porting over legacy features/customizations that you need.
    

Each approach has its pros and cons, that are outlined in the table below:

Testing

There should be a heavy amount of QA performed against the upgraded code. This is in addition to the QA that should occur in the Upgrade Engineering activity. During this activity, a full regression test should be done to make sure everything still works, performance testing to understand if the application's performance has changed, acceptance testing to ensure any existing/new functionality works as expected, and security testing to test for any new security issues that may have risen during the code upgrade.

Deployment

In this activity, you are pushing the code to the necessary environment(s) and running any additional update steps as documented in your build plan. It is important too test the full build plan against an environment that resembles production (SAP Hybris Commerce version, product/order data) as much as possible. Using an environment that was incrementally updated during the "Upgrade Approach" activity should not be used to verify the build steps. This is because you can't guarantee an incremental update from a single deployment that worked, will again work when executed as a single step in a larger build plan.

Your build plan should account for any data migration that will occur when upgrading your code. There are some scenarios where the data needs to be prepared prior to the actual deployment, and it is crucial that these steps are included in the build plan. Once the code deployed there might be some optional data migration steps to ensure existing orders, products, and so on work with your target version. These steps should be completed before the regression testing.

Once the upgraded code has been deployed and the team has confirmed any required data migration is complete, a regression test should be executed before the site is made available to external customers. This is to ensure the key scenarios are working in the upgraded production system.

Support

The support activity can be as short or as long as needed, but the duration should be planned in advance to make sure the right people from the team are available. During the support phase, the team is responsible for ensuring the upgraded system is running correctly. Any P1 bugs should be fixed by the team. If there aren't any P1 bugs the team should begin to tackle any P2 bugs.

At the end of the support activity, the ongoing maintenance of the system should be handed to the Application Management team, then the closing phase of the project can begin. The support activity can continue if the stakeholders agree the site is not stable.

Closing

Reporting

Create various reports to document how successful the Upgrade Project was, which means:

• • Updated list of bugs / known issues
  • Lessons learned / Sprint retrospective
  • Updated financials
  • Final updates to training / knowledge base/ handover documents for support team

Final Hand-Off

Once the upgrade is completed and deployed, the final step is to complete a final hand-off to the BAU (business as usual)  team that will support the application going forward. A meeting should occur with key stakeholders from the BAU team to share the reports created during the reporting activity. It is possible that some documentations might be incomplete and extra training might be required to help the BAU team understand how to use the new features. In your project plan, you should include some time to transfer knowledge and close any gaps shortly after the upgrade is deployed, while the upgrade team is still around.

Once the BAU team has confirmed the handover documentation is complete and the Upgrade Project Steering Committee have agreed the project is complete, then the upgrade project can be closed and the Upgrade team disbanded and freed up to work on other projects.

Conclusion

You now have a good idea of the phases and activities involved with an SAP Commerce upgrade. If you want more details on completing an upgrade please contact cxworks@sap.com