CX Works

A single portal for curated, field-tested and SAP-verified expertise for your SAP C/4HANA suite. Whether it's a new implementation, adding new features, or getting additional value from an existing deployment, get it here, at CX Works.

Migrate to SAP Commerce Cloud: Technical Considerations

Takin

Migrate to SAP Commerce Cloud: Technical Considerations

In this article you find all the important technical considerations to succeed in your migration to SAP Commerce Cloud. This is part of a series of articles to help you migrate to SAP Commerce Cloud in the Public Cloud. If you haven't already done so we recommend you begin with the article Migrate to SAP Commerce Cloud

Table of Contents

Technical Considerations 

A successful migration is one that keeps intact the system's functionality, data and performance. Migrating to SAP Commerce Cloud in the Public Cloud not only involves moving your SAP Commerce solution to a different infrastructure, but also requires adapting your current solution to fit the SAP Commerce Cloud architecture, as well as copying your data across database platforms. It is important to properly plan and execute the changes required for your move.

SAP Commerce Cloud provides three standard environments (i.e. the development, staging and production environments). The migration process involves a sequential and incremental migration of these environments from their respective on-premise or SAP Commerce Cloud on SAP Infrastructure equivalence; starting with the development environment, then staging, and finishing up with the production environment. The following paragraphs guide you through a set of technical considerations relevant to your migration.

Infrastructure Consideration

SAP Commerce Cloud Architecture consists of a combination of mandatory and optional software packages which can be used to create a tailored commerce solution. The SAP Commerce Cloud architecture may differ significantly or slightly from the baseline architecture that you are migrating from. A migration assessment should be performed prior to the migration planning to determine the possible differences between the two architectures. Any gaps found should be addressed with accompanying recommendations. Some of the most common code adaptation changes typical to a migration project are discussed later in this page. In this section, we discuss the main architectural components along with some of known obstacles within each component. 

Web Layer: SAP Commerce Cloud offers a standard web tier that is closed to customer specific configuration. This restricts the ability to make modifications regarding: 

  • Using non-default load-balancer scheme
  • CDN (content delivery network) integration with authentication
  • Web server caching
  • Static content cache at the web server  

Application Layer: although commerce processes are hosted using standard computing resource, SAP Commerce Cloud infrastructure is able to dynamically match load to required capacity through horizontal scaling of:

  • Web Server nodes
  • SAP Commerce nodes
  • Solr nodes
  • SAP Commerce data hub nodes

Storage Layer: persistent storage is provided by both Azure SQL (structured query language) Server and Azure Blob Storage services. Azure SQL is currently the only back-end database offered by SAP Commerce Cloud:

  • File storage: SAP Commerce Cloud offers Azure Blob Storage in place of traditional file system. Here are a few considerations relating to file persistence:
    • The local files system accessible to containers should not be relied upon for file storage. Use the Azure Blob Store offered by SAP Commerce Cloud as the medium for processing files. 
    • The default media storage strategy cannot be changed from the default for SAP Commerce Cloud media strategy which relies on the use of Azure Blob Storage.
  • Database and SQL processing: a database change to Azure SQL may require gap analysis between Azure SQL and the source database. For instance:
    • In the unlikely event that your current database stores large objects (lob) greater than 2 GB in size, the existing data may not fit into Azure SQL lob types which are capped at 2 GB. Data truncation might happen and such occurrences should be analyzed in a case-by-case manner. 
    • Considerations must be made to all database platform-specific SQL statements contained within your custom code: they should be removed or replaced with Flexible Search queries. 

Security Layer: security is a wide topic and we only attempt to highlight a few of the security elements we think you may be interested in: 

  • SSL (secure sockets layer) offloading is achieved at the web server layer. 
  • Data stored in Azure SQL and Azure Blob Storage are encrypted at rest.
  • Calls made to the Azure SQL database from the application layer are encrypted. 
  • Traffic in an out of the web server is also encrypted.

Builds & Environments Setup

Setting up your commerce cloud environment is simple: the Cloud Portal makes it easy to create new environments; generate and deploy builds to environments. Your code repository needs to be connected to SAP Commerce Cloud, and it needs to contain a so-called manifest file (a.k.a. build manifest) which defines the extensions, properties, aspects, and tests for your application. For an overview of many of the features of the Cloud Portal, including build and deploy, please watch the following video:

