Combined upgrade and migration projects also known as “single go-live approach” are challenging when it comes to planning the dependencies between upgrade and migration streams.

But if you ever wonder if it’s possible to deliver upgrade and migration in one GO, the answer is YES!

The article describes how the upgrade and migration streams can collaborate and how to increase the efficiency of tasks parallelization without compromising the quality.

The highlight of this blog is data migration using SAP Commerce DB Sync.

*Most of optimizations listed below is applicable when project team consists of at least two developers. Number of developers might vary depending the project scope, complexity and duration.

By default data and media migration is executed when upgrade phase is completed and code adaptation activities are in progress.

Below you can find few strategies to optimize the project plan and start preparation for data migration when the upgrade activities are still in progress.

This will ensure that all important steps are planned and executed well in advance and you do not have to worry about the project critical path. 

Environment Provisioning

Assumptions

Production-first approach assumes the first migration and then testing activities are executed in production environment.

In summary, this process is comprised of replicating the database schema as-is from source to target, migrating the data, then letting SAP Commerce apply mandatory type-system changes via Platform Update functionality during regular deployment.

This way, the requirement of having the source and target database in matching versions, is removed.

Although, at first glance this approach sounds like increased complexity, it has several advantages:

• It reduces the business disruption by having only one downtime window for both Upgrade and Migration.
• It also reduces the double-work necessary to go live On-premise and then again on the SAP Commerce Cloud architecture.
• It removes the need of running two UAT cycles. Significant impact on project duration and engagement of Business.
• Last but not least, it makes any rollback much easier, as there are no changes done On-premise.

This requirement can be fulfilled only if p1 environment is provisioned once SAP Commerce Cloud subscription access was provided to customer.

Read more about SAP Commerce Cloud environments provisioning using SAP for Me.

Source system preparation

To fully benefit from production-first approach, customer should be aware of their responsibility for source system preparation.

Customer should be enabled about their responsibility for data and media clean up at early project stage (ideally when the upgrade activities are in-progress).

This will ensure enough time for data preparation prior to the first migration run execution.

The following topics should be addressed to customer during project kick-off or later during data migration workshop:

• data cleanup (refer to Data Maintenance and Cleanup of a SAP Commerce Cloud Project for recommendations)
• data anonymization possibilities
• provisioning of production-like environment On-premise (in terms of data size)
• data size measurement (preferably with details about expected data growth rate)
  • identify whether “complex” data is in or out of scope (audit data, custom LOBs etc.)
• direct environment access for media migration process
• media size and consistency check, cleanup/reduction if possible

The workshop should result in action plan with due dates which can be tracked during regular project status meetings.

Infrastructure Setup

Another critical prerequisite for successful data migration is the infrastructure setup. Consider the following aspects as part of data migration workshop agenda.

VPN and NAT setup

Depending on customer’s requirements connection to source database might need to be established through secured tunnel.

Setup of mandatory networking adaptation needs to be applied both on SAP Commerce Cloud and On-premise systems.

Once completed, connectivity can be validated directly from DB Sync (refer to Data Source Validation).

Repository access configuration

Customer must provide essential repository access details. In case of non-publicly hosted repository (GitHub, Bitbucket etc.), previously configured NAT should also contain entry point for repository connection.

Repository structure needs to follow SAP official recommendations. Refer to Code Repository Setup and Build Guidelines for more details.

Lift & Shift Activities

Environments configuration (endpoints, redirects, DNS, SSL setup etc.) can be another example of the tasks that can be run in parallel to upgrade and/or code adaptations activities.

The configuration can be adapted on early project stage (assuming environments are provisioned) However, it’s not mandatory for execution of data migration.

Minimal Upgrade Scope Deliverables (deployable MVP)

The following activities must be completed by upgrade stream before any technical data migration-related activities can start.

In this scenario, assuming the activities below are completed, it is the earliest stage in the project where data migration is technically feasible.

• application configured with target version
  • complex customizations can remain disabled or mocked
• application can be deployed in SAP Commerce Cloud
  • only HAC extension along with SAP Commerce DB Sync included is required to be fully operational
• mandatory type system adaptations applied (optional)
  • to reduce risk of issues caused by type system differences in case if source database is not MSSQL
• it’s possible to generate type system initialization script for MSSQL database

Following the steps described above enables the first data migration run as early as possible.

Refer to SAP Commerce Cloud – DB Sync data migration safeguarding for more details regarding migration process.

Why is it so important to run the first migration at early project stage?

The main benefit of running the migration as soon as possible is a chance to fine-tune the entire process and to prepare for the most optimal execution during cut-over window.

Besides, first migration results should give the following outcome/findings:

1. Identify technical blockers (constraint violations, data inconsistency, DB engine specific issues comparing source vs. target)
2. Measure expected duration per table
3. Identify potential performance bottlenecks:
   1. analyze considerations for target database scaling (DTU on Azure SQL Database)
   2. analyze considerations for horizontal scaling for Background Processing aspect
   3. analyze considerations for source database scaling/tunning

For general recommendations regarding performance optimization of data migration process refer to Performance Guide.

This article does not include details regarding media migration. Please refer to Migrate Media with AzCopy

Go-Live Readiness in SAP Commerce Cloud

The section below provides additional recommendations for project planning.

Consider parallelization options depending on the project team size, project duration, budget.

Sequential Tasks

These tasks must go one by one. Adding more developers or parallelization at this stage does not optimize duration.

1. Adjust Code to build on the Target Version
2. Adapt Code Customizations to the Target Version
3. Adjust Code so the Application starts on the Target Version
4. Adjust Type System for the Target Version

Tasks which can be executed in parallel to other tasks

Consider adding more developers if possible to optimize project duration.

For complex projects where functional upgrade is involved, consider separate streams working in parallel to technical upgrade and migration streams.

1. Code Changes
   • Adapt vendor-specific database queries and data types
   • Backend to Azure Blob Storage (Hot Folders) & Cloud Hot Folders Configuration
   • Adapt File-based Integrations and access to local file system
   • Region Cache Adaptation
   • Data Hub upgrade (if applicable)
   • Integrate Customer’s SMTP solution
   • Image Resizing code solution
   • SOLR configuration and schema upgrade
2. Functional Upgrade Activities
   • Commerce Search to Adaptive Search
   • Cockpits to Backoffice
   • Smart Edit
   • Legacy Promotions to New Promotion Engine

To wrap up there is no ideal template of the project plan. Every project is unique and it is also driven by external dependencies.

Nevertheless, by applying the techniques recommenced in this article, project plan can be optimized and the risk of single go-live approach is reduced to minumum.