Migrating NCR’s custom order statuses to match your new workflow

When NCR Retail Online was discontinued, retailers had to move their online shops to another platform, commonly Magento or WooCommerce through an NCR Counterpoint partner. Rebuilding the storefront is only part of that transition. Custom order statuses also need to be transferred carefully so staff, customers, inventory records and fulfilment systems continue to interpret an order in the same way.

An old status such as “Awaiting Counter Pickup” may have represented several actions inside the business: payment approval, stock allocation, warehouse preparation and a customer notification. A new platform may separate those actions or use different terminology. Treat status migration as a workflow design exercise rather than a simple export task, and the new system will support daily retail operations instead of creating another layer of confusion.

Audit the statuses you use today

Start by exporting the complete status list from NCR Retail Online, including statuses that appear rarely or are used only by particular departments. Include manual statuses, automated statuses, payment states, fulfilment stages, return conditions and any labels created for specific product categories. A lawn and garden retailer, for example, may have separate handling for bulky machinery, supplier-direct items and seasonal plants; those distinctions can be explored alongside the lawn and garden range when reviewing category workflows.

For each status, record who applies it, what event triggers it, which system receives it and whether it sends an email or SMS. “Ready for collection” may be triggered by a warehouse scan, while “Payment review” may be set by an administrator after a fraud check. This audit reveals duplicate labels, abandoned processes and statuses that staff use as private reminders rather than as reliable operational data.

Capture the status history attached to existing orders as well. Historical records may be needed for warranty claims, customer disputes, accounting checks or Australian consumer law enquiries. Even if the new platform cannot reproduce every old label, preserving the original value in an archive or migration field prevents important context from disappearing.

Design a clear status map

Create a mapping document with the NCR status, its new equivalent, the business meaning, the transition trigger and the customer-facing message. A useful mapping might convert “New” to “Processing,” “Stock Allocated” to “Picking,” “Counter Pickup” to “Ready for collection,” and “Dispatched” to “Complete” only when the new platform’s reporting rules support that choice.

Avoid matching words without matching behaviour. “Complete” may mean the order has left the warehouse in one system, while it means payment, delivery and customer receipt are all finalised in another. If a WooCommerce extension or Magento module introduces its own fulfilment statuses, document those separately from the platform’s core order state and decide which one should control notifications.

Keep internal and customer-facing language distinct where necessary. Staff may need “Awaiting supplier confirmation,” whereas a customer may simply see “We are confirming availability.” This is especially useful for Australian retailers managing regional freight from Melbourne to Perth or Darwin, where a short delay may reflect carrier scheduling rather than a problem with the order.

Rebuild the workflow in the new platform

Before importing live orders, configure the new state machine, permissions and automation rules. Decide which statuses can be changed by sales staff, warehouse users, customer service teams, payment gateways and shipping integrations. A status that should be system-generated must not be freely editable, or an accidental change could trigger a dispatch notice before stock has been packed.

Connect each status to the correct operational event. Payment approval should update the financial state, not automatically mark an order as ready to ship. A warehouse scan should update fulfilment, while a carrier tracking event should update dispatch. Returns should have their own path, such as “Return requested,” “Return received,” “Refund approved” and “Refunded,” rather than being forced back into the ordinary completion sequence.

Review the way stock is reserved and released. If an order moves from “Picking” to “Cancelled,” the inventory rule must return available units at the right moment. This matters during high-demand Australian sales periods such as Click Frenzy or end-of-financial-year promotions, when a delayed stock adjustment can create overselling within minutes.

Protect notifications and customer expectations

Every migrated status should be checked against its email, SMS or account-page message. Customers need accurate information about payment, dispatch, collection and refunds, while internal teams need alerts that contain enough detail to act. Remove messages that mention NCR Retail Online, old support addresses or legacy collection instructions.

Pay attention to Australian conventions. Display prices and refunds in Australian dollars, preserve GST wording where required, and use local spelling such as “authorised” and “organisation” in customer templates. If a Sydney customer selects store collection, the message should name the correct location, opening hours and identification requirements rather than relying on a generic “pickup” label.

Marketing and service communications should remain aligned with operational truth. A back-in-stock announcement or social campaign must not imply immediate dispatch if the new workflow includes a manual availability review. Teams that use external social growth tools should keep those promotional activities separate from order-state automation, so engagement metrics never become a substitute for confirmed inventory or payment information.

Migrate data safely and test edge cases

Use a staged migration rather than changing every order and integration at once. First create a test copy of the catalogue, customers and representative orders. Include paid and unpaid orders, partially fulfilled orders, split shipments, click-and-collect purchases, refunds, exchanges, cancellations and orders containing backordered products.

Run each example through the complete workflow. Check that the new system assigns the intended state, updates inventory once, sends the correct message and passes the appropriate information to Counterpoint, the payment service, the warehouse and the carrier. Test duplicate webhooks and delayed carrier notifications as well; integrations sometimes deliver the same event twice or deliver events out of sequence.

Set a cut-off point for old orders. Orders placed before launch may remain in the legacy system for reference, while open orders can be migrated with a controlled status and an original-status field. Reconcile order counts, totals, GST, payment references and stock quantities between systems. A short period of dual reporting can expose differences before the new workflow becomes the sole source of operational data.

Govern the new status model

A status system needs an owner after launch. Assign responsibility for approving new statuses, changing transition rules and reviewing notification content. Without governance, staff tend to create labels such as “Urgent,” “Call customer” or “Waiting on Jane,” which mix workflow stages with personal notes and make reporting unreliable.

Train teams by role rather than giving everyone the same technical guide. Warehouse staff need to understand scanning and fulfilment transitions; customer service needs to interpret delays and refunds; finance needs to reconcile payment and tax states; administrators need to manage permissions and integrations. Security training should be part of the programme, particularly when staff gain access to new APIs, payment tools or customer information. The guidance on ecommerce security protocols provides useful context for that part of the transition.

Monitor the first weeks with a dashboard showing orders by status, average time in each stage, failed automations, manual overrides and notification errors. A sudden rise in “Processing” orders may indicate a payment integration issue, while an unusual number of cancelled orders may point to stock synchronisation problems. Review the results with the Counterpoint partner and adjust rules carefully, keeping a record of each change.

A successful migration leaves customers seeing familiar, dependable progress even when the technology underneath has changed. Staff should know what each status means, systems should update one another in the correct order, and historical data should remain explainable. The key point to remember is that custom statuses are operational instructions, not decorative labels: map their meaning, test their triggers and govern them as part of the new retail workflow.