Resource / Migration
Migration Risk Kit
Use this before a WordPress or WooCommerce to Shopify migration. It turns search equity, URL history, redirects, metadata, analytics and app risk into named decisions before launch pressure starts.
How to use it
Treat the migration as a search-equity transfer, not just a rebuild.
A Shopify migration usually becomes risky when the old site evidence disappears before anyone has decided what to protect. This kit keeps the important decisions visible: which old URLs matter, which destinations must exist, which redirects need testing, which metadata rules need preserving, and which launch checks block go-live.
- Complete the evidence inventory before the old WordPress or WooCommerce site changes.
- Score each risk area from controlled to launch-risk so the team knows what cannot be ignored.
- Classify old URLs as protect, rebuild, consolidate, retire or investigate before redirect rules are written.
- Name owners for analytics, redirects, Shopify templates, collections, content and launch monitoring.
- Keep the kit open after launch so the first month is monitored by page type, not gut feeling.
Risk score
Score each migration risk before build decisions become expensive.
Use the score to decide whether an issue is safe to leave for normal QA or serious enough to block launch. A score is only useful when it has an owner, a due date and the evidence behind it.
| Score | Meaning | Action |
|---|---|---|
| 0 | Controlled | Evidence exists, owner is named, and the action can wait for normal QA. |
| 1 | Low risk | Evidence is mostly complete, but one check or owner needs confirming. |
| 2 | Medium risk | The issue could affect rankings, revenue, reporting or launch confidence if ignored. Assign before launch. |
| 3 | Launch risk | Do not launch until this is fixed, accepted in writing, or explicitly de-scoped by the project owner. |
Evidence inventory
Export what the current site has already proved.
Do this before themes, plugins, URLs, menus, redirects or tracking are changed. The old site contains the evidence that tells the migration team which pages, queries, links and journeys already matter.
| Evidence | Source | Why it matters |
|---|---|---|
| Top organic landing pages | GA4, old analytics, server logs | Shows which URLs already earn visits or revenue. |
| Search Console pages and queries | Google Search Console Performance export | Shows how Google currently understands each page. |
| Indexed URL inventory | Sitemap, crawl, Search Console, CMS exports | Prevents valuable old URLs disappearing during the build. |
| Backlinked URLs | Search Console links, Semrush, Ahrefs or similar | External links should land on relevant Shopify equivalents. |
| Revenue-driving URLs | GA4 ecommerce, Shopify/WooCommerce orders, CRM data | Some pages matter commercially even with modest traffic. |
| Metadata and SEO plugin data | Yoast, Rank Math, WooCommerce, CMS export | Captures titles, descriptions, canonicals, noindex rules and schema clues. |
| Important internal links | Crawler export and manual internal-link review | Shows which pages the old site architecture supported. |
| Existing redirect rules | WordPress plugins, server config, Cloudflare, host panel | Avoids dropping historic redirects or creating chains. |
Minimum viable export: top organic landing pages, Search Console pages and queries, full URL crawl, backlink targets, metadata export, redirect export and a benchmark of organic revenue or enquiries.
URL decisions
Do not map every old URL as if every old URL has the same job.
Redirect mapping fails when the team treats the spreadsheet as a technical import file only. The map is a decision log. Each old URL needs a reason, a destination and a priority.
| Decision | Use when | Migration action |
|---|---|---|
| Protect | The old URL has traffic, revenue, links, rankings or strategic value. | One-to-one redirect to the closest Shopify equivalent. Preserve intent. |
| Rebuild | The old page is valuable, but the new Shopify destination does not exist or is too weak. | Create or improve the Shopify product, collection, page or blog URL before launch. |
| Consolidate | Several old pages answer the same intent or now belong in one stronger destination. | Redirect to a stronger combined destination with matching user intent. |
| Retire | The old page is obsolete, low value, unsupported or has no useful equivalent. | Return a sensible 404/410 or redirect only where the destination genuinely helps. |
| Investigate | The URL has conflicting signals or unclear ownership. | Hold for review by SEO, owner or developer before launch. |
| Old URL type | Old example | Likely Shopify destination | Risk note |
|---|---|---|---|
| WooCommerce product | /product/example-product/ | /products/example-product | Check variant, out-of-stock and discontinued-product handling. |
| WooCommerce category | /product-category/example/ | /collections/example | Collections are often the most important migration destinations. |
| WordPress blog post | /blog/example-post/ | /blogs/news/example-post | Preserve informational intent and internal links. |
| Guide or landing page | /guides/example/ | /pages/example or a blog URL | Do not force useful guides into weak commercial pages. |
| Tag/archive page | /tag/example/ or /category/example/ | Collection, guide, blog index or retire | Most archive URLs need deliberate decisions, not bulk redirects. |
| Filtered URL | ?filter_colour=black | Usually no indexed Shopify equivalent | Rebuild as a collection only if search demand and catalogue depth justify it. |
| Media URL | /wp-content/uploads/example.jpg | Usually no public destination | Protect only if the asset has links or search value. |
| Legacy redirect | /old-product-name/ | Final Shopify URL | Avoid old-to-new-to-newer chains. |
Launch blockers
Agree what can stop the launch before the launch meeting.
A clean migration needs calm escalation rules. If everything is urgent, nothing is prioritised. Use the blockers below to decide what must be fixed, what needs sign-off, and what can move into post-launch monitoring.
| Priority | Blocker | Why it matters |
|---|---|---|
| P1 | High-value old URLs have no mapped destination. | Traffic and link equity can be lost immediately after launch. |
| P1 | Redirects point valuable pages to the homepage. | Google and users lose the original intent signal. |
| P1 | GA4, ecommerce events or Search Console verification are not ready. | The team cannot tell whether a launch problem is SEO, tracking or both. |
| P1 | Important Shopify pages are blocked, noindexed or canonicalised incorrectly. | New pages may not be eligible to perform. |
| P2 | Collection structure is still changing during redirect mapping. | Old category intent may be mapped to unstable URLs. |
| P2 | SEO plugin metadata has not been exported from WordPress. | Page-level titles, descriptions, canonicals and noindex decisions can be lost. |
| P2 | Apps are being installed without an owner or rollback plan. | Launch issues become harder to isolate. |
Page-type checks
Review the migration by page type, not only by URL count.
A store can pass a basic crawl and still lose performance if important collections, products or guides have changed intent. Use the checks below to keep each page type accountable.
- Product handle agreed
- Title and meta migrated or rewritten
- Variant handling checked
- Product media and alt text reviewed
- Unavailable/discontinued action agreed
- Old category intent mapped
- Collection description and H1 reviewed
- Filter/indexing rules checked
- Internal links rebuilt
- Priority collections included in launch QA
- High-click articles exported
- Old internal links updated
- Images and headings reviewed
- Author/date handling checked
- Commercial support links preserved
- Sitemap live
- Robots/noindex/canonical rules checked
- Redirect chains tested
- 404 report monitored
- Search Console submitted
- GA4 installed
- Ecommerce events tested
- Search Console verified
- Launch annotation added
- Monitoring owner named
- Native Shopify option checked first
- Duplicate SEO controls avoided
- Script/performance impact reviewed
- Rollback path known
- Owner named
Post-launch monitoring
The migration is not finished when the Shopify store loads.
Keep the monitoring plan open for the first month at minimum. Early movement is normal. Unexplained page-type drops, broken high-value redirects, tracking gaps and blocked Shopify destinations are not.
| When | Check | What to look for | Action if bad |
|---|---|---|---|
| Launch day | Golden URL redirect test | Top organic, backlink and revenue URLs redirect to the right Shopify destinations. | Fix P1 redirect rules before traffic is judged. |
| Launch day | Analytics and checkout test | GA4 traffic and ecommerce events are visible; test order paths work. | Fix tracking before calling any change an SEO drop. |
| Day 1 | Live crawl | 404s, blocked pages, canonical mismatches, redirect chains and internal old links. | Fix blockers and update internal links to final URLs. |
| Days 2–7 | Search Console watch | Sitemap processing, excluded URLs, crawl errors and top-page movement. | Prioritise issues on old high-value URLs. |
| Weeks 2–4 | Landing-page comparison | Important old page types have equivalent Shopify landing pages receiving traffic. | Improve destinations where intent or content depth changed. |
| Quarter one | Commercial page review | Collections, products, guides and resources are recovering or improving by page type. | Move from migration recovery into Shopify SEO improvement. |
Next step
Turn the kit into working files.
Keep the process here, then use the workbook and CSV sheets for the actual handoff between owner, developer, SEO reviewer and marketing team.