直接答案：先证明迁移能解决问题，再决定怎么搬
WooCommerce 迁移 Shopify 不是一次“导出再导入”，而是商务平台、数据模型、URL、应用集成和团队流程的共同切换。正确顺序是：先写清当前问题和迁移成功标准，再盘点数据与功能，制作逐 URL 映射，完成沙盒迁移和验收，最后才切换域名。若现有问题只来自主题、主机或插件管理，先修复 WooCommerce 可能比换平台更合理；若团队希望减少基础设施维护、统一商务后台，并且 Shopify 能承载关键流程，迁移才有明确依据。
Shopify 的官方 WooCommerce 迁移指南列出了人工复制、CSV、迁移应用、API 和专业服务等路径，也明确指出部分数据不能靠 CSV 完整迁移。因此，任何方案都应先回答“哪些必须原样保留、哪些可以重建、哪些依法或按业务规则只需归档”。
一、用业务目标约束迁移范围
不要把“系统更现代”写成目标。应把迁移动机转成上线后能够验收的条件，例如：运营人员可以自行管理商品与市场；订单能稳定进入 ERP；退款和税费字段可对账；主要落地页保留搜索入口；核心国家能完成真实支付和履约。每个条件都要有负责人、验收方法和失败时的回退方案。
| 决策维度 | 迁移前要确认 | 可验收结果 |
|---|---|---|
| 平台维护 | 当前故障来自主机、插件还是业务复杂度 | Shopify 目标架构确实减少对应维护项 |
| 商务能力 | 商品、促销、订阅、B2B、账户有哪些例外 | 关键场景在测试店逐项通过 |
| 国际业务 | 市场、币种、语言、支付、税费和物流边界 | 目标国家用真实地址完成端到端测试 |
| 数据 | 哪些对象必须迁移，哪些只需归档 | 数量、字段、关系和抽样内容可对账 |
| SEO | 哪些旧 URL 有流量、外链或业务价值 | 一对一映射、状态码、canonical 与内链正确 |
| 运营 | 谁负责商品、内容、订单、退款和权限 | 新流程有书面 SOP 并完成演练 |
若还没有业务需求清单，可先参考 WESWOO Shopify 服务范围整理发现、迁移、集成与持续支持的责任边界，而不是直接以应用清单代替需求。
二、建立数据清单，不假设所有字段都能平移
至少盘点商品、变体、SKU、图片、集合或分类、客户、同意状态、历史订单、退款、优惠、评价、博客、页面、政策、元字段和文件。记录源字段、目标字段、转换规则、是否必迁、数据所有者及验证方法。Shopify 的通用迁移说明提醒：产品应先于客户导入，历史订单再在产品和客户之后处理，才能尽量保持对象关系；历史订单、礼品卡、博客等对象的可用方法也不同。
产品 CSV 适合批量基础字段，却不等于完整迁移工具。按照 Shopify 的产品 CSV 说明，文件必须符合目标列结构，依赖缺失列的数据会报错。组合商品、订阅、定制选项、多语言字段、评论、复杂税类与插件自定义表通常要单独设计。客户密码不能被当作普通字段搬运；账户激活和隐私同意状态也应按目标平台及适用法规处理。
建议先迁移一组“难样本”：多变体商品、缺图商品、含特殊字符的 SKU、退款订单、游客订单、多个地址客户和下架内容。难样本通过后再跑全量，比先导入全部、再人工寻找异常更可控。
三、按用户旅程核对功能与集成
把 WooCommerce 插件清单翻译成业务能力，不要在 Shopify 中机械寻找同名应用。逐项检查商品发现、站内搜索、筛选、促销叠加、订阅、预售、账户、评价、税务、运费、支付、退款、客服、邮件、ERP、WMS、CRM 和分析。
每个集成至少记录：系统主数据在哪一端、同步方向、唯一标识、延迟容忍度、失败重试、重复事件处理、权限和告警。用“创建—修改—取消—退款”的完整生命周期测试，不能只验证创建订单。对长期运行所需的应用订阅、中间件、开发维护和人工处理计算年度总成本，而不是只比较 WooCommerce 主机费与 Shopify 套餐费。
跨境商店还应验证市场与支付资格，而不是假设迁移后自动获得所有本地能力。可结合 Shopify 跨境独立站上线框架建立市场、支付、物流和内容验收表。
四、把 SEO 当成 URL 迁移项目
迁移前导出旧站所有可访问 URL，并结合 sitemap、分析、Search Console、外链和收入数据确定优先级。为每个值得保留的旧 URL 指定最相关的新 URL；不要把大量商品、分类和文章全部重定向到首页。Google 的带 URL 变更的网站迁移指南建议先准备映射、更新内部链接、canonical 与 hreflang，再启用永久服务端重定向并提交新 sitemap。
Shopify 的路径结构往往与 WordPress 不同。按照Shopify URL 重定向说明创建并测试可支持的重定向，同时注意固定路径、仍返回有效页面的旧路径以及语言子目录等限制。上线前抓取预览站，检查 200、301、404、canonical、robots、hreflang、标题、结构化数据和图片。上线后继续监测未找到页面、重定向链、索引和主要查询；搜索表现短期波动并不能单独证明迁移成功或失败。
需要系统检查技术基线时，可使用 Shopify 独立站 SEO 实操清单，但最终 URL 取舍仍应由真实搜索、外链和业务数据支持。
五、用两次迁移和一次切换演练降低风险
第一次迁移用于发现字段与功能缺口；修正规则后进行全量彩排，并记录耗时、错误率、人工修复项和可接受的数据冻结窗口。正式切换前明确旧站停止写入时间、增量数据范围、DNS 与域名步骤、支付和邮件检查、客服话术、回退触发条件及决策人。
上线验收不应只看首页。至少覆盖主要市场的首页、集合、商品、搜索、账户、购物车、折扣、结账、支付成功与失败、订单通知、履约、取消、退款和退货。SEO 验收要从旧 URL 抽样到最终新 URL，确保没有循环、链式跳转或无关落点。旧系统和原始导出应按安全与合规要求保留可控的只读备份，不能在确认后立即销毁唯一数据源。
六、什么情况下应暂缓迁移
出现以下任一情况，应先补齐证据：关键订阅或 B2B 流程尚无可用方案；ERP/WMS 接口没有端到端测试；支付主体不符合目标市场要求；税务责任未确认；URL 映射缺失；团队没有内容冻结和回退窗口；总成本只计算了套餐而忽略应用、开发和运营。暂缓并不等于永不迁移，而是避免在未知条件下把风险转移给顾客。
迁移最终是一个业务取舍。将“保留并修复 WooCommerce”“分阶段迁移”“一次性切换”作为三个真实选项，比较三年的成本、风险和团队能力，再形成书面 go/no-go 决定。已经确认需要外部团队时，可查看 WESWOO 项目案例了解公开项目范围；任何案例结果仍应以获准披露且可核验的资料为准。
常见问题
WooCommerce 商品可以直接全部导入 Shopify 吗？
基础商品和变体可通过符合格式的 CSV 导入，但插件自定义字段、订阅、组合商品、多语言内容等未必能直接对应。先做字段映射和难样本测试，再决定 CSV、应用或 API 的组合。
历史订单一定要迁移吗？
不一定。客服、财务、保修、复购分析或法规可能需要不同保留范围。应由数据所有者确定哪些要进入 Shopify、哪些保留在受控归档系统，并验证查询与权限。
换到 Shopify 会不会自动保住 Google 排名？
不会自动保证。相关内容质量、逐 URL 映射、永久重定向、内部链接、canonical、sitemap 和上线监测都会影响迁移结果，且搜索系统重新抓取期间可能波动。
迁移期间必须停店吗？
不一定需要长时间停店，但必须设计数据冻结或增量同步窗口，避免旧站继续产生的新订单、客户和库存变化遗漏。窗口大小取决于数据量、接口和演练结果。
如何判断迁移已经完成？
只有当业务旅程、数据对账、集成、支付履约、SEO 映射和团队 SOP 都通过书面验收，并且严重问题有明确回退或修复路径时，才算完成，而不是域名能够打开就结束。