Shopify discovery audit: what must be clear before build starts

Discovery pays off once several systems, countries or teams depend on each other. If the data model, integrations and ownership are decided during development, every technical decision stays provisional and later change becomes expensive.

A simple theme relaunch with a clean catalogue does not need a multi-week audit. A move from Shopware or Adobe Commerce with ERP, PIM, B2B, SEO history and several markets does, because the visible store is only one part of the programme.

The audit starts with artefacts rather than opinions: system diagrams, app and contract inventories, data exports, API documentation, analytics, Search Console, support cases, process descriptions and real example records.

Interviews add context but do not replace evidence. A process is understood only when owners, triggers, data objects, exceptions and the expected result are visible.

Name one system of record for each object: product, price, inventory, customer, order, delivery, return and finance. Direction, trigger, frequency, failure path and replay can then be defined per flow.

Without that matrix, systems write against each other. Shopify, ERP and PIM may all be technically able to change a field, but organisationally only one should own its truth. That decision matters more than the connector choice.

The target architecture shows systems, responsibilities and data flows, not every future vendor. The scope then separates mandatory capabilities, later phases and explicitly excluded work.

Every scope item needs an acceptance criterion. “It works” is not one. An imported customer, B2B price, market switch or return must be testable with concrete data and an expected result.

SEO migration is not a launch-week checklist. URL inventory, information architecture, redirect rules, canonicals, hreflang, structured data and status codes affect the data model and content production throughout the build.

Cutover joins technical and organisational dependencies: freeze, delta imports, DNS, tracking, payment checks, redirects, inventory reconciliation and rollback. Every activity needs timing, ownership and a clear signal for success or cancellation.

The final pack includes the current system view, target architecture, data and integration matrix, prioritised scope, risk register, migration and cutover plan, acceptance criteria and an estimate with explicit assumptions.

Open questions do not disappear behind a broad estimate. They remain named as decisions, spikes or prerequisites, allowing an internal team, NICCOS or another supplier to plan the next step transparently.