Migrating Custom Checkout Fields From NCR Retail Online

When NCR Retail Online was discontinued, retailers had to move their online shops and operational data to another ecommerce environment. For many businesses, the hardest part was not copying product records or customer names. It was preserving the extra checkout fields that supported delivery, fulfilment, trade accounts, store collection and customer communication.

Custom fields often carry important context that standard platform migrations overlook. A note about a rural delivery, a business purchase order number, a preferred store, or a customer’s consent choice can affect how an order is processed. If these details disappear during a move to Magento, WooCommerce or another platform, staff may face manual work and customers may receive the wrong service.

A careful migration treats checkout as a business workflow rather than a collection of boxes on a web page. The field label, stored value, validation rule, visibility, privacy status and destination in the new system all need to be understood before the first live order is placed.

Plan The Field Migration

Begin by creating an inventory of every custom checkout field in the old NCR Retail Online store. Include fields shown to guests, signed-in shoppers, trade customers and staff. Record where each value was stored, whether it was mandatory, and which teams used it after an order was submitted.

Some fields may appear to be redundant but still support reports, warehouse instructions or customer service. Others may have been introduced for a temporary campaign and no longer deserve a place in checkout. Speaking with store managers, warehouse staff and the accounts team can reveal dependencies that are not obvious in the ecommerce administration panel.

A useful migration register includes the old field name, its purpose, data type, sample values, required status, customer visibility and proposed replacement. It should also identify the owner responsible for approving the mapping. This creates a reliable reference when developers configure the new checkout and when staff test the result.

If customer accounts are recreated as part of the move, account records must be handled separately from checkout data. The process should cover passwords, consent and duplicate profiles; practical guidance on account creation guide workflows can help teams define that boundary.

Map Legacy Data To Modern Fields

Modern ecommerce platforms usually offer standard fields for names, addresses, phone numbers and delivery instructions. Use those native fields wherever possible. A standard field is more likely to work with tax calculations, shipping modules, reporting tools and future integrations than a custom text box carrying the same information.

For fields with no direct equivalent, decide whether the data belongs in the checkout, the customer profile, the order record or an external system. A preferred retail location may belong to the customer account, while a one-off delivery note should remain attached to the order. A business registration number may need to be available to accounts staff without being displayed publicly.

Data types deserve close attention. A postcode should be stored as text rather than a number so leading zeroes are preserved. A yes-or-no consent choice should not be migrated as free-form wording. Dates, phone numbers, purchase order references and loyalty identifiers should each have a defined format.

Australian addresses also require sensible local handling. A customer in Wagga Wagga, Geelong or Perth may enter a suburb, town or locality that does not fit assumptions designed around overseas address models. State abbreviations, four-digit postcodes, apartment details and regional delivery zones should be tested against the carrier and tax systems used by the new store.

Rebuild Checkout Forms For Clarity

Recreating every old field exactly can make checkout slower and less accessible. Review the reason each field exists, then redesign the form around the customer’s task. Use clear labels such as “Business purchase order number” rather than internal terms that shoppers will not recognise.

Conditional fields can reduce clutter. Show a company registration field when a shopper selects a business purchase, or display a collection-store selector only when “Click and Collect” is chosen. On mobile screens, which are widely used by Australian shoppers comparing prices on the move, a shorter form can reduce abandonment.

Decide which fields are required based on operational need rather than convenience. A delivery instruction might be optional for metro Sydney orders but useful for a farm or remote property. Mandatory fields should have a plain-language explanation, and error messages should identify the correction without wiping previously entered information.

Payment data should never be copied into ordinary custom fields. Card details, tokenised payment references and gateway responses belong in the payment provider’s secure workflow. Before configuring a replacement gateway, review payment gateway guidance so custom checkout data does not become mixed with sensitive payment information.

Protect Privacy And Operational Accuracy

Checkout fields can collect personal information even when they seem harmless. Delivery notes may reveal accessibility needs, while a birthday, membership number or communication preference can identify a person. Catalogue each field against the business purpose, restrict staff access and remove values that are no longer needed.

Australian retailers should consider the Privacy Act and the Australian Privacy Principles when transferring customer information to a new platform or hosting provider. The privacy notice should explain why information is collected, how it is used and whether third-party services receive it. Consent wording should be recorded distinctly from general marketing preferences.

Security also depends on the surrounding configuration. Use HTTPS, strong administrator authentication, least-privilege permissions and secure API connections. Do not place private customer notes in order comments that are automatically exposed to a warehouse, courier or customer email unless that visibility is intentional.

Notifications require their own mapping. A field used to route an order to a particular store may need to appear in an internal email but not in the customer receipt. A carefully designed notification planning process helps confirm which values belong in order confirmations, dispatch notices and staff alerts.

Test The Australian Customer Journey

Testing should use realistic scenarios rather than a single successful checkout. Create test orders for guest shoppers, returning customers, business buyers, gift recipients, Click and Collect customers and people requesting delivery to regional areas. Check the storefront, administration panel, warehouse view, email templates and reporting output for every submitted value.

A Victorian address, a Queensland postcode, a parcel headed to Tasmania and a remote Northern Territory delivery can expose different validation or freight rules. Test mobile browsers as well as desktop devices, and include slower connections that may occur outside major city centres. Confirm that fields remain usable with keyboard navigation and screen readers.

Payment, tax and shipping tests should be completed together. Check that Australian GST is calculated correctly, that a discount does not alter a custom value, and that shipping integrations receive the suburb, state and postcode in the expected format. Test failed payments, abandoned checkouts and edited orders as well as successful transactions.

A controlled user acceptance test is valuable before launch. Ask people from customer service, fulfilment, finance and retail stores to process defined scenarios and explain what they expect to happen. Their feedback can reveal that a field is technically migrated but displayed in the wrong place or absent from a report they rely on every day.

Launch With A Controlled Cutover

Choose a cutover window that gives staff time to monitor orders without competing with a major sale, public holiday or seasonal rush. Australian retailers should take care around periods such as Boxing Day promotions, EOFY activity and Christmas dispatch deadlines, when a small checkout problem can create a large support queue.

Freeze changes to legacy fields before the final export and keep a dated backup of the source data. Reconcile record counts, compare sample values and document any fields deliberately excluded. If the old platform must remain available for reference, restrict access and make its status clear so staff do not enter new orders in the wrong place.

After launch, monitor field completion rates, validation errors, payment failures, fulfilment exceptions and customer support contacts. Compare these measures with the old store where possible. A sudden drop in purchase order numbers or delivery instructions may indicate a hidden form problem rather than a change in customer behaviour.

Practical checks before switching traffic include:

• Confirm every retained field has an owner and a destination
• Test Australian addresses, GST, shipping and store collection
• Verify private data is excluded from unsuitable emails and reports
• Keep a rollback copy of the original customer and order records

Post-launch review should continue beyond the first day. Check orders after a week, then again after the first major promotion. Remove fields that produce no useful business outcome, refine help text where shoppers hesitate, and update internal procedures when the new platform changes how staff view or edit an order.

A second checklist can keep ownership clear:

• Customer service verifies labels, errors and account behaviour
• Fulfilment verifies delivery notes, collection locations and order exports
• Finance verifies tax, purchase orders and payment reconciliation
• Marketing verifies consent records and communication preferences

The move from NCR Retail Online is an opportunity to simplify checkout while preserving the information that keeps an Australian retail operation running smoothly. The essential task is to understand each legacy field, give it an appropriate home, protect its data and prove its behaviour through realistic testing. What the reader should remember is simple: migrate the business meaning behind each field, not merely the field itself.