What should be tested before a Shopify Odoo connector goes live?

Test Odoo credentials, company selection, warehouse mapping, product matching, one normal order, one discounted order, one refund, one inventory update, one fulfillment update, and one intentional failure before enabling production volume.

Should Shopify Odoo sync launch all workflows at once?

Most teams should launch in phases. Start with connection, product matching, warehouse mapping, and a controlled order sample before enabling broad live order, inventory, fulfillment, and historical import jobs.

How long should the team monitor after go-live?

Review failed jobs daily during the first week, then compare Shopify and Odoo records after the first accounting close. The first week proves operations; the first close proves finance.

What is the biggest go-live risk?

The biggest risk is unclear record ownership. The team should know which system owns products, inventory, customers, orders, taxes, refunds, and fulfillment before any automated job writes production data.

Shopify Odoo Go-Live Checklist for Operations Teams

The go-live decision is operational, not only technical

A Shopify Odoo connector can pass a connection test and still be unready for production. The connection test proves that Shopify can authenticate, Odoo can respond, and the app can reach the ERP. It does not prove that the correct Odoo company was selected, that every Shopify location maps to the right Odoo warehouse, that taxes land on valid Odoo tax records, or that retries will not create duplicates.

The go-live checklist should therefore be owned by operations, finance, and the person responsible for the Shopify store. A developer or app installer can verify credentials. The business has to verify record ownership. If the wrong company receives orders, if Shopify stock pools into one warehouse, or if refunds do not reverse the right records, the integration may look successful while creating cleanup work.

This checklist is written for teams connecting Shopify and Odoo with Synco Connector. It also works as a general evaluation framework for any Shopify Odoo connector. The goal is simple: launch only after the team knows what happens to orders, inventory, products, customers, taxes, refunds, fulfillment, and failed jobs.

Phase 1: freeze the source-of-truth decisions

The first go-live risk is not an API error. It is a disagreement inside the team about which system owns which data. If the team cannot answer that question before launch, the connector will be blamed for conflicts that were never decided.

Decide these ownership rules before enabling production sync:

Shopify owns checkout, customer-facing order status, storefront merchandising, payment events, discount codes, and online order creation.
Odoo usually owns warehouse stock, company context, internal product identity, accounting records, taxes, purchase operations, and fulfillment operations.
Products may be Shopify-owned, Odoo-owned, or split by field. The team must decide this before broad product sync.
Customers may sync one-to-one into Odoo partners, or high-volume DTC orders may use a configured single-customer pattern.
Fulfillment may be Shopify-to-Odoo, Odoo-to-Shopify, or different by operational flow.

Write these rules into the implementation notes. The point is not paperwork. The point is that every later test needs a standard answer. If an order changes in Shopify after it has reached Odoo, what should happen? If Odoo stock changes after a cycle count, should Shopify update immediately or wait for a scheduled job? If a product title changes in Shopify and Odoo also has a different name, which system wins?

The connector can enforce the answer only after the business chooses it.

Phase 2: verify Odoo access and company context

Odoo credentials should be tested with the same user that production sync will use. A connection made with an admin account does not prove a restricted integration account can create sale orders, write stock moves, read products, or post accounting records.

Check these Odoo access items:

Odoo URL, database name, username or API key, and version are correct.
The account can read companies, warehouses, products, partners, sale orders, invoices, taxes, and stock records.
The selected Odoo company is the company that should receive Shopify orders.
Multi-company context is explicit. The connector should not rely on whatever Odoo marks as the default company.
Odoo version behavior is known. A connector that writes taxes or stock for v16 may need different payloads for v17, v18, or v19.

For multi-company Odoo, do not launch until one test order lands in the correct company and one inventory update reads from the correct warehouse. Multi-company errors are expensive because records can appear valid while belonging to the wrong books.

Useful supporting guides: Shopify Odoo allowed company IDs, Odoo API key for Shopify connector, and Odoo access rights for Shopify Odoo sync.

Phase 3: map warehouses and Shopify locations

Inventory go-live fails when the team treats stock as one number. Shopify has locations. Odoo has warehouses and stock locations. A serious launch maps those structures before live orders can change stock.

Create a location map with four columns:

Shopify location name.
Shopify location purpose, such as online store, retail, 3PL, pickup, or regional warehouse.
Odoo warehouse or stock location.
Whether inventory should sync for that pair.

Do not use a fallback warehouse unless the business has agreed to it. Unmapped Shopify locations should be excluded rather than quietly inheriting stock from the wrong Odoo warehouse. If a Shopify location can fulfill orders, the team should know which Odoo warehouse it corresponds to.

Test these cases before go-live:

One Odoo stock adjustment pushes to the correct Shopify location.
One Shopify order reduces stock through the intended Odoo flow.
One unmapped location is ignored or stopped clearly.
One product without an Odoo link creates a visible failed job instead of a silent stock mismatch.

For deeper planning, use the Shopify Odoo warehouse mapping guide, multi-location inventory sync page, and Odoo stock quant to Shopify inventory guide.

Phase 4: prove product matching before order sync

Order sync depends on product matching. If Shopify order lines cannot resolve to Odoo products, the connector has to create products, fail the order, or write incomplete data. None of those should be a surprise during launch.

Before live order sync, choose the product matching strategy:

