Shopify retirement
LiveView onlyMigration contract · nothing switched off yetProven in prototype7the model works over seeded data; no live integration
Proposed1approach stated, nothing built or verified
Evidence needed2current behaviour must be captured first
Not started2no replacement in any form
The proposed order pathHow an order reaches Business Central after the shop closesProposed
What stays. The existing app and the new website front end are retained. What changes is where they read from and where their orders go.
Where they read from. Both read from mCentral's own store: identity, catalogues, pricing, buying lists and budgets come from the records on this platform, not from Shopify.
Where orders go. A small Business Central ingestion module is proposed to accept mCentral orders as sales orders over the API. This bypasses Shopify as the relay: the shop stops being the way an order reaches Business Central.
Every unknown the proposal depends on:
- API access to the Business Central environment: not verified
- Authentication for a server-to-server write: not agreed
- The order payload against the sales order schema: not specified
- A live write, even in a sandbox company: not attempted
Everything in this card is proposed. Stating the approach is Phase 0 doing its job; nothing above is a claim that any part of it has been built or tested.
The fulfilment return path, separatelyHow a customer sees despatch and tracking after the shop closesNot started
Today. Today the customer sees despatch and tracking because Business Central writes fulfilment state back into Shopify (Sync BC Documents on, Create Fulfilled Orders on). Switch the shop off without replacing this and orders still flow, but nobody outside the building can see where their delivery is.
After retirement. After retirement, mCentral OPS reads posted shipments and fulfilment events from Business Central and shows despatch and tracking on the app and website itself.
Why it is its own row. Order creation and fulfilment write-back are two integrations with two directions and two failure modes. The proposed ingestion module covers order creation only; proving it proves nothing about this path.
Proof still needed: the read path for posted shipments out of Business Central, the source of tracking references, and one real order's despatch reaching a customer with Shopify out of the loop.
The replacement register12 dependencies, each with its own proof
| Dependency | Today: what Shopify owns | Owner after retirement | State | Proof still required |
|---|---|---|---|---|
| Company identityOwner: mCentral platform ownerShopify today: read and write | Shopify holds a B2B company record per customer, synchronised from Business Central with order import (Report 30100 Shopify Sync Customers, job queue widely in Error at audit, PP-002). Business Central remains the customer master. | mCentral OPS company records, with Business Central as the accounting master. | Proven in prototype | A live read of the Business Central customer table over a supported API, and a reconciliation of every Shopify company record against it with no orphans.Prototype surface: Companies |
| Location identityOwner: MSC operations ownerShopify today: read and write | Shopify company locations carry the per-location settings the shop runs on: assigned catalogue, checkout review and metafields. Business Central holds the ship-to addresses, and the fulfilment site is the customer's Location Code. | mCentral OPS site records: head office with child sites, each with its own configuration. | Proven in prototype | A mapping of every Shopify location and Business Central ship-to onto exactly one mCentral site, with the unmapped remainder listed and resolved.Prototype surface: Sites on the evidence account |
| Authentication and session ownershipOwner: mCentral platform ownerShopify today: read and write | Shopify's Customer Account API mints the sign-in token, the customer portal sits on a Shopify App Proxy, and the session is the signed proxy query string. Shopify owns who can sign in. | mCentral OPS owns identity outright: accounts, sessions and devices. | Not started | A decided identity approach, a migration plan for every active sign-in, and a proven login that never touches Shopify. No decision is recorded yet.Prototype surface: Identity & access |
| CataloguesOwner: MSC commercial ownerShopify today: read | The catalogue each location can buy from is a Shopify catalogue assigned to that location. | mCentral OPS product range with per-site catalogue assignment, read by the app and the website. | Proven in prototype | The retained app and the new website reading catalogue data from mCentral's own store, with a parity check against what Shopify serves each location today.Prototype surface: Products |
| PricingOwner: MSC commercial ownerShopify today: read | The prices a buyer sees are served from Shopify price lists. The audit found that when two price lists reach one location the effective price can be wrong, so today's behaviour is itself part of the evidence. | The mCentral price authority: one precedence rule from site override to head office to published price. | Proven in prototype | A resolved-price parity run per site against the live shop, plus a decision on every conflicting price-list row the audit surfaced.Prototype surface: Pricing on the evidence account |
| Approved Buying ListsOwner: MSC commercial ownerShopify today: read and write | The list is maintained in mCentral and pushed to Business Central and Shopify; the shop reads it from Shopify location metafields at order time. | mCentral OPS holds the list and the shopfront reads it directly. The Shopify push, and the metafield read behind it, are retired. | Proven in prototype | The app and website buying screens reading the list from mCentral's own store, and a check that no order path still reads the Shopify metafield.Prototype surface: Buying list on the evidence account |
| Budgets and categoriesOwner: MSC finance ownerShopify today: read | Budget categories sit in Shopify location metafields and are read at order time; Business Central's budget extension reports after the spend. | mCentral OPS site budgets with the five categories, live during order build, optional per site. | Proven in prototype | Budget position read from mCentral's own store at the moment of checkout, and the Shopify metafield read retired without a gap in enforcement.Prototype surface: Budgets on the evidence account |
| CheckoutOwner: mCentral platform ownerShopify today: read and write | Ordering is a Shopify checkout: a draft order, a checkout review where the location requires one, then a completed Shopify order. | The retained app and the new website check out against mCentral's own store, on account, with the same review behaviour where a site requires it. | Proven in prototype | The prototype storefront checkout proves the model over seeded data. Still required: the retained app running the same checkout against mCentral's store, and parity with each location's live review behaviour.Prototype surface: Storefront checkout |
| Payment on account and approval rulesOwner: MSC finance ownerShopify today: read | Payment terms and checkout review settings are read from Shopify records per location; an order over the line pauses for checkout review. The exact live configuration of terms and review triggers has not been captured per company. | mCentral OPS approval rules: release holds into Awaiting approval with a work item, and payment on account against the customer's terms. | Evidence needed | A capture of the live Shopify payment-terms and review configuration for every company and location, so the replacement rules can be specified against fact rather than memory. The internal approval flow itself is already proven in prototype.Prototype surface: Approvals |
| ReportingOwner: MSC finance ownerShopify today: read | Any report that reads Shopify order or customer data depends on the shop staying up. Which reports those are has not been inventoried. | mCentral OPS reporting over its own store, with no Shopify read anywhere. | Evidence needed | A complete inventory of every report, export and consumer that reads Shopify data today, then a parity run of each against mCentral's figures. The reporting surface itself is already proven in prototype.Prototype surface: Reports |
| Order creation into Business CentralOwner: Business Central administrator with the mCentral platform ownerShopify today: write | Completed Shopify orders are imported into Business Central by the MS Shopify Connector (Report 30104 Sync Orders from Shopify, auto-create on, not auto-released). The job queue was widely in Error at audit (PP-002, a ten-character field cap, PP-022). Shopify is the relay. | Proposed: a small Business Central ingestion module that accepts mCentral orders as sales orders over the API, so orders enter Business Central without Shopify as the relay. | Proposed | API access confirmed, authentication agreed, the order payload specified against the sales order schema, then a first test write in a sandbox company. None of this has been attempted or verified. |
| Fulfilment and tracking write-backOwner: MSC operations ownerShopify today: write | Business Central syncs fulfilment state back to Shopify (Sync BC Documents on, Create Fulfilled Orders on), and the customer sees despatch and tracking through the shop. This is a separate integration from order creation. | mCentral OPS reads fulfilment state from Business Central's posted documents and shows despatch and tracking on the app and website itself. | Not started | A read path for posted shipments and fulfilment events out of Business Central, a decided source for tracking references, and one order's despatch reaching a customer with no Shopify in the loop. Distinct from the ingestion module: proving order creation proves nothing here. |
A screen existing on this platform proves a prototype, never a delivered integration. Each row closes on its proof column, not on its screenshot.
What the states are allowed to meanFour states, no others, defined once
| State | What it means, and no more |
|---|---|
| Proven in prototype | The replacement works as a prototype screen over seeded data. It proves the model and the workflow, not a live integration, live data or production readiness. |
| Proposed | An approach has been stated and nothing has been built or verified. Every unknown it depends on is still open. |
| Evidence needed | The replacement cannot be specified yet because the current behaviour has not been captured in enough detail. The next step is evidence, not code. |
| Not started | No replacement exists in any form, prototype or otherwise. |
Cutover: the exit gates, in orderNo gate opens without evidence; the order is the plan
| Gate | What has to be true | Owner | Evidence | State |
|---|---|---|---|---|
| G1 · Every read replaced | Identity, catalogues, pricing, buying lists, budgets and reporting all read from mCentral's own store, with a recorded parity check per dependency. | mCentral platform owner | Per-dependency parity records, kept against the rows above. | Not started |
| G2 · Order creation proven without Shopify | The proposed ingestion module, once accepted, creates a sales order in a sandbox company and then a controlled live order, reconciled line by line. | Business Central administrator | The sandbox sales order reference and the reconciliation. The module itself is still proposed, so this gate cannot open yet. | Proposed |
| G3 · Fulfilment return path proven | One shipped order's despatch and tracking reach the customer with no Shopify read or write anywhere in the chain. | MSC operations owner | The order reference and the customer-visible tracking record. | Not started |
| G4 · Reporting parity | A month-end reporting run reproduces its figures without a single Shopify read. | MSC finance owner | The two runs side by side, reconciled. | Not started |
| G5 · Identity migrated | Every active buyer signs in through mCentral's own identity; no session is minted by Shopify. | mCentral platform owner | The sign-in log for a full trading week with zero Shopify sessions. | Not started |
| G6 · Read-only trading period | Shopify is set read-only and MSC trades a full period on the replacements alone, with no regression in ordering, pricing, lists or reporting. | MSC operations owner | The period's exception log, empty of Shopify fallbacks. | Not started |
| G7 · Token revocation | Only after G1 to G6 close: API tokens revoked, apps removed, the shop archived. | mCentral platform owner | The revocation record. | Not started |
Shopify stays read-only before token revocation: every gate above must close with evidence while the shop can still be read, so there is always a way back until the last step. Nothing is switched off until then.
Grounding and evidenceWhere these facts can be checked on the platform
- The account-level evidence: Halewick Estates GroupThe observed account structure this contract is grounded in, with the same exit responsibilities on the record.
- The verified order route: SO-58214One verified order proves the current Shopify relay into Business Central. It does not prove every order follows it.
Owners above are role owners: no person is named because none is evidenced as owning a gate, and no dates are set because none have been agreed.