An ERP replacement can become a much larger project when someone assumes the online store must be replaced at the same time. The ERP programme already involves finance, purchasing, stock, customer accounts and reporting. Adding a new commerce platform also introduces a new customer experience, content migration and another launch to coordinate.
Sometimes a combined change is justified. But a new ERP does not, by itself, establish that the storefront needs rebuilding. The useful question is whether the existing commerce platform can support the future operating model through a maintainable integration.
For Australian and New Zealand retailers, wholesalers and distributors, OSE recommends making the retention decision explicitly. Assess the store against future requirements, separate unavoidable integration changes from optional website improvements, and plan how orders will be handled across the transition.
This guide helps business and technology leaders define that boundary before committing to a larger programme. It is a planning framework, rather than a promise of uninterrupted trading or a substitute for assessing your actual systems.
Key Takeaways
- A new ERP does not automatically require a new commerce platform.
- Assess future buying rules and integration maintainability before retaining the store.
- Plan open orders, stock, account pricing and historical references across cutover.
- Rehearse the transition and agree commercial go/no-go criteria before launch.
Separate the ERP decision from the storefront decision
Start with two short assessments. The ERP assessment explains what the business needs to change in its operating systems. The commerce assessment establishes whether customers can still buy effectively and whether the platform can support the new rules.
Keeping the store is worth investigating when the buying experience remains suitable, the platform is maintainable, and the required ERP interfaces can be implemented and supported. You may still need substantial integration work, data preparation and checkout changes. Retention does not mean leaving every component untouched.
A broader rebuild becomes more compelling when the store has its own material constraints: unsupported software, an unsuitable account model, inaccessible custom code or buying workflows that cannot reasonably meet the future requirements. Document those issues separately so the ERP change does not become the explanation for every unrelated improvement.
For the wider decision, see our eCommerce replatforming guide. Compare retaining and adapting the store with replacing it using the same business requirements, rather than assuming either option is automatically simpler.
Map what the ERP currently does for the online channel
List the business information and actions the store depends on. Include products, customer accounts, account prices, inventory, orders, fulfilment updates, invoices, credit status and returns. Identify the integrations and scheduled jobs that move each item, including manual steps staff have added over time.
For each flow, record the owner, direction, frequency, identifiers and expected outcome. An integration diagram is useful, but it should be supported by examples of an actual customer placing an actual type of order. That reveals rules a connector feature list may omit.
Pay particular attention to custom fields and background processes. A warehouse code may determine fulfilment, a customer flag may control payment options, or a nightly job may create a catalogue export. These dependencies can be easy to miss when the current system has been operating for years.
Our guide to choosing a commerce platform for your ERP provides context for evaluating the relationship. In a retention project, apply that evaluation to the platform you already have.
Check the future rules before selecting a replacement connector
Do not begin by asking whether a connector supports both product names. Establish the future business rules first, then ask the integration partner to demonstrate how the proposed connection implements them.
For a B2B distributor, that might include customer-specific product access, carton quantities, contract pricing and credit holds. A retailer may place more emphasis on multiple fulfilment locations, returns and stock allocation. A cross-Tasman business may need different company, currency and warehouse relationships for Australian and New Zealand orders.
Separate capabilities supported by the standard connector from configuration, extensions and custom development. Identify who maintains each part and what happens when either platform changes. A connector can accelerate delivery without covering the full operating model.
Ask for evidence using representative records, not only a generic demonstration. The goal is to establish whether the existing store can participate reliably in the new process and where its configuration or code needs to change.
Keep identifiers stable where practical and map changes explicitly
An ERP migration may introduce new product, customer or company identifiers. The store still needs a reliable way to recognise an existing item or account. Treat identifier mapping as a business asset with an owner, rather than a spreadsheet assembled during launch week.
Record the relationships between old ERP references, new ERP references and commerce IDs. Define how variants, pack sizes, customer locations and inactive records are handled. Where identifiers must change, plan the effects on integrations and reporting before importing the replacement values.
Review the information customers can see as well. Keeping the commerce platform may preserve much of the existing experience, but an import can still alter product names, availability, account access or public URLs. Protect content and URL behaviour deliberately instead of assuming platform retention protects them automatically.
Microsoft’s data migration guidance distinguishes configuration data from migrated business records and recommends planning mapping, validation and cutover activities. Use that distinction when assigning work between the ERP and commerce teams.
Make stock and fulfilment a business acceptance check
A successful stock import does not establish that customers can make the right delivery choice. Confirm how the new ERP calculates availability and how that value reaches the store. Include reservations, safety stock, warehouse eligibility, returns and units of measure.
For Shopify, locations and fulfilment configuration determine where inventory is tracked and how orders can be assigned. When an ERP replacement changes location references, review the corresponding commerce relationships instead of simply replacing the quantity feed.
In applicable Adobe Commerce implementations, stocks connect inventory sources with sales channels. Validate that mapping for the deployed architecture and the new ERP’s warehouse model; do not assume a shared warehouse name means both systems interpret availability identically.
Ask operations staff to verify representative products and destinations. Include an item that is unavailable, a split fulfilment and a product sold in a pack. Our inventory accuracy guide explains the wider controls behind a dependable stock promise.
Decide what happens to orders already in progress
The difficult boundary is often an order that began before cutover but finishes afterwards. It may be paid but unfulfilled, partially shipped, backordered or awaiting account approval. Define which system owns each state during the transition.
Create explicit rules for new orders, open orders, cancellations, refunds, returns and shipment updates. Decide whether older transactions remain in the legacy ERP, move to the new ERP, or require a controlled link between the two. The right answer depends on the ERP migration and financial processes.
Give each commerce order a traceable destination reference. Prevent the old and new integrations from independently creating the same order. A queued message or manual workaround must not become a second order when the new connection starts processing.
Keep customer service informed about where to find historical records. Staff should be able to explain an order’s status without searching several systems or asking the customer to repeat the full transaction history.
Use a transition architecture with clear boundaries
There is no universal cutover pattern. A coordinated switch may suit a business able to control a defined transition window. A phased rollout may suit distinct regions, entities or customer groups, provided the integration can route transactions unambiguously.
Where both ERPs remain operational temporarily, specify which one owns each transaction and data flow. Avoid uncontrolled dual writes. Shadow comparisons can help validate the new integration, but a comparison process should not accidentally trigger live invoicing, allocation or customer notifications.
Define what the storefront may do when an ERP dependency is unavailable. Some businesses can retain new orders for later transfer; others require live price, credit or availability validation. Agree the permitted behaviour with the commercial and operations teams rather than letting a technical timeout decide it.
Document the transition design in a form both delivery teams can use: system ownership, routing rules, pending-work handling and the point at which each integration is enabled or disabled.
Rehearse the cutover against measurable acceptance criteria
Run a rehearsal using representative migrated data and realistic buying scenarios. Follow an order from account access and price selection through payment or account terms, ERP acceptance, warehouse processing and customer status updates.
Include failure scenarios: an unknown product, a rejected account, a delayed transfer and a manually entered order. Confirm that staff can see the exception, understand its cause and recover it without duplicating the business action. The ERP integration recovery guide provides a practical investigation sequence.
Set acceptance criteria before the launch meeting. Examples include reconciled customer mappings, verified account-price scenarios, usable inventory values and traceable destination references for the trial orders. Record unresolved issues with their operational impact and an accountable decision-maker.
The rehearsal should also establish how long the transition steps take and which tasks depend on others. Replace assumptions in the launch plan with observed evidence wherever possible. A successful demonstration of one happy-path order is not sufficient launch evidence.
Define recovery before switching the live connections
A rollback plan needs more than a copy of the old connector. Specify the conditions that trigger a stop, who can make that decision and how orders accepted during the transition will be reconciled.
Once the new ERP has created transactions or operational teams have begun fulfilment, reverting configuration may not reverse those actions. Plan how to identify and resolve that state. In some circumstances a controlled forward recovery is more practical than returning to the previous arrangement.
Keep release records, configuration snapshots and recoverable backups appropriate to the systems involved. Confirm responsibility for each recovery step with the ERP provider, commerce partner and internal team. Avoid discovering during an incident that every supplier assumed another team owned the transaction reconciliation.
Compare the full programme cost before expanding scope
Compare two explicit scopes: retaining the store with the required integration and data changes, and replacing the store alongside the ERP. Include discovery, development, migration, validation, staff training, transition support and the effort required from your own team.
Retention can avoid a second platform migration, but extensive legacy customisation may reduce that advantage. Conversely, a desirable redesign may still be better delivered after the ERP transition, when operational rules and data are stable. Evaluate the dependencies rather than bundling projects for convenience.
For an ERP-specific example, our MYOB EXO to Acumatica migration guide explores a particular transition. Use product-specific discovery to establish the actual work; there is no reliable universal cost or timeline for changing an ERP integration.
After launch, compare operational outcomes with a baseline: unaccepted orders, manual handling, pricing exceptions, stock discrepancies and customer service enquiries. Completing the migration is a delivery milestone; sustained improvement requires separate evidence.
If an ERP programme is prompting a website rebuild decision, talk to OSE about reviewing the commerce dependencies. Bring the current architecture, target ERP and representative buying scenarios so the discussion can distinguish necessary integration work from optional platform change.
Frequently asked questions
No. Assess whether the current commerce platform can support the future buying rules and a maintainable connection to the new ERP. Integration, data and configuration changes may still be substantial. A rebuild needs its own justification based on the store’s limitations and future requirements.
That depends on which ERP services checkout requires and whether orders can be retained safely for later processing. Define the permitted fallback behaviour and customer promises before launch. Do not assume continued checkout means orders can already be fulfilled.
Set explicit ownership rules for paid, open, partially shipped and backordered transactions, as well as returns and refunds. Maintain references between commerce orders and the relevant ERP records. Staff need a clear way to find historical information and prevent duplicate processing.
It may cover part of the requirement. Validate customer accounts, pricing, inventory, units of measure, order states and exception handling using representative records. Separate standard capability from configuration and custom work, and establish who supports each part after launch.
Consider a combined programme when the existing store has material constraints and the future operating model requires a different platform. Compare the delivery dependencies, transition risk and total effort with a staged approach. The ERP change alone is not sufficient evidence that the store needs replacement.