Limitations of staged upgrade

Upgrading Sterling Order Management System Software to release 10.0 using a staged rollout upgrade approach could have some potential issues. You may have to perform certain business and implementation evaluations to handle some of the data consistency issues.

There are certain limitations if you upgrade Sterling Order Management System Software to release 10.0 using a staged rollout upgrade approach. For example:

  • Data that is created in a newer version and modified in an older version can potentially have issues.

    For instance, if an order or a shipment or a record is created from a new version, then, modifying them from an older version can potentially have issues if the new version follows different business rules or process. For example, consider the following scenario where a ShipToHome order is created from a new version:
    • Case 1: A customer walks into a store S1 that is still using the older version, and change the Shipping Date or Shipping Address and if these functions are not changed during the implementation of the new version, then, the older version can handle the changes without any issues.
    • Case 2: A customer walks into a store S1 that is still using the older version, and change the delivery option from ShipToHome to PickAlternateStore and if the change of delivery type is not supported by the older version, then, the modification of the order from an older version can potentially have issues.

    In such scenarios, while rolling out a new feature in new version, perform complete business and implementation evaluation to check the data consistency for the older version. Also, perform regression testing for the older version data using new version's rolled out features. If any issues are encountered, Order Tagging feature can be used to control such functions on an older version. Refer Configuring order tags for sales orders to know more on tagging an order with a particular version.

    Sterling Order Management System Software supports controlling modification types based on certain conditions. Order version can be used as a condition to control modifications. Refer Defining custom modification types to know more on defining custom modification types for a process type.

  • Time triggered transactions are executed for only one version and it processes all the data. That is, if you decide to implement a new functionality related to a particular process, it is strongly recommended that you run the new version agent. For example, if you decide to roll out some change in payments, then the payment agents must be running for the new version.
  • Different versions cannot have different process flows. For example, pipelines, SDF components like events, actions, user exit implementations, business rules, resource permissions, resource hierarchy, and participant model.
  • New features that impacts the older version is not supported if the new version feature cannot be enabled independently. That is, if the new feature interferes in any way with an already running production feature, the roll out of the feature must be evaluated to ensure the data compatibility.