Migrate to SAP Commerce Cloud: Technical Considerations
17 min read
In this article you will 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. If you haven't already done so we recommend you begin with the article Migrate to SAP Commerce Cloud.
Table of Contents
A successful migration is one that keeps intact or improves the system's functionality, data, and performance. Migrating to SAP Commerce 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. two sandboxes and a production environment). The migration process involves a sequential and incremental migration of these environments from their respective on-premise equivalents. The order in which you migrate the environment depends on the planning of your project. Two typical sequences seen in projects are:
- Migrate from lower to higher environment (e.g. DEV, STG and PROD)
- Migrate Production first, test it, and proceed to migrating the lower environments in parallel (e.g. PROD // DEV, STG).
In addition to the below technical considerations please refer to the information in the following pages:
- Information related to assessing current Commerce implementations to prepare for a migration to the cloud: Assessments are vital to a successful Migration to SAP Commerce Cloud
- Concise technical Checklist for Succeeding with SAP Commerce Cloud
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
Application Layer: although commerce processes are hosted using standard computing resources, 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 Microsoft Azure SQL Database and Azure Blob Storage services. Microsoft Azure SQL Database 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 case-by-case.
- 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 and 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 please refer to the Cloud Portal help page.
A few key pointers for your setup:
- Code Repository Setup: when you connect your repository, the system pulls your code into the builds and environments that create your unique product platform.
- Adding a Build Manifest to your Code Repository: the build manifest defines how
your application should be built by including baseline properties with environment-specific
- Build Manifest Components: the components of the build manifest enable
you to configure a number of build attributes. You can explore
build manifest examples.
- Build Manifest Components: the components of the build manifest enable you to configure a number of build attributes. You can explore build manifest examples.
- Builds & Deploy: when you're ready, you create the compiled code of your SAP Commerce Cloud application, and then deploy it to a provisioned environment. You can:
Solr: you can replace the standard setup with a customized version of Solr
- Adding Language Packs: you can deploy language packs to SAP Commerce Cloud by adding a property to the manifest.json file in your code repository
Why do you need to adapt your custom code during migration? Planning to migrate to SAP Commerce 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 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
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
Configure the SMTP server details on SAP Commerce Cloud.
Leveraging a 3rd Party SMTP Service?
Optional: If you require a VPN (virtual private network) to ensure a secure connection to your SMTP relay server or external systems, please review Virtual Private Network (VPN) help page.
Decide on the most suitable approach to email integration.
Email server details should be available before the migration starts.
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 this help page.
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
Using ImageMagick as part of SAP Commerce Cloud:
See: this page 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 'backgroundProcessing' aspect.||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 have the option to 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.
In addition to the above listed Code Adaptations that are necessary changes to run existing Commerce applications in the cloud, modifications to existing integration patterns or creating new integrations may be needed especially if developing new functionality for cloud environment. SAP recommended strategy moving forward is to move beyond the traditional in-app extension/customization and to leverage a 'side by side' extensibility pattern where you extend Commerce Cloud outside of the core application.
Please see Integration Options for SAP Commerce Cloud for additional information on this topic.
Data & Media 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.
Please read through Data and Media Migration for further information on how to successfully execute migration of Commerce related data to the cloud.
Migrating Configuration to Cloud Environment
Most configuration settings used in the current SAP Commerce project can be reused as is, however there are considerations needed for some configuration to adapt to the SAP Commerce Cloud environment. These activities could range from controlling how IP traffic flows into your system, to setting up host name aliases for IP resolution.
Please see the information topics listed at the SAP help page for the various areas relevant to your SAP Commerce application that may need to be reconfigured for a move to SAP Commerce Cloud.
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 such as:
- 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.
Please refer also to Testing a Migration of SAP Commerce.
The scalability offered by SAP Commerce Cloud is a feature meant to cover for traffic increase, it is not meant to cater to non-performant code. When moving to SAP Commerce Cloud your application, no matter if previously hosted on premise or on a hyperscaler infrastructure, you're adopting a new infrastructure with its own principles and you need to execute thorough testing; as previously performant code might run differently on the new infrastructure.
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 in 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 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 performing poorly: 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
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 such as 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.
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 step in a successful migration. Understanding the SAP Commerce Cloud architecture and having a detailed migration are natural next steps.