Orders

Migrated orders may not be a duplicate of the original. Please check them carefully when deciding how to use them for customer support or other operations. The total and product line item total should be correct, but the arrangement of promotions and adjustments may differ.

Ids

When using a custom migration for orders or an incremental migration for orders extra steps are needed to handle changes to the order_id. First, the order_id property should be removed from the migration yml file. Then something must be done for the order URLs, this may be a rewrite rule or some custom code.

For more information see the Potential ID conflicts section of the Known issues when upgrading from Drupal 6 or 7 to Drupal handbook.

Adjustments

In Commerce 2 shipping adjustments are on the order. Promotion adjustments, as of 2.7/2.8, are on the order item. Tax adjustments can be on either the order or the order item.

Adjustments calculation

It is not possible to migrate all the adjustments to be an exact copy of the original site. The are complicated and sometimes not all the data is available on the row. Therefor, many adjustments are prorated across all product line items.

In Commerce 2, v2.8, the calculation of the order item adjustment changed but it is still possible to use the older, legacy, method. Previously the adjustment calculation was applied to the order item unit price and now it is applied to the order item total price. See Order item adjustments are now calculated based on the order item total, not the unit price.

All the order item migrations in Commerce Migrate now use the order item total and set the property, uses_legacy_adjustment to FALSE.

Customize the Order States

Commerce 1

The order states are customized using a custom process plugin, two such plugins are provided CommerceOrderStateDefault and CommerceOrderStateValidation. The former is used in the d7_commercer_order.yml. If you are using validation, then change the plugin to commerce_migrate_order_state_with_validation.

If that is not suitable, you can write your own process plugin, using the existing two as an example.

Ubercart 6

To customize the order states to match your source data edit the order migration yml file. The migration uses the static_map process plugin to change the source state to the desired destination state. In the following example, if the source has a state of 'cart' it will be mapped to 'draft' and the new site will use 'draft' for this order. It is simple a matter of updating this map to suit your data.

state:
  plugin: static_map
  source: status
  map:
    checkout_checkout: draft
    checkout_review: draft
    checkout_payment: draft
    checkout_complete: draft
    cart: draft
    canceled: canceled
    # If you are using validation change 'completed' to 'validation' for the
    # pending and processing states.
    pending: completed
    processing: completed
    completed: completed