Common mistakes when migrating SAP Commerce from on-premise to Cloud

SAP has been focusing on moving their product portfolio to the cloud and expects their customers to make the shift as well. SAP Commerce 2205 is the last on-premise release of the company’s commerce offering and will be going out of mainstream maintenance in July 2026 , which means many businesses will need to migrate to SAP Commerce Cloud over the next 2 years.

Making the move to Commerce Cloud comes with substantial benefits, from more frequent feature releases, to no longer worrying about infrastructure maintenance, to the improvements in performance and scalability that a modern cloud architecture enables. However, the shift to cloud can also bring unexpected challenges that require new ways of working to solve.

Here are 4 common mistakes to watch out for during your SAP Commerce Cloud migration and steps to take to minimize the risks, cut the costs, and reduce the time-to-value of your project. 

Lack of communication and buy-in across business teams 

Cloud migration may be triggered by technology needs, but it often leads to a wider modernization of business processes that makes the project just as much of a change management challenge as a technical one. 

Looking at a SAP Commerce Cloud migration through a tech-only lens can lead to disruption of critical functionality, frequent delays, and missing out on potential business value the migration could enable. 

Set up a cross-departmental migration team 

Bring together a group of representatives from marketing, merchandising, engineering, finance, and other departments that rely on SAP Commerce to create a migration roadmap that factors in both technology and business priorities. 

This team can help: 

• Define business critical requirements; 

• Uncover potential roadblocks early; 

• Simplify and consolidate workflows; 

• Identify obsolete data, features, and processes that don’t need to be migrated; 

• Find opportunities to solve current challenges with the new deployment;

• Train colleagues on the new system. 

Clarify the implications of software-as-a-service.  

“Moving to the cloud” can mean different things to different people, and it’s good to get stakeholders on the same page about what’s actually involved in the shift to SAP Commerce Cloud. 

The current version of Commerce Cloud, SAP Commerce Cloud in the Public Cloud 2211 , is delivered as software-as-a-service (SaaS). Which means that SAP takes care of infrastructure maintenance including cloud hosting, security updates, performance monitoring, and compliance standards. This is possible because the platform is hosted on a shared Microsoft Azure cloud environment and all customers use a standard set of core platform processes, which allows patches and updates to be instantly deployed to all users. 

So an SAP Commerce Cloud migration isn’t a lift-and-shift of on-premise architecture to your choice of cloud provider, it requires adopting the core Commerce Cloud processes and moving to Microsoft Azure infrastructure. Which is important to clarify when creating the scope and timeline for feature refactoring and data migration. 

SaaS also changes the billing process. Along with the base license fee, you pay for the cloud resources that you use. To avoid unpleasant surprises, loop in the finance team early on to go over the consumption-based pricing options for SAP Commerce Cloud, how SAP monitors and reports cloud usage , and the available dashboards to track monthly cloud costs .

Carrying over too many customizations from on-premise SAP Commerce

A big benefit of the SaaS delivery model is that it allows for frequent, backward-compatible releases so that there’s no more need for major version updates. SAP refers to this as “ continuous innovation ” and it allows them to release monthly updates to SAP Commerce Cloud .

Standardization is key to this continuous innovation model, and why you can’t make changes to the core platform services in the SAP Commerce Cloud architecture . Adding custom functionality requires using an extension that is compatible with the core platform services. This can be an optional SAP extension, a third-party extension, or an extension you build yourself using the SAP Business Technology Platform . 

Any customization you want to carry over from your on-premise SAP Commerce application will require the resources to rebuild it as an extension, maintain it, and test it against the monthly platform updates.

This can be a big investment, and the migration is a chance to take a critical look at existing customizations, standardize where possible, and reduce the time and resources spent on platform maintenance. 

Check if equivalent functionality is now available out-of-the-box

For companies that have been using SAP Commerce for years, there’s a good chance that some customizations made early on could now be replicated with features that have since been released. Here’s a high-level overview of the features added to SAP Commerce Cloud over the past 6 years , update notes for the quarterly release of new features in the SaaS offering , and a summary of the features added to Commerce Cloud in 2023 . 

Be pragmatic about refactoring vs standardization. 

It’s easy to fall for the sunk cost fallacy when it comes to customizations. One way to combat this is by creating a system to quantify and compare the impact each customization has on key areas such as productivity, customer experience, support for business-critical processes, or financial advantage. 

This scoring can help with more candid decision-making about which customizations offer a big enough benefit to justify the cost of building and maintaining a new extension and when it makes more sense to adjust processes to fit the core Commerce Cloud features—even if that means abandoning previous investment. 

Make new extensions easy to maintain 

Most businesses will have some unique needs that do require custom extensions. Creating these extensions with the best practices for SAP cloud development in mind will help avoid building up a complex web of customizations that cause errors every time the core platform updates.  

The SAP Business Technology Platform (SAP BTP) provides a framework for creating extensions without disrupting the performance and core processes of SAP Commerce Cloud. Using SAP BTP, businesses can create SAP extensions as independent services so that changes to one extension won’t impact the performance of another. Making it easier to adapt services to changing business needs. 

