Commerce cutover war room evidence checklist

Run launch weekend on evidence gates, not optimism, so you never lose an order, a payment reference, or a catalog record to a cutover nobody can prove went right.

Book discovery · Read integration services

In this guide

• War-room timeline
• Evidence gates by system
• Rollback and sign-off rules
• Build and testing checklist
• Monitoring and operating model
• FAQs

Cutovers fail on evidence, not on deployment

Cutover failures rarely begin at DNS. They begin when freeze rules, delta imports, queue drains, index rebuilds, payment callbacks, redirects, and rollback criteria are not tied to evidence. A launch weekend needs a war-room checklist that shows which system is frozen, which data moved, which queues are clean, which smoke tests passed, and who can stop the launch.

The checklist should be hour-by-hour because ambiguity grows under pressure. If the war room cannot answer whether orders, customers, catalog, payment references, search index, and redirects are in a known state, the site is not ready for traffic.

War-room timeline

cutover_timeline:
  t_minus_24h:
    - "content and catalog freeze confirmed"
    - "rollback owner and decision deadline confirmed"
  t_minus_12h:
    - "delta import rehearsal evidence reviewed"
    - "payment and OAuth callbacks validated"
  t_minus_4h:
    - "order export queues drained"
    - "search full index completed and sampled"
  t_minus_1h:
    - "DNS/redirect change prepared"
    - "support brief and incident bridge open"
  launch:
    - "checkout smoke"
    - "order export acknowledgement"
    - "payment settlement marker"
    - "search/category smoke"
  t_plus_2h:
    - "rollback decision or continue sign-off"

Evidence gates by system

• Commerce: login, cart, checkout, order confirmation, customer account, and support view.
• ERP/OMS: first order acknowledged, export queue clean, rejected order path visible.
• PIM/catalog: delta import complete, catalog version active, sampled product data correct.
• Search: full index complete, incremental index running, representative queries sampled.
• Payment: authorization, capture, webhook, refund path, and settlement marker validated.
• Redirects/DNS: primary domain, legacy redirects, callback URLs, sitemap, and robots behavior checked.

Data state decisions before launch

Cutover planning should name which records are migrated, which records remain in legacy, which records are read-only after freeze, and which records can still change during launch. Open carts, customer accounts, order history, wishlists, product media, prices, inventory snapshots, promotion rules, payment tokens, and support cases all have different risk profiles.

For each object, decide whether the target system becomes source of truth at launch, after a stabilization window, or only after reconciliation. Open carts may need expiry rather than migration. Order history may need read-only legacy access. Inventory may need a final snapshot plus event catch-up. Payment tokens may need provider-controlled migration or reauthorization. Search may need a full rebuild after catalog delta, not before. These are business decisions with technical consequences.

The war room should also know which jobs are paused. A legacy export that keeps running after target launch can overwrite target state. A target import that starts too early can publish stale data. A search job that runs against the wrong catalog version can make a successful cutover look broken.

Smoke tests that count

A smoke test counts only when it proves a business outcome. Loading the homepage is not enough. The cutover smoke should include login, product detail, category/search, add to cart, checkout, payment authorization, order confirmation, ERP or OMS acknowledgement, support lookup, and a redirect from a legacy URL. If B2B is in scope, include account selection, permissions, price visibility, and checkout approval.

Each smoke test should record timestamp, tester, market, device or channel, order or product id, expected outcome, actual outcome, and screenshot or dashboard link. The evidence log matters because teams otherwise retest the same paths repeatedly while missing the failed downstream state.

Rollback and sign-off rules

Rollback criteria must be binary. Examples: checkout failure above threshold, paid orders missing order creation, ERP acknowledgements blocked, search index unusable for major categories, or authentication callback failure on production host. The war room should know whether rollback means DNS revert, feature flag, integration pause, job rollback, data restore, or manual order intake.

Sign-off should be staged. Technical sign-off says the platform is running. Integration sign-off says order, payment, catalog, search, and support flows are traceable. Business sign-off says trading can continue. Support sign-off says customer-facing teams know what to say. Do not collapse those decisions into one “go” message.

