Introduction

Migration to the cloud has become increasingly popular in recent years as businesses look to take advantage of the cost savings and flexibility it offers. Enterprises consider migration of their order management systems to the cloud as it provides several benefits for enterprises, including increased scalability, flexibility, and infrastructure cost savings.

IBM Sterling Order Management (on-premises) data migration

IBM Sterling Order Management is a comprehensive order management software solution that tracks orders from creation to delivery as well as manages and processes the data associated with the order as it progresses through its life cycle. IBM Sterling Order Management Software provides cross-channel order orchestration capabilities that enable intelligent brokering of orders across many disparate systems. It manages all information, including order capture, inventory management, order fulfillment, and after-sales services and scheduling. It also offers real-time visibility into orders from all channels, allowing business users to dynamically alter order processes. IBM Sterling Order Management is also one of the few enterprise applications that allows customers to deploy the application on any deployment model of choice, whether SaaS, private cloud/on-premises, or public cloud. You may have heard us say – My Cloud, Your Cloud, Any Cloud.

In this article, we will explore what IBM Sterling Order Management on-premises data migration to the cloud entails and some of the key considerations for enterprises looking to make the move.

The IBM Sterling Order Management SaaS offering (OMoC) has additional data migration considerations and data retention policies to deliver services efficiently. The tools and processes mentioned below outside the IBM Sterling Order Management provided standard APIs/tools may not be feasible with the IBM Sterling Order Management SaaS offering(OMoC). Please reach out to us for advice and support on migration to the IBM Sterling Order Management SaaS offering(OMoC). 

The data that needs to be migrated in the Sterling order management application resides in the database and falls into three categories.

• Configuration Data: Business and system rules and configuration that are needed for Order management
• Master Data: Business Data such as Catalog, Customer Info, etc.
• Transaction Data: Orders, shipments, payment processing, etc.

The Transaction data usually contributes to the lion’s share of the application data.

The data migration strategy varies depending on the business model, order life cycle, timelines, cloud offerings, and other requirements. The approaches require implementing DIY processes using the IBM Sterling Order Management provided standard APIs/tools to accomplish the data needs. There are several key considerations that businesses should consider before embarking on a data migration project.

Fresh Start Approach:

In starting fresh w.r.t transactions in the new database, migration involves only moving the Configuration data and Master Data to the database on the cloud. This works for the use cases with a shorter order life cycle and infrequent use of the historical data.

There is a variation to this approach that involves moving the open orders to the cloud database after the migration. This variation is suitable for enterprises with short order fulfillment life cycles (0-2 days) and small volumes of open orders. This is not suitable for the use-cases with complex order life cycles. The open orders can be re-created in the new instance using the product-provided APIs such as createOrder. One of the major grocery retailers chose this approach to migrate only the open orders from their existing OMS instance to a new upgraded OMS instance on their private cloud infrastructure.  

IBM Sterling Order Management provides the following tools which can be used to perform the move.

DB Verify:
The dbverify tool can be used to generate and/or apply the OMS database definitions such as tables, sequences, and indexes.

Configuration Data:
Configuration Deployment Tool (CDT) can be used to apply the configuration changes. The CDT tool helps to export the configuration data from the Master Configuration as XML files. The CDT export can be imported into the database on the cloud using the CDT tool.

Master Data:
The master data details can be loaded into the OMS using the integrations built as part of the OMS implementation. For instance, item load from the external PIM system to load the catalog into OMS.

OMS also has a Master Data Upload feature that accepts the file with the specified template to load the data. The OOTB supports the Customer, Customer Price List, Item List, Item Category, and Item Price List. The feature can be extended to modify the templates and also add new entity uploads as needed. 

IBM Sterling Order Management ChangeDataExport and ChangeDataImport agents can be used to fully or partially migrate the configuration and master data to the target database. The agents work based on the configured sync profiles to export and process the required table groups. The delta export requires enabling Change Project Management.  

Alternatively, the DB tools can be used to export the required Master Data from the on-premises database and import it into the cloud database.

Transaction Data:

Even if we start with a clean transaction schema, some of the data classified under transaction tables might need adjustments. 

Examples:

• Inventory: When GIV is used. Inventory can be loaded to OMS using the full inventory sync from the locations. In both cases (GIV or IV), careful consideration is needed if the inventory supply data must be adjusted to offset the demand from the existing order management system.
• Inventory resource pool/Ship node capacity consumption: In case capacity consumption has to be adjusted, capacity overrides can be used to set the available capacity for certain dates if it differs from the standard configuration.
• If open order re-creation is feasible for the OMS solution as explained above, order re-creation can be considered.