A few key pointers for your setup:

Code adaptations

Why do you need to adapt your custom code during migration? Planning to migrate to SAP Commerce Cloud in the Public Cloud may require changes to your current implementation or code be adjusted to work with public cloud infrastructure. The most common code adaptations when migrating to SAP Commerce Cloud in the Public Cloud have been analyzed and published in Getting Started with SAP Commerce Cloud. Here is an outlook to some of the published code adaptations. 

Code Adaptation (click in the deep links for more details) Options Activities Dependency
Integrating an Email Service with SAP Commerce Cloud with the New Commerce Cloud Email Services


Since SAP Commerce Cloud Build Platform does not offer an SMTP (simple mail transfer protocol) relay server; below are a few recommended options to leveraging external email sending capabilities with SAP Commerce Cloud

  • Use your self-host SMTP Server
  • Leverage a 3rd Party SMTP Service
  • Integrate with Email Service

Configure the SMTP server details on SAP Commerce Cloud.

Leveraging a 3rd Party SMTP Service?

  • Take care of the contract with the desired 3rd Party before the implementation starts.
  • Extend the code base to integrate with the desired provider. The action of sending an e-mail is delegated to an EmailSendStrategy implementation that makes the necessary API calls

Optional: If you require a VPN (virtual private network to ensure a secure connection to your SMTP relay server or external systems, please review Setting Up a VPN for SAP Commerce Cloud.

Decide on the most suitable approach to email integration.

Email server details should be available before the migration starts.


Image Resizing



A common solution for image resizing is for SAP Commerce to use a local deployment of ImageMagick software, typically hosted on the same system running SAP Commerce. In SAP Commerce Cloud, ImageMagick is delivered as part of a different extension called cloudmediaconversion. You'll have to adopt this extension to keep using ImageMagick, see https://help.sap.com/viewer/0fa6bcf4736c46f78c248512391eb467/SHIP/en-US/fba094343e624aae8f041d0170046355.html

An alternative is to leverage an external Digital Asset Management system (DAM) and ensure it is connected to your SAP Commerce Cloud solution. Examples can be found in the SAP App Center.


Using ImageMagick as part of SAP Commerce Cloud:

See: https://help.sap.com/viewer/0fa6bcf4736c46f78c248512391eb467/SHIP/en-US/fba094343e624aae8f041d0170046355.html for more info.



File Sync - Cloud Hot Folders (Extended Hot Folders)

File-based integration with SAP Commerce was realized through the standard Hot Folder for file-based data imports. In the SAP Commerce Cloud world, things have evolved to using Cloud Hot Folders.

An obvious difference between the new and old approach towards file-based import is the location of the file to import. For SAP Commerce Cloud, this will be the designated Azure Blob Storage provided to you by SAP Commerce Cloud itself.

Review your file upload approach and validate that it can incorporate a Blob Store file upload using standard Azure tools (or third-party tools). 

Enable and configure Cloud Hot Folders.

Use the default File Processing Channels or add more channels as needed.

Learn how to Get the Most out of Your Cloud Hot Folders and Azure Blob Storage

Retrieve your Cloud Hot Folders Storage account properties from the Administration Console (HAC) [see Microsoft Azure Blob Storage Connection Properties]. 

Cache Region Configuration

The way you specify your cache region size changes with your move to SAP Commerce Cloud: ultimately, in SAP Commerce Cloud your cache region size is no longer static, but a computed value relative to the system's dynamic available memory.

Keep the cache configuration dynamic based on the total amount of available memory provided by a variable.
Cronjobs Execution In SAP Commerce Cloud, cronjobs should run within the right SAP Commerce instances in the Kubernetes cluster, as defined by the 'backgroundProcessingaspect. Review bulk processing jobs to validate they adhere to the recommended guidelines.
Additional Server Hosting

There may be a need to host latency- and/or bandwidth-sensitive applications as close as possible to your SAP Commerce Cloud solutions. On premise, you would naturally deploy these processes within the same host or network as your SAP Commerce solution. SAP Commerce Cloud is a fully managed infrastructure that does not allow you to deploy additional external software. Learn more about ways to host third-party software for use with SAP Commerce Cloud.

List out the applications, binaries or infrastructure components (beyond the Commerce application and database) that make up your target architecture.

Use architectural design that promote separation-of-concerns between the productive SAP Commerce Cloud subscription and the rest of your world.

Decide on a best fit target architecture.

Consider factors such as latency, bandwidth, security and cost when deciding on the target architecture of choice.

Data Migration

It is recommended to clean-up your data before migrating your data: you can follow Data Maintenance and Cleanup guide to learn how to maintain your data. Reducing the size of your data through proper cleanup will not only reduce the time to migrate your data, but also eliminate any negative performance impact from having unnecessary data. 

Lift & Shift

Lift and shift are a set of activities to setup your SAP Commerce Cloud solution so it works similarly to your current system. These activities could range from controlling how IP traffic flows into your system, to setting up host name aliases for IP resolution. 

Below are some common configuration activities to help you setup up your new SAP Commerce Cloud in the Public Cloud solution:

  • Once your environment is successfully deployed, you define the endpoints through which you connect to the underlying services. Additional configuration could include:
    • Uploading static files that can be served by the web-server expose or used to inject properties into the application.
    • Adding a maintenance page for when your site is undergoing maintenance.
    • Setting up website redirects to define alternative landing pages for your storefront.
  • There are a number of security configurations that you may wish to apply to your solution including the application of firewall rules and SSL Certificates. You could:
  • Use the event logs to find information on the environments in SAP Commerce Cloud, by:

Smoke Testing

It is important to execute a sanity test to verify that your newly-migrated environment is ready for the next testing phase. Executing your smoke test include verifying functionality like:

  • Users can log-in and log-out.
  • Orders can be successfully placed. 
  • The home page works as intended. 
  • The Product Detail Page is rendering correctly with correct product information including price. 
  • The Product List Page is rendering correctly with valid set of information. 
  • Search is working correctly. 
  • SAP Commerce Cloud is communicating with third party systems via both storefront and backend systems and processes.

Performance Benchmarking

A properly executed performance test will help avoid instability, outages and other performance-related issues that could ultimately affect the experience of your customers and their trust on your brand. It is important to ensure your migration to SAP Commerce Cloud does not introduce any performance degradation. The code you are running on your current system might be optimized for your existing setup, but might require additional tuning for your SAP Commerce Cloud in the Public Cloud solution. A few considerations:

  • Introducing new features with the migration project also adds more risk: the further apart the migrated code is from its original source, the higher the chances for performance variation across your old and new systems. Plan to only migrate code that has been released to production.  
  • Performance of the source system should be measured and compared with that of your migrated SAP Commerce Cloud solution, after all code has been migrated. Any observed degradation should be resolved before going live.
  • What to do in case you observe poor performance on SAP Commerce Cloud? There are many reasons why your migrated solution could seemly be poor performing: these reasons could range from missing database index to excessive caching. You may wonder, "how can a database index get lost?" An index available in the source database will not migrate over SAP Commerce Cloud if such index was created directly in the source database platform without a corresponding definition in the SAP Commerce type system. This can typically occur via a Database Administrator running a script of SQL queries directly against the database at sometime during the lifespan of your SAP Commerce solution. Missing indexes could impact query performance.
  • Before starting your migration project, review the existing performance test plans, tests scripts, established KPIs and NFRs; otherwise plan to develop one as part of sprint 0.

Deployment, Go Live & Cut-Over 

SAP Commerce Cloud migration involves migrating your development environment first and then finishing up with your production environment. As each environment is being migrated, it is helpful to keep an activity log of what was done to setup and configure each environment. Ultimately, this methodical approach helps build your go live checklist as you migrate one environment to the next. The resulting list will form the foundation of your go live plan. The final go live plan should be reviewed by every member of the team with a participating role in the go live for accuracy and completeness. Furthermore, the plan should be tested until trusted.  Every participating member should also be fully aware of not just the plan but also the schedule. The Go Live Readiness for SAP Commerce Cloud walks you through additional considerations like addressing the readiness of your team and providing a sample go live checklist. To ensure that your site is ready to manage external traffic, you can perform a readiness check to test your site in terms of availability and load-balancing efficiency.

Conclusion

The process of migrating to SAP Commerce Cloud should be a methodical approach towards transferring your existing SAP Commerce functionality and data from your current environment to SAP Commerce Cloud in public infrastructure. A detailed migration assessment is an essential first in a successful migration. Understanding the SAP Commerce Cloud architecture and having a detailed migration are natural next steps.