What to test before launch

Run a cutover rehearsal with real timings. Do not just dry-run deployment. Freeze content, run a delta import, drain queues, rebuild the index, validate payment callbacks, test redirects, create a smoke order, export it, and write the sign-off note. Then rehearse one rollback path.

Operate after go-live

The first two hours should be evidence collection, not celebration. Track order intake, payment/order mismatches, ERP acknowledgements, search zero-result spikes, login failures, cache errors, redirects, and support tickets. Keep the war room open until the business owner signs off on traffic, order, payment, and support signals.

Cutover roles that must be named

A cutover plan needs named owners, not team names. The cutover commander controls timeline and decision log. The business owner accepts customer-impact tradeoffs. The platform owner controls deployment, rollback, and runtime health. The integration owner controls queues, acknowledgements, and replay. The data owner controls imports, catalog versions, and sampled records. The payment owner controls authorization, capture, webhook, and settlement checks. The support owner controls customer-service messaging.

If any role is “shared,” the plan should name the primary decision-maker and backup. Launch weekends create too much pressure for informal ownership. The sign-off log should show who made each decision, the evidence they used, and the rollback deadline they accepted.

The same role list should be used during rehearsal. If a backup cannot make the decision in rehearsal, they will not be ready during launch.

Evidence log format

The evidence log should be simple enough to fill in during the war room. Use one row per gate: timestamp, gate name, owner, evidence link, affected market, decision, risk note, and next checkpoint. For example, “search full index complete” should include index job id, catalog version, sampled query list, owner, and sign-off. “payment callback validated” should include PSP reference, order code, webhook id, and settlement marker. “ERP acknowledgement confirmed” should include order code, ERP reference, queue state, and owner.

This log is not bureaucracy. It prevents two common launch failures. First, it stops the team from losing evidence when a problem appears later and people disagree about whether a gate passed. Second, it lets a new incident commander join the bridge and understand the state without replaying the entire launch conversation.

Rehearsal defects to fix before launch

Treat rehearsal defects as launch blockers when they affect evidence, ownership, or rollback. A missing dashboard field is a blocker if it prevents order export sign-off. An unclear support message is a blocker if customers may be charged during the cutover. A manual import step is a blocker if only one person knows how to run it. A rollback command that has never been executed is not a rollback plan.

The rehearsal should produce a defect list grouped by owner: platform, data, integration, payment, search, support, and business. Do not close the rehearsal until each owner has accepted or resolved their defects. This is where launch confidence comes from.

Aftercare window

Keep aftercare separate from the launch bridge. The launch bridge decides whether traffic can continue. Aftercare tracks the slower signals: refund mismatches, delayed ERP postings, search drift, seller or supplier tickets, abandoned checkout spikes, and customer-service themes. The aftercare owner should publish a daily evidence summary until the business agrees the new operating model is stable.

Cutover evidence checklist

• Freeze catalog, content, pricing, and integration changes with named owners.
• Rehearse delta import, queue drain, index rebuild, redirects, and payment callbacks.
• Define binary rollback triggers before launch day.
• Smoke test checkout, order export, payment, search, login, and support views.
• Keep a timestamped sign-off log with owner names.
• Hold post-launch monitoring until traffic, orders, payments, and support are stable.

FAQs

What is the most common cutover mistake?

Treating deployment as the cutover. Commerce cutover is also data state, queue state, search state, payment callback state, redirect state, and support readiness.

When should rollback be decided?

Before launch day. The war room should have thresholds and a decision deadline so the team does not negotiate rollback while customer orders are already flowing.

Who signs off after launch?

Business, operations, platform, integration, and support owners should sign off against evidence: traffic, checkout, order export, payment, search, redirects, and support signals.

Related pages

• Integration services
• Runbooks and monitoring
• Payment reconciliation
• ERP integrations
• Middleware and iPaaS

Assess cutover readiness.

CCI can review freeze rules, evidence gates, rollback triggers, and launch-room ownership before the weekend plan becomes a data-repair exercise.

Book discovery · See how we work