Underestimating the data challenge of an SAP Commerce Cloud migration  

Not factoring in enough time and resources to migrate data to cloud infrastructure is a major culprit for project delays, and shifting over massive amounts of unchecked legacy data can lead to unnecessarily expensive cloud bills. 

Make data compatible with Azure SQL database

On-premise SAP Commerce supports the use of different databases (e.g. SAP HANA, Oracle, mySQL) but SAP Commerce Cloud requires the use of the Microsoft Azure SQL Database. Which means a Commerce Cloud migration often involves moving to a new database.

The scope of this project can vary widely depending on your current data schema, the amount of data being moved, and the external dependencies of your on-premise application. It's common to work with external SAP experts to support the data migration process. 

Here are some tips from the SAP community on best practices when migrating data to Commerce Cloud: 

• On-premise data to cloud data . A look at database mapping between different databases and Azure SQL. (Note: This article was written before the release of Commerce Cloud 2211, the fully SaaS version, so the descriptions of SAP’s product offerings are outdated.) 

• Lessons learned migrating to Commerce Cloud . Some examples of troubleshooting errors that came up during commerce data migration. (Same note as above.)

• Combined upgrade and migration approach . An overview of a migration project plan using SAP Commerce DB Sync to streamline the move from source database to target database. 

• Migrate media to SAP Commerce Cloud - A guide to using the Microsoft AzCopy tool for media migration from an on-premise source to Azure Blob storage . 

Clean up tech debt before migration  

Audit existing assets and processes to avoid wasting time migrating obsolete data and wasting money on the cloud resources needed to host it. 

Working with a cross-departmental migration team is especially useful in this step to help identify duplicate records, outdated content, unused features, and opportunities to simplify and consolidate workflows. 

Put a plan in place for ongoing data maintenance

To keep costs low and performance high it’s important to make sure that, post-migration, unnecessary data isn’t allowed to build up over time. 

To help stay on top of data maintenance, it’s good to map out the regularly generated technical and transaction data in your SAP Commerce Cloud deployment and set up preemptive data retention rules for common processes and workflows. 

Not taking advantage of the SAP composable commerce offering 

The SAP Commerce Cloud composable offering opens the doors for SAP customers to modernize their eCommerce strategies, as it allows companies to mix and match SAP Commerce Cloud capabilities with functionality from other software vendors. 

With a composable commerce approach teams can choose best-fit solutions for different parts of the commerce experience and connect them via APIs so that it’s easy to add, replace, or remove capabilities as business needs change. 

SAP Commerce Cloud is now composable-ready, and companies that don’t include composability in their migration plan are leaving a big business advantage on the table. 

Start by going headless  

In a headless setup , backend systems only communicate to the frontend (the head) via standardized APIs. This “decoupling” allows teams to make changes to the frontend without worrying about disrupting backend processes, and vice versa.

Going headless is typically the first step towards composable commerce because it allows for quick, continuous frontend improvements while backend systems can be updated or replaced at a more moderate pace. 

SAP does offer an API-based frontend, SAP Commerce Cloud, composable storefront , which can be a great way to get started with a headless approach. However, it’s designed to primarily work with SAP products so as companies start to add more third-party tools to their composable tech stack they’ll likely need to find an alternative to SAP composable storefront . 

One option is to use a Frontend-as-a-Service (FEaaS) solution, like Alokai , that provides infrastructure, common components, and key integrations with other composable tools. With FEaaS, developers don’t have to recreate the wheel and can focus on building the frontend features that are unique to the business. 

Explore other SaaS tools for best-fit functionality 

With composable commerce you aren’t locked into a set of features from any particular tool. You can use the parts of SAP Commerce Cloud that fit your business, and can replace other parts with third-party solutions that better support your use case. For example, using other SaaS cloud solutions to leverage AI-powered search , to add new payment options , or even replace SAP SmartEdit with a more flexible headless CMS . 

The API-based flexibility of a composable commerce approach also means that companies can make this transition gradually. Adding or replacing functionality doesn’t require a complete code rewrite, but just means rerouting the relevant APIs. Allowing businesses to modernize the commerce stack in iterative steps , instead of a major replatform project every few years. 

Alokai is modern, composable frontend for SAP Commerce Cloud  

Alokai is a frontend-as-a-service (FEaaS) solution that has everything needed to quickly launch flexible, high-performing storefronts with SAP Commerce Cloud . Teams can halve the time-to-market of new storefronts with prebuilt, fully customizable frontend components that cover the full user journey from homepage, to checkout, to user account management. 

It’s an especially powerful solution for SAP customers moving towards a composable commerce approach . Along with an API-first architecture that makes it easy to connect any backend service to a storefront, Alokai offers pre-built integrations with the leading customer experience tools and a unified data layer to connect and orchestrate data across your composable tech stack. 

If you’re thinking about going composable with SAP Commerce Cloud, don’t hesitate to get in touch to see if Alokai is the best-fit for your business.