Ecommerce migration and checkout acceptance example
Prepared 17 October 2026 | Turing Websites

PURPOSE
Follow three synthetic product-variant rows from source data to a staging map,
then inspect the checks needed before a store release. All SYN references,
products, prices, quantities and paths are fictional teaching inputs.
This separate fixture does not supply the Aurora demonstration's product data.

WHAT IS INCLUDED
source-products.csv: three input rows, one variant per product in this example.
migration-map.csv: the outcome and reason for every source row.
products-staging.csv: two eligible rows with publication flags set to false.
redirect-plan.csv: all three old-to-new URL proposals and their eligibility.
redirects-staging.csv: two draft redirect candidates, both disabled.
checkout-acceptance.csv: ten checks with expected outcomes and blank evidence.
expected-results.csv: independent count and arithmetic controls.
validate-example.py: dependency-free Python validator, included in the ZIP.

Extract ecommerce-migration-example.zip into a folder. Open the CSVs as UTF-8,
comma-separated data, preserving text references and paths. To verify the
unchanged teaching fixture with Python 3, run:
  python3 validate-example.py --self-test
The validator reads local files and prints its findings. It makes no network
calls and writes no store, payment or platform records.

READINESS AND UNKNOWN VALUES
Ready means eligible for this staging dataset. Publication is a later decision.
The source has 3 rows: 2 ready and 1 held. The cup has SKU SYN-CUP-SAND, GBP 24.00
unit price and 8 units. The towel has SKU SYN-TOWEL-NAVY, GBP 18.00 and a checked
stock quantity of 0. Zero stock is valid data: the towel stays in staging with
out_of_stock availability, and checkout should prevent its purchase.

The apron row has an unknown variant SKU. Its source and map SKU remain blank.
It is held as MISSING_VARIANT_SKU and is absent from both staging files. Its
proposed destination stays visible in redirect-plan.csv, while TargetPath is
blank and Enabled is false. Resolve the SKU against the source before deriving
new staging outputs. Preserve unknown price or stock as blank too; a blank must
never become zero or an invented reference. The validator exercises these cases.

FIELD MAP
SourceRowRef -> stable row key throughout the example, prefixed SYN-ROW-.
ProductRef -> preserved product key, prefixed SYN-PRODUCT-.
Title, Variant -> preserved labels, with no generated product claims.
VariantSKU -> required unique variant key; blank means hold.
Currency -> GBP throughout; no conversion is performed.
UnitPriceGBP -> preserved two-decimal sample unit amount.
StockQuantity -> preserved non-negative whole quantity; 0 is valid.
OldPath -> FromPath on an eligible draft redirect.
PlannedNewPath -> preserved candidate product path; ToPath only when eligible.
Availability -> in_stock for a positive quantity; out_of_stock for zero.
Publish, Enabled -> false throughout this fixture.

These are platform-neutral staging columns, not a native Shopify, WooCommerce
or other platform import format. Map them to the selected platform's supported
schema in a preview environment. A fuller catalogue needs its own rules for
multiple variants, product grouping, media, categories, SEO fields and inventory
locations. Test those fields and permissions against the target platform.

RECONCILIATION CONTROLS
3 source rows = 2 ready + 1 held. Source stock 11 = ready stock 8 + held stock 3.
Staging contains 2 product rows and 2 disabled redirect candidates.
One ready row retains stock 0. All publication and redirect flags remain false.
Ready quantity x sample unit price is GBP 192.00: 8 x 24.00 + 0 x 18.00.
Held quantity x sample unit price is GBP 96.00: 3 x 32.00, outside staging.
These multiplication checks are not sales, profit or inventory valuations.
Two cup units give a GBP 48.00 merchandise subtotal. Shipping, tax and the final
checkout amount remain unknown and blank. Their treatment belongs to the
configured store and its delivery rules; this fixture calculates none of them.

CHECKOUT AND RELEASE ACCEPTANCE
Use a copy of checkout-acceptance.csv for the chosen platform's test store.
Every supplied status is Not run; ActualResult, EvidenceReference and CheckedAtUTC
are blank. The file describes work to execute, rather than completed results.
Record test references instead of customer or payment details.

Confirm product identity, price and inventory after import. Check zero-stock
behaviour and rejection of quantities above available stock. Compare the basket's
merchandise subtotal with the source before checking the configured final amount.
Use the chosen provider's sandbox success, decline and event-replay procedures.
Reconcile a successful test payment with exactly one test order and its test fulfilment
record; inspect the failed-payment path without creating a paid order.

For URLs, verify each candidate destination resolves in preview, each old path
maps once and redirects have no chains. The held row cannot enter a redirect
export. Activate redirects only with their corresponding published destinations
and the recorded release checks. Staged out-of-stock products may remain visible
where that is the chosen catalogue policy, with purchase controls checked.

Before cutover, record mobile/keyboard checks, the source backup, the agreed
inventory cutoff, reconciled counts, the redirect review, rollback steps and
the release decision. Keep staged products unpublished and redirects disabled
until the intended platform checks and release decision are complete.

VALIDATION SCOPE
The included validator independently derives the map, eligible products and
draft redirects, compares them with these files and recomputes the controls.
It checks the missing-SKU hold, blank-versus-zero handling, unique keys, safe
local paths, absence of redirect chains, false publication/activation flags,
blank unexecuted acceptance evidence and ZIP file integrity when available.
The --self-test option exercises deliberately invalid copies in memory.

This is a local data and acceptance-plan example. No store migration, provider
checkout, tax calculation or production redirect has been executed for it.
The Aurora demo's browser interactions are a separate preview, not evidence
that these platform acceptance checks have been run.