Suspensions vary by cause, and Shopify does not publish a single uniform procedure, so the first hour is spent confirming what still works rather than assuming. In most reported cases the storefront and checkout go offline first, while admin access continues for a period so the merchant can retrieve data. That window is not guaranteed and its length is not stated in advance, which is why export comes before every other task.

From the admin, three things typically remain reachable: the product catalog (exportable as CSV), customer records (also CSV), and order history (CSV, with a separate export per date range on large stores). Product images are the common trap. The CSV contains image URLs pointing at Shopify’s CDN, not the image files themselves. Those URLs generally keep resolving for some time after a suspension, but there is no published commitment that they will, so pulling the actual files down early removes a risk that is cheap to remove.

Two more items belong in the first hour: a copy of any theme customizations worth keeping as reference, and a full list of installed apps with their billing status, because app subscriptions bill through Shopify and stop when the store closes, taking their data with them unless each app offers its own export.

With the immediate exports secured, week one is a completeness pass. Product CSVs from Shopify carry titles, descriptions, prices, SKUs, variants, and image URLs, and WooCommerce can import that structure with mapping adjustments. Customer exports carry names, emails, and addresses, but not passwords: password hashes do not transfer between platforms, so every customer will set a new password on the new store. Planning the messaging for that now avoids a support pileup at launch.

Order history deserves more care than it usually gets. Tax records, warranty claims, and repeat-customer analysis all depend on it, and once the Shopify store is fully closed there is no second chance at the export. Downloading complete history, verifying row counts against the admin’s totals, and storing a copy outside the working project is an afternoon of tedium that removes a permanent loss.

The domain is the one asset a suspension does not take. If it was registered through Shopify, this is the week to confirm control of the registration and prepare to point DNS elsewhere. If it was registered independently, nothing changes yet; it keeps resolving to Shopify until cutover.

The build is not the long pole in this project. Underwriting is. A merchant leaving Shopify after a category-based suspension frequently cannot use the default WooCommerce processors either, because WooPayments and Stripe publish restricted-business lists of their own that overlap heavily with Shopify’s. The realistic path for a restricted category is often a high-risk merchant account, and those applications involve human underwriters, document requests, and timelines that commonly run one to three weeks.

That is why the application starts on day one, not after the build. Underwriters review the business’s website as part of the application, and a placeholder page with a clear product description, refund policy, contact information, and terms of service can carry the review before the full store exists. When the processor approval and the finished store arrive in the same week, the 30-day timeline holds. When the application starts in week three, the store sits finished and unable to take payment.

Week two is the build itself: WordPress and WooCommerce on managed hosting, a theme, and the catalog import. Managed hosting earns its cost in this scenario for a specific reason: a store launched under time pressure has had less testing than a store launched on a normal schedule, and a host that handles PHP updates, daily backups, and uptime monitoring removes a set of failure modes the owner has no spare attention for.

The catalog import runs from the week-one CSVs. Variants, categories, and image attachments each need a verification pass, because a mapping error that puts every product in one category is easier to catch on day ten than after launch. This is also the week to be selective: a suspension migration is a poor time to redesign. Matching the old store’s structure closely keeps the redirect work in week three simple and keeps the project inside the timeline. Refinements can follow once revenue is flowing again.

App replacements happen here too. Reviews, email capture, shipping calculators: each Shopify app either has a WooCommerce plugin equivalent or it does not, and the honest move is to launch with the short list the store actually needs rather than rebuilding the full app stack under deadline.

Shopify enforces a fixed URL structure: products under /products/, collections under /collections/, content under /pages/. WordPress does not use those paths, so every indexed URL needs a 301 redirect to its new equivalent or the store’s accumulated search rankings dissipate. The redirect map is a spreadsheet built from the product export, and it is the cheapest insurance in the project.

DNS cutover is scheduled, not improvised: TTL lowered in advance, the switch made at a low-traffic hour, and the old paths spot-checked immediately after. If the domain handled email through a Shopify-connected service, mail records get verified before the switch, because a store that launches while order confirmations bounce creates its own emergency.

Checkout testing waits on the processor approval and then becomes the week’s main event: a real transaction in every payment method offered, a refund pushed through end to end, and tax plus shipping rates checked against the old store’s behavior. A test order caught here costs nothing. The same failure in a customer’s cart costs the sale and some trust.

Go-live on this plan is quiet: DNS has switched, checkout has processed real test transactions, and the redirect map is live. The remaining work is watching. The first watch is orders themselves, checked daily against payment processor deposits, because settlement timing on a new merchant account often differs from Shopify Payments and the first payout can lag the first sale by several days.

The second watch is Search Console: crawl errors and 404s reveal redirect gaps one at a time, and fixing them in the first two weeks limits the ranking cost. The third is customer friction, mostly password-reset requests from returning customers, which the week-one messaging should have made routine.

A month after the notice, the merchant owns the software, the data, and the customer records outright, and the platform-permission layer that produced the suspension no longer exists in the stack. The processor relationship still carries rules, and hosting terms still apply, but no single company can close the storefront by email again.

On a suspension clock, the two clocks are the whole game: the build and the processor application have to start the same day. Boston Web Group has run this plan, and a call in hour one beats a call in week two. Bring us the suspension notice and we will start both clocks with you.