Lift and Shift Approach:

 This is appropriate for use cases that want to begin cloud migration while retaining all data. This approach presents the challenge of migrating larger amounts of transaction data from on-premises to the cloud. Though you can still take advantage of the cloud infrastructure and monitoring tools, the on-premises data quality issues continue.

The terabytes of data from the on-premises database can be exported using robust database tools. For instance, IBM DB2 has a robust export tool that saves the data as files, and Oracle database has an export datapump utility.

The exported data can be imported into the database on the cloud with a mix of cloud offerings and database tools. For instance, IBM Db2 on the cloud web console supports the import of smaller files. For larger files, tools such as IBM Lift CLI, DB2 Load, and the built-in External Tables functionality can be used to migrate gigabytes or terabytes of data securely to IBM DB2 on the cloud.

Hybrid Approach:

This approach suits use cases where the order life cycle is of moderate longevity, like extended returns, and has generous warranty terms. Depending on the customer service requirements, this entails migrating only the most recent data (say, the last 2-3 years). The transaction data can be more than a decade old. Customer service often does not need to use older data.  

If the closed orders need to be imported for future exchange/return purposes, they can be processed using the OMS importOrder API.

Data Preparation Considerations:

Before migrating data to the cloud using “Lift and Shift” or “Hybrid” approaches, businesses should ensure that their data is properly pruned. This starts with evaluating the database table sizes of on-premises data. For instance, some of the IBM Order Management database tables tend to grow if properly set up business data retention policies and corresponding purge processes are not in place.

A few examples below:

YFS_INBOX

Verify if the “Inbox Purge” is running without issues. If the table size is too large with the purge running, then the proper business processes or configurations are not in place to close the YFS_INBOX alerts in a timely manner. Consider auto-resolving the exceptions raised by the application program. Auto Resolution marks the YFS_INBOX entries as closed, which can then be removed by the purge processes.

YFS_REPROCESS_ERROR

Verify if the “Reprocess Error Purge” is running without issues. If the table size is too large with the purge running, then it means the re-processible exceptions are not resolved. For instance, there may have been an issue with integration with an external system, resulting in thousands (or more) of failures in OMS. The issue was then fixed, and the updates were republished to OMS. However, the failed exceptions were never addressed in OMS. These exceptions can be ignored, which closes the corresponding YFS_INBOX entries. The corresponding processes can then purge the records.

YFS_AUDIT, YFS_IMPORT, YFS_EXPORT

The data from these tables can be truncated if the old data is no longer used. Consider enabling the Export and Import Table purges if not already set up. 

• Order Audit Detail Purge à Order Purge can be extended to define Additional Purge Codes to remove the order audits (YFS_ORDER_AUDIT, YFS_ORDER_AUDIT_LEVEL, and YFS_ORDER_AUDIT_DETAIL tables) and YFS_ORDER_RELEASE_STATUS entries with zero quantities. This helps to delete the unnecessary records from the transaction tables before purging the orders.

Database Changes Synchronization:

When using the “Lift and Shift” and “Hybrid” approaches, the export and import processes can take time depending on the database size. Hence there is a need for synchronizing the latest data changes since the time a full export was taken.

IBM DB2 includes powerful tools such as IBM Data Replication, which enables CDC (Change Data Capture) replication, which captures database changes and sends them to target databases. The Oracle database also allows the CDC to capture the changes since the export using SCN (System Change Number) and deliver them to the target database. Using a combination of full data export and CDC, a seamless OMS switchover (with minimal outage) from an on-premises environment to a cloud environment can be achieved. One of the major North American retailers serving orders from across the globe chose this approach to extend the cloud benefits to the IBM Sterling Order Management application.

Conclusion

Overall, a successful enterprise application data migration requires careful planning, preparation, and execution. By evaluating the considerations outlined above, businesses can ensure that their Sterling order management data is moved safely and efficiently across environments, with minimal disruption to their operations.

IBM Expert labs team have successfully helped many Sterling order management customers in their upgrade and modernization journey. Reach out to us for IBM experts who can help you plan and complete your modernization journey and maximize the returns from your IBM Sterling Order Management software investment.

#SupplyChain
#Highlights
#Highlights-home
#OrderManagementandFulfillment