An ecommerce launch checklist for orders, stock and support

Establish a launch boundary

List the products, regions, payment methods and integrations included in the first release. State exclusions clearly. A hypothetical homeware shop may begin with domestic shipping and a smaller catalogue while trade ordering remains outside scope. This boundary helps the team decide which tests are essential and prevents an unfinished workflow from being mistaken for a live service.

Assign a decision-maker who can delay launch if a critical check fails. Record what counts as critical: incorrect totals, an inability to fulfil orders or exposure of private information should not be treated like minor cosmetic issues. Agree how lower-priority issues will be tracked and resolved. Launch readiness is a decision about acceptable risk, not the absence of every possible improvement.

Reconcile catalogue and stock data

Compare the source catalogue with the imported store. Check representative prices, variants, identifiers, tax treatment, images and descriptions. Verify that discontinued products do not remain accidentally purchasable. Stock counts need a confirmed source and update process; a visible quantity is not reliable simply because it appears in the new system.

Include awkward products in the test set: a single remaining unit, an unavailable option, a bulky item and an item with a special delivery rule. Ask operations to verify them. If product information is still being edited during migration, agree a freeze or reconciliation procedure. Otherwise a successful import can become outdated before the store is opened.

Exercise the full order lifecycle

Use the payment provider's permitted test facilities to check successful and failed payments, then plan any controlled live verification with the owner. Confirm totals, currency, discounts, shipping and tax calculations against the business's requirements. Never assume that one successful checkout proves every configured payment and delivery combination behaves correctly.

Follow the test order through notifications, fulfilment, cancellation and refund. For the homeware example, try a partially fulfilled order and a damaged-item enquiry. Confirm what the customer sees and what the operator must do. Avoid logging sensitive payment details in test reports. The important evidence is the expected status and reconciliation, not private credentials or card information.

Verify communication and support

Review order messages for accuracy, contact details and realistic expectations. Distinguish a payment confirmation from a shipping confirmation. Test the reply route and check that someone owns it. If support is handled through a shared inbox, agree access and coverage. A store should not invite questions through a channel that no one checks.

Publish clear policies supplied by the business and reviewed as appropriate for its obligations. Check links to delivery, returns and privacy information. Do not invent policy terms to complete a page. Where a process depends on manual approval, explain that boundary to customers. The interface should describe the real service, not a more automated operation the business hopes to have later.

Protect existing discovery and ownership

If replacing a store, map old product and category URLs to relevant destinations and test redirects. Preserve important content when it remains accurate. Check page titles, canonical URLs and the sitemap without creating duplicate homepage entries. Search engines should find the public catalogue, not checkout, account or internal test pages that expose an inappropriate journey.

Confirm owner access, backup or export arrangements and a recovery plan. Document how to disable purchasing safely if a serious order problem occurs. Agree the release sequence and who will monitor initial orders. Keep a list of changed settings so troubleshooting does not rely on memory. Recovery planning is particularly important when several suppliers own different parts of the store.

Store launch checklist

• Confirm first-release products, regions and exclusions.
• Assign launch approval and critical-failure criteria.
• Reconcile catalogue, prices, variants and stock sources.
• Test payment failure, fulfilment, cancellations and refunds.
• Verify customer messages, policies and support ownership.
• Check redirects, metadata and public sitemap destinations.
• Document access, recovery and initial-order monitoring.

Schedule a post-launch review that includes customer questions and operational exceptions, not only traffic. Record observed problems separately from proposed enhancements. This keeps the next iteration grounded in how the store actually serves buyers and gives the team a clearer basis for deciding what should be improved first.