Existing Shopify variants link to Odoo products through stored IDs.
Search-and-create uses SKU, barcode, or configured name search before creating new records.
New Shopify products are allowed to create Odoo product templates only if the catalog workflow permits it.
Odoo-to-Shopify product sync is allowed only for the fields the Shopify team expects Odoo to own.

Run a small product test set. Include a simple product, a multi-variant product, a product with a missing SKU, and a product that already exists in Odoo. If products use metafields or custom fields, test one real mapping and one invalid mapping.

The launch goal is not to sync every product immediately. The goal is to prove that the connector will not create duplicate products when the first real orders arrive.

Phase 5: test the exact order records finance expects

Do not let the first live Shopify order be the first serious order test. Order sync should be tested with the Odoo record type finance and operations selected.

Confirm these settings:

Shopify orders create draft sale orders, confirmed sale orders, sale receipts, draft invoices, or accounting-entry invoices as configured.
Paid-only sync behavior is deliberate if unpaid orders are excluded.
Customer strategy is correct: normal customer matching or single-customer mode.
Shopify order reference is visible on the Odoo record.
Payment status and method are visible where finance expects them.

Use this test set:

One simple paid order.
One unpaid or pending order, if the store has those.
One discounted order.
One order with shipping, tips, duties, or import fees if the store uses them.
One partial refund.
One order edit.
One duplicate webhook or manual retry.

The duplicate retry matters. A retry-safe connector should complete or skip safely. It should not create a second Odoo order because the same Shopify event arrived again.

For the underlying order model, read Shopify Odoo order record type guide, Shopify Odoo order sync guide, and Shopify order reconciliation with Odoo.

Phase 6: validate tax, refunds, and service lines

Tax and refund testing should happen before production, not during month-end close. A normal test order without tax proves very little.

Validate these cases:

Shopify tax lines map to configured Odoo tax records.
Odoo version-specific tax behavior is correct for the running Odoo version.
Discounts do not distort the Odoo tax base.
Shipping, duties, tips, and import charges land as intended service lines.
Partial refunds reverse only the refunded lines.
Full refunds remain traceable to the original Shopify order.

If a tax mapping is missing, the connector should stop the affected job and explain the missing mapping. Silent fallback is worse than a failed job because finance may not catch the mismatch until reporting.

Use the Shopify Odoo tax mapping page, Shopify Odoo tax sync guide, Shopify Odoo refund sync page, and duties and import fees guide for the detailed workflows.

Phase 7: test fulfillment and tracking in the direction you will use

Fulfillment can run in more than one direction. Some stores fulfill in Shopify or through a 3PL and need Odoo updated. Others fulfill in Odoo and need Shopify tracking updated for the customer.

Before launch, confirm the fulfillment source:

Shopify-to-Odoo fulfillment means Shopify fulfillment events update Odoo deliveries or pickings.
Odoo-to-Shopify fulfillment means Odoo delivery completion pushes tracking and fulfillment status back to Shopify.
Partial fulfillments should update only the fulfilled lines.
Tracking numbers, carrier names, and tracking URLs should land where the team expects them.

Test one fulfillment in the selected direction and one partial fulfillment if the store ships partials. Then replay the event. The connector should not double-fulfill.

Phase 8: prove queue visibility with one intentional failure

A go-live test set should include one intentional failure. This is how the team learns whether the connector is recoverable under pressure.

Safe intentional failures include:

Remove one product link from a test product.
Use an unmapped test tax.
Disable a warehouse mapping for a test location.
Use a restricted Odoo user in staging.
Trigger a duplicate event.

The expected result is a visible failed job with the Shopify reference, Odoo context, and error message. The team should know where to find it and how to retry after fixing the cause.

Do not launch a connector if the team has never seen the failure view. Happy-path demos do not prove launch readiness. Failed jobs prove whether operations can recover without asking a developer to read logs.

Use Shopify Odoo sync errors, retry failed Shopify Odoo jobs, and queue dashboard guide for the recovery model.

Phase 9: choose a first-week monitoring rhythm

Go-live does not end when the first order syncs. The first week should have a short daily review.

Review these items every day during week one:

Failed jobs by workflow: orders, inventory, products, refunds, fulfillment, and customers.
Orders in Shopify compared with records in Odoo for the same day.
High-velocity SKU stock counts between Shopify and Odoo.
Tax mapping errors and unmapped product errors.
Fulfillment events that did not send tracking back to Shopify.
Manual fixes the team still performed outside the connector.

This review should be short. The point is to catch mapping gaps before they compound. By the end of week one, the team should know which workflows are stable and which need configuration work.

The first accounting close is the second milestone. Finance should compare a payout sample against Odoo records after refunds, taxes, discounts, shipping, and payment status have all moved through production.

Final go-live checklist

Use this as the final launch gate:

Odoo credentials are valid for the production integration user.
Odoo version is detected and supported.
Correct Odoo company is selected.
Shopify locations are mapped to Odoo warehouses.
Inventory direction is explicit.
Product matching has been tested with existing products and variants.
Order record type is selected and tested.
Customer strategy is selected and tested.
Taxes, discounts, shipping, tips, duties, and refunds are tested.
Fulfillment direction is selected and tested.
One duplicate event has been retried safely.
One intentional failure has produced a visible failed job.
Historical import is scoped and separated from live order sync.
First-week monitoring owner is assigned.

When all of these are true, the launch risk drops meaningfully. The connector is no longer just connected. It has been tested against the workflows that make Shopify and Odoo difficult in production.