01 / METHOD
Define the parity surface
The migration is treated as an operating-system change, not a storefront swap. The relevant product, customer, order, search, payment, compliance and operational paths are made visible before they are moved.
CASE STUDY / PRE-LAUNCH VERIFICATION
A controlled verification record for a complex commerce migration. Production cutover has not been verified, so this page documents the constraint, method and current evidence scope only.
THE CONSTRAINT
CONSTRAINT / OWNERSHIP / CONTROLGrey Haze is a useful reference because the migration question is larger than a new storefront. The work crosses data, search, payments, compliance, platform ownership and the operating path after a build. Each of those areas can carry commercial risk if it is treated as a separate hand-off rather than part of one controlled system.
The brief is not to prove that one platform fits every merchant. It is to make the parts of the existing operation that must remain useful explicit, then test the target system against those requirements. That is the same discipline Hollow Point applies to an ecommerce migration assessment, whether the final recommendation is Medusa, a different owned architecture or an improvement to the current stack.
Grey Haze is currently in pre-launch verification. Production cutover has not been verified. That distinction matters: verification scope and observed checks are useful evidence; they are not a declaration that a production migration is complete.
THE VERIFICATION METHOD
METHOD / BEFORE ANY CUTOVER CLAIM01 / METHOD
The migration is treated as an operating-system change, not a storefront swap. The relevant product, customer, order, search, payment, compliance and operational paths are made visible before they are moved.
02 / METHOD
Records are checked through explicit mappings and exceptions. The question is whether the team can use the result, not whether an export technically completed.
03 / METHOD
URLs, redirects, canonicals, metadata, internal links and structured-data behaviour belong in the verification scope before a cutover decision is made.
04 / METHOD
Checkout, account, product, payment and operating flows need testing as connected journeys. A page that renders is not evidence that the system is ready to carry trade.
05 / METHOD
Any production decision needs named checks, monitoring and a rollback path. Pre-launch verification is evidence for that decision, not a substitute for it.
MIGRATION SCALE UNDER VERIFICATION
LEDGERED EVIDENCE / CURRENT SCOPEThe figures on this page describe the current pre-launch verification scope. They do not represent a production cutover, a completed migration or a promise of a comparable result for another merchant.
The evidence is intentionally narrow: a migration should be evaluated against its agreed parity criteria, real customer and operating journeys, and a release process that can be observed and reversed where necessary. When production cutover is independently verified, the proof ledger is the place to update the public wording first.
orders included in Grey Haze pre-launch verification.
line items included in Grey Haze pre-launch verification.
customer records included in Grey Haze pre-launch verification.
orphan records observed in current Grey Haze pre-launch verification.
WHEN THIS PATTERN IS RELEVANT
FIT / NEXT DECISION