结论：先证明确实该迁移，再讨论怎么搬
WooCommerce 迁移到 Shopify 不是一次“导出再导入”，而是商务规则、数据关系、URL、支付、履约、应用和团队责任一起换轨。真正的完成标准不是新首页能打开，而是客户、商品、订单、库存、金额、搜索入口和运营流程都能被证明；发生差异时，团队还知道谁可以暂停、谁批准补偿、旧站怎样进入只读或回退状态。
Shopify 的官方迁移总指南列出的路径包括手工复制、CSV、迁移应用、合作伙伴和 API。其 WooCommerce 专项指南也明确建议先导入产品，再导入客户，最后处理历史订单，让订单可以关联到目标商品和客户。把这条顺序当作起点，但不要把它误解为所有插件字段、订阅或交易都能自动对应。
| 结果 | 必须提供的证据 | 不能替代证据的假象 | 不通过时的动作 |
|---|---|---|---|
| 数据完整 | 源快照 = 创建、更新、跳过、隔离和失败的总和 | 后台显示“导入完成” | 生成差异集并暂停下游 |
| 关系正确 | SKU、客户、订单行、库存地点、优惠引用可追溯 | 只比较商品总数 | 修复映射后按批次回放 |
| 交易可运营 | 支付、退款、税、运费、履约和通知回放成功 | 测试订单能付款 | 隔离支付/履约并延迟切换 |
| SEO 可延续 | 旧 URL 台账、单跳 301、目标页面与 sitemap 检查 | 只检查首页 200 | 修复 URL、canonical 和内链 |
| 可恢复 | 冻结窗口、回滚负责人、补偿步骤和只读备份 | 只有一份 CSV | 保留旧站并执行恢复演练 |
本文只保留迁移项目的决策和运行边界；需要深入 API、批量作业和性能取舍时，可继续阅读Shopify 数据迁移工程指南。客户身份、同意、账户和隐私机制另见Shopify 客户数据迁移全指南，平台成本假设可对照Shopify 和 WooCommerce 价格与总拥有成本拆解。需要实施协作时，可查看 WESWOO 的迁移与建站服务和跨境电商知识中心。
留在 WooCommerce、修复现状，还是迁移到 Shopify
把平台选择写成有证据的决策，而不是品牌偏好。若现有 WooCommerce 能稳定承载关键旅程，而问题主要来自一两个可替换扩展，先修复并保留它可能更稳；若维护、托管、发布或市场扩展的瓶颈反复出现，再以目标运营模型和迁移风险作比较。任何一项“迁移”信号都不能抵消未解决的支付、税务、数据合规或集成阻断项。
| 决策信号 | 留在 WooCommerce / 先修复 | 迁移到 Shopify 的理由 | 需要的证据 |
|---|---|---|---|
| 业务目标 | 现有漏斗、市场和履约已达标，只需修复局部问题 | 发布、市场、团队运营或稳定性有可量化瓶颈 | 基线指标、事故记录、目标值 |
| 数据与扩展 | 关键字段依赖少数可维护扩展，且有可靠备份 | 扩展耦合、版本升级或主机运维造成持续风险 | 插件清单、数据字典、恢复演练 |
| 交易与履约 | 支付、税、库存、订阅链路在现有站可重复 | 目标市场需要新的支付、地点或运营控制 | 端到端回放、提供商资格、库存对账 |
| SEO 与内容 | 旧 URL 收益稳定，改动收益不足以覆盖重定向风险 | 站点结构、性能或内容治理问题需要重建 | URL 台账、日志、自然入口和改版方案 |
| 迁移准备度 | 无冻结窗口、负责人或增量方法 | 已完成彩排、差异有阈值、回滚可演练 | go/no-go 记录、时间线、回滚报告 |
这篇主文吸收迁移前的五个问题
迁移前必须连续回答五问：它要解决哪一个可量化问题？哪些数据和关系必须留下？现有功能与集成能否在 Shopify 中重建？旧 URL 与搜索信号怎样保住？能否在有限冻结窗口内安全切换并回退？这五问对应 post 9671 的前置评估意图，本文把答案落实为台账、映射、测试和验收门，而不是停留在观点。
迁移前五问：用证据做 go/no-go 决定
不要因为“WooCommerce 插件太多”或“Shopify 更容易操作”就直接立项。把保留 WooCommerce、分阶段迁移和一次性切换作为真实选项，比较三年的平台、主机、扩展、开发、维护、支付、SEO 风险和机会成本。任何关键问题没有证据，就标记为阻断项，而不是在预算中写“后续处理”。
| 前置问题 | 需要收集的证据 | 通过条件 | 暂缓信号 |
|---|---|---|---|
| 迁移要解决什么？ | 事故、维护工时、发布周期、结账漏斗、市场计划 | 有负责人和上线指标 | 目标只有“换平台” |
| 什么数据必须保留？ | 对象清单、保留年限、客服/财务查询、隐私请求 | 每个字段有去向 | 只说“全部迁移”却无字段表 |
| 功能能否重建？ | 插件能力、工作流、API、报价和失败路径 | 关键旅程在目标店原型通过 | 订阅、B2B 或 ERP 只有截图 |
| SEO 怎样连续？ | sitemap、日志、分析、外链、旧 URL 和新 URL | 每个高价值地址有唯一去向 | 大量 URL 统一跳首页 |
| 能否安全切换？ | 迁移耗时、增量方法、冻结窗口、回滚演练 | 停止阈值已签字 | 没有谁能按下暂停键 |
先写暂停条件，而不是先排发布日期
出现以下任一情况，应暂缓：支付主体或目标市场资格没有书面确认；税务责任尚未由财税负责人确认；ERP/WMS 的创建、修改、取消、退款链路没有端到端测试；关键订阅无法说明下一次扣款由谁发起；高价值 URL 没有映射；团队没有内容冻结、库存冻结或回滚窗口。暂缓是控制风险，不是放弃项目。
选择迁移路径并冻结项目边界
Shopify 官方 WooCommerce 指南把手工复制、CSV、Shopify Store Migration 应用、第三方迁移应用和迁移专家列为不同路径。小型基础目录可以用 CSV；包含扩展字段、历史订单、媒体关系、持续增量或严格审计的商店，通常要用应用、API 或自建转换层。路径可以混用，但每类对象必须有一个明确的主写入路径，禁止不同工具互相覆盖。
用范围矩阵防止“顺便重做一切”
将每个对象标为必迁、重建、归档或淘汰，并写出依据。把设计重做、内容重写、数据清洗、市场扩张和平台迁移拆成不同工作包。这样既不会把旧站错误结构原样复制，也不会在切换夜临时加入未经测试的新促销或新国家。
| 范围对象 | 迁移方法 | 负责人 | 验收证据 | 目标处理 |
|---|---|---|---|---|
| 目录事实：SKU、标题、价格、重量、变体、图片 | 产品 CSV/应用/API，按难样本先行 | 商品负责人 | SKU、变体和媒体抽样报告 | Shopify 产品、变体、媒体 |
| 客户关系：邮箱、地址、标签、同意、外部 ID | 客户 CSV + 身份/隐私专项流程 | 客户与隐私负责人 | 身份去重、同意和激活抽样 | 客户资料与受控归档 |
| 交易历史：订单号、行项目、金额、税、退款 | 迁移应用/API，或只读归档 | 财务负责人 | 币种、金额方程与退款对账 | 历史订单或只读仓库 |
| 商业规则：优惠、礼品卡、订阅、积分 | 原生重建 + 专项应用/保留旧系统 | 运营负责人 | 规则生命周期和余额/扣款回放 | 重建、专项迁移或保留 |
| 内容与入口：页面、博客、媒体、旧 URL | 内容导入 + 媒体审核 + 301 台账 | 内容与 SEO 负责人 | 内容抽样、爬取、状态码报告 | 页面、文章、文件与重定向 |
目标运营模型与差距分析：先确定谁在新店负责什么
迁移的目标不是把旧后台的菜单换一套，而是把“谁拥有事实、谁可以写入、谁处理异常”说清楚。为商品、价格、库存、订单、客户、内容、支付、税务和履约分别指定主责系统、备援系统、可接受延迟、审批人和服务目标。若目标店需要人工补偿、客服查询或财务导出，也要把这些工作写进 SOP 和培训，而不是假设应用会代替团队判断。
用能力差距表决定重建、替代或保留
逐项对比 WooCommerce 当前行为与 Shopify 目标行为：触发条件、字段、权限、通知、失败处理、报表和数据保留都要有样例。差距分为可配置、需要应用/中间件、需要开发、必须人工或暂不迁移；只有“看起来相似”的界面不能作为通过依据。
| 能力 | WooCommerce 当前事实 | Shopify 目标设计 | 差距与决定 | 负责人/证据 |
|---|---|---|---|---|
| 商品与价格 | 哪个插件或后台角色能改标题、价格、促销价 | 产品、价格目录和市场规则的主写入端 | 可配置/应用/开发/人工 | 商品负责人签字 |
| 库存与履约 | 仓库、预留量、在途量和拆单规则 | 地点库存、履约服务和 WMS 事件 | 补齐地点或保留 WMS | 供应链回放 |
| 订单与退款 | 支付捕获、退款、取消和客服权限 | 订单、支付提供商、财务和通知链路 | 重建状态与补偿流程 | 财务测试单 |
| 客户与同意 | 账户、营销同意、隐私请求和重复身份 | 客户账户、同意记录和受控人工路径 | 单独设计身份/隐私方案 | 隐私抽样 |
| 内容与 SEO | 页面构建器、翻译、短代码和重写规则 | 页面、文章、文件、模板、canonical 和 301 | 清洗/重写/归档 | 内容爬取报告 |
盘点 WooCommerce：先盘清源数据和运行中的插件
WooCommerce 的业务事实分布在 WordPress 数据库、wp-content、媒体库、主题、扩展表、订单元数据、定时任务和外部系统里。标准产品导出不代表覆盖订阅、礼品卡、组合商品、会员、评价、自定义字段或库存服务。先冻结一份插件与版本清单，记录每个插件的目的、数据表、事件、cron、外部账号、许可证和停用后影响。
WooCommerce 官方的REST API v3 文档提供产品、变体、客户、订单、优惠券等资源；产品导入导出说明说明内置 CSV、字段映射和自定义元数据导出。使用后台导出、REST API、数据库只读快照和人工访谈互相校验，不能把某一种导出视为事实源；导入/导出前先在 staging 或恢复副本上验证。
客户、订单和优惠券的 CSV 导出要特别标注扩展边界。WooCommerce 官方导出扩展文档描述的是安装该扩展后的能力，不是所有 WooCommerce 核心店铺都具备的统一保证；可用字段还会受自定义插件影响，大型导出应分批并对每批数量和金额做闭合检查。
建立对象、数量和关系台账
给每种对象记录源 ID、业务键、状态、创建和修改时间、关联对象、隐私等级、总数、导出方式、负责人和抽样方法。对订单另外记录游客订单、退款、取消、部分履约、税行、运费行、优惠券行和支付交易。对产品记录简单、可变、捆绑、组合、下载、预售和订阅类型。台账本身要版本化，并与导出文件哈希绑定。
| 数据域 | 盘点问题 | 最低输出 | 高风险例子 |
|---|---|---|---|
| 产品 | 属性、变体、SKU、媒体、分类和自定义字段在哪？ | 产品/变体/媒体数量与关系 | 变体选项超过目标模型 |
| 客户 | 注册、游客、重复邮箱、多地址和同意如何表示？ | 客户身份与同意清单 | 同邮箱多实体或无同意来源 |
| 订单 | 交易、退款、税、运费、履约和状态是否完整？ | 订单金额方程与状态分布 | 部分退款或多币种 |
| 内容 | 页面、文章、短代码、图片和下载是否依赖插件？ | URL、正文、媒体和模板清单 | Page Builder 短代码失效 |
| 运行面 | webhook、cron、缓存、搜索、邮件和 ERP 谁在写？ | 集成拓扑和停用步骤 | 双写或重复扣款 |
备份、隐私和可恢复性要先于第一次导入
WooCommerce 官方备份 WordPress 内容指出，完整备份至少包括数据库和 wp-content 文件夹；WordPress XML 不覆盖订单、产品和 WooCommerce 设置。迁移前应生成数据库 SQL、wp-content/媒体、主题与扩展版本、配置清单、CSV/API 导出、URL 台账、DNS 记录、支付与物流配置的加密副本，并存放一份离开生产主机的副本。
备份的价值要靠恢复证明。把 SQL 和文件恢复到隔离环境，打开产品、客户、订单、媒体、结账和订阅管理页，验证关键查询；记录恢复时间、缺失文件、权限和数据库版本。真实客户、地址、订单和 token 只保留必要人员访问，调试日志使用内部 ID、哈希和错误字段，不复制完整个人数据或支付凭证。
把目标店也当作需要留证的系统
Shopify 是托管服务，但迁移仍需保存目标店主题版本、产品/客户/订单导出、重定向 CSV、市场与翻译配置、应用设置、API 版本、导入结果和审核报告。不要假设后台撤销按钮等于完整回滚。每次执行生成 run_id、配置哈希和时间戳，让团队能回答“这一条数据由哪一轮规则写入”。
字段映射：把源模型翻译成可审计的目标契约
字段表至少包含源路径、源类型、目标对象和字段、必填性、枚举映射、空值处理、长度、单位、时区、敏感级别、主责系统、转换版本和验收查询。金额使用十进制和币种，不用浮点数；时间保留源时区、UTC 值和业务时区；HTML 清洗短代码、内联脚本和不再存在的媒体；SKU、外部订单号和邮箱分别定义唯一性，不能互相替代。
用不可变 ID 和语义哈希保证可重放
建立 source_system + object_type + source_id 到 Shopify GID、handle 或外部键的身份映射。SKU 会变、邮箱会改、订单展示编号可能带前缀，所以它们适合冲突检测，不应单独充当全局主键。每个规范化 payload 保存哈希；重跑先比较身份映射和语义哈希，再决定创建、更新、跳过或隔离。超时后先查询是否已成功，不能盲目重建。
| 源字段/事实 | Shopify 候选 | 转换规则 | 验收重点 |
|---|---|---|---|
| Woo product ID、SKU | Product/Variant 的外部映射与 SKU | 保存源 ID，SKU 重复则隔离 | 父子关系和 SKU 闭合 |
| 属性/variation | Options、variants、metafield | 规范化名称、值和单位 | 每个组合唯一且可售 |
post_content/短代码 | Product description、Page、metaobject | 清洗 HTML，短代码改为组件 | 无残留短代码和 404 媒体 |
| 用户 ID、邮箱、地址 | Customer、addresses、tags | 邮箱规范化，重复人工裁决 | 登录、地址、同意和隐私请求 |
| order number、line items | Order、line items、metafields | 保存源单号，不重算历史事实 | 币种、税、折扣和退款方程 |
商品、变体、媒体和库存要分层迁移
商品不是一行 CSV。先建立产品类型、属性、选项、变体、媒体、分类/collection、价格、库存和销售渠道的关系图，再迁移最复杂的样本。Shopify 的产品 CSV 导入说明提醒，CSV 会影响价格、重量、库存等经营字段；WooCommerce 导出的列通常需要编辑才能符合 Shopify 模板。Shopify WooCommerce 专项指南还注明，第一方 Store Migration 应用处于早期访问，并对超过三个产品选项的商品有明确限制；遇到这类商品要改用应用/API、拆成 metaobject 或重新建模，并在当前实施日重新确认限制。
Shopify 产品 CSV 还有依赖字段：变体数据变化时必须同时提供对应的选项列；缺少依赖可能生成默认变体或删除已有变体，所以正式导入前要在隔离店 dry-run，导入后做差异对账。多地点库存应使用库存 CSV，不能把单一产品的 Inventory quantity 当作所有地点的总量；优先用能保留更完整状态视图、减少意外覆盖的全状态格式，并逐行核对 SKU × 地点。产品元字段需预先定义，变体元字段不能通过产品 CSV 写入，应安排其他已审核路径。
先导结构，再导媒体、发布和库存
建议顺序是：产品类型和选项定义、产品与变体、媒体与 alt、集合/分类、价格与市场、地点和库存、销售渠道发布。媒体上传完成不等于资源可见，要检查状态、顺序、尺寸、alt、重复文件和目标页面引用。Shopify 的多地点库存说明强调各地点库存独立；总数相同但仓库错位，仍会造成错误承诺和履约失败。
客户、订单和账户：先保留关系，再谈界面
Shopify 的客户 CSV 文档明确：CSV 不能迁移其他商店的客户密码；导入后需邀请客户创建新密码，且客户 CSV 不能代替订单导入，也不会导入 Total Spent 或 Total Orders。客户 CSV 必须使用 UTF-8，单个文件当前有 15 MB 限制，只有已定义的受支持客户元字段可通过 CSV 导入；这些限制与字段支持应在执行日前按目标店复核。重复邮箱或电话需要按当前导入规则处理。迁移前决定使用新客户账户、旧客户账户、身份提供商还是受控的重新激活流程，并测试验证邮件、密码重置、地址和订单历史。
历史订单可通过迁移应用或 API 处理；Shopify 的迁移指南提醒，导入历史订单时，仍接收新订单通知的员工可能收到每一笔导入订单的邮件。导入前暂停不该触发的通知、Flow、ERP、营销和履约动作，导入后再按清单恢复。订单要保留源订单号、原始处理时间、币种、税、折扣、支付状态、履约和退款语义，而不是伪造一次新的实时交易。
以订单金额方程和客户身份验收
每条历史订单核对：商品行小计 − 折扣 + 运费 + 税费 = 总额，退款与已收款的关系也要对上；对多币种同时保存店铺币种和顾客展示币种。客户抽样覆盖游客、重复邮箱、多个地址、退订、隐私删除、历史订单和最高价值客户。只要客户能在后台看到记录，不代表营销同意、账户激活和客服权限都正确。
折扣、礼品卡和订阅是未来义务，不可顺手复制
WooCommerce 核心优惠券管理支持百分比、固定购物车和固定产品折扣，并有产品、分类、邮箱、最低消费、叠加和使用次数限制。Shopify 的折扣文档则区分折扣码、自动折扣、金额/百分比、买 X 送 Y 和免运费等方法。迁移时按规则重建，而不是只复制 code 和 amount；明确时区、有效期、适用范围、叠加顺序、已使用次数和客户分群。过期活动通常应归档，避免把旧优惠重新开放。
WooCommerce Gift Cards 扩展的预付礼品卡、商店余额和促销券不是同一件事；Shopify 的giftCardCreate需要相应权限，可创建带初始价值、代码、到期时间和客户关联的礼品卡。迁移前核对余额、币种、状态、到期日、已兑换金额和法律条款，并用一张真实测试卡完成购买、兑换、部分使用和退款。
订阅风险更高。WooCommerce Subscriptions 官方说明，订阅协议同时关联产品、客户、支付网关和一个或多个订单；付款 token 的可迁移性取决于网关。Shopify 的订阅合同模型由订阅应用管理 selling plan、合同、计费尝试和后续订单；其迁移客户信息指南强调可在不直接迁移信用卡的情况下迁移特定支付方式，并建议迁移期间暂停旧系统扣款，防止重复收费。
评价、店铺余额和法律存档也要单列。评价要保留作者、商品、星级、正文、创建时间、审核状态和同意依据，并检查目标评价应用是否接受历史导入；店铺余额要像礼品卡一样对账余额和使用记录；已完成订单的原始税务、付款和退款事实可放入受控只读归档，归档访问、保留期限和删除请求由财务与隐私负责人批准。不要为了让后台数量相等而伪造交易或把促销券当成可兑余额。
把订阅拆成新老客户两条路径
为每个订阅保存产品/变体、周期、数量、下次扣款时间、状态、优惠、配送、客户同意、支付提供商和重试策略。旧合同可以继续由旧网关短期扣款，新订阅走 Shopify 应用；或者在客户主动更新付款方式后切换。无论选哪条路径，都要测试首次扣款、续费、失败重试、暂停、跳过、换品、取消、退款、税和通知，并让财务批准扣款暂停与补偿方案。
页面、博客、政策与文件：内容资产也要能独立验收
产品迁移成功不代表站点内容完整。把 WordPress 页面、博客文章、作者、发布时间、分类、媒体库、下载文件、政策、表单、短代码、导航和模板逐项登记；标出由插件生成的内容、需要重写的组件、法律审批人和停用旧站后仍要保留的文件。隐私政策、退款/配送政策和市场特定条款应由业务或法务确认版本，不要由迁移脚本自动改写。
先恢复内容语义，再恢复视觉布局
将正文 HTML 中的短代码、嵌入、表单动作、图片相对路径、下载权限和内部链接转换为 Shopify 可维护的页面、文章、文件、元对象或主题区块。Page Builder 只复制渲染结果可能留下不可编辑的图片；更可靠的验收是作者能在目标后台更新内容，访客能在不同语言和市场打开它，表单提交也能到达正确的处理人。
| 内容资产 | 源端核对 | 目标处理 | 通过证据 |
|---|---|---|---|
| 页面/博客 | 作者、日期、分类、正文、短代码、草稿状态 | Page、article、blog 或重写组件 | 正文、元数据、媒体和作者抽样 |
| 政策/法律 | 市场、语言、版本、审阅日期、链接 | 政策页面与市场展示规则 | 业务/法务签字和结账链接 |
| 媒体/下载 | 文件路径、alt、尺寸、权限、引用次数 | Shopify 文件或受控外部存储 | 资源状态、权限、无 404 |
| 表单/导航 | 字段、收件人、同意文案、菜单层级 | 表单应用/中间件和导航 | 测试提交、邮件、内链爬取 |
SEO URL 台账：先收集所有入口，再设计新结构
WooCommerce 旧 URL 来自产品/分类固定链接、WordPress 页面、博客、媒体、语言插件、历史重写规则、sitemap、分析、Search Console、外链和服务器日志。抓取当前导航远远不够，因为排名页、广告落地页、旧活动页和带语言前缀的路径可能没有菜单入口。每一条旧 URL 记录状态码、最近流量、收入、外链、语言、目标意图、是否保留和最终新 URL。
一对一 301 优先于全站跳首页
Shopify URL redirect 文档支持后台或 CSV 导入重定向，但有固定路径、保留前缀不能重定向、仅对错误 URL 生效等限制，计划不同也可能有不同数量上限。把保留前缀列为台账中的显式例外，目标映射要在域名切换前导入并抽样验证。商品指向对应商品、分类指向对应集合、文章指向同意图文章；确实无替代且无价值的页面再按 SEO 和合规策略返回下线状态。检查编码、大小写、尾斜杠、查询参数、循环和链式跳转，确保一次 301 后目标 200。
| 旧地址类型 | 目标策略 | 需要保留的上下文 | 验收 |
|---|---|---|---|
| 商品/变体页 | 对应 Shopify product/variant 或主商品 | SKU、语言、市场和 canonical | 200、标题和购买路径正确 |
| 分类/标签页 | 对应 collection、搜索或内容页 | 原类别意图和内链 | 无无关首页跳转 |
| 内容/博客页 | 对应 page/article/blog | 作者、媒体、发布时间 | 正文、图片和 schema 正常 |
| 重复/参数页 | 选一个规范页，必要时过滤参数 | canonical、robots、活动参数 | 无爬虫循环和软 404 |
| 删除且无替代 | 经过审批的下线策略 | 删除原因与业务证据 | 状态、sitemap 和内链一致 |
多语言与 Markets：把语言、地区、币种一起验收
WooCommerce 多语言插件常把翻译、语言目录、税费、价格和产品 ID 组合在一起；迁移不能只把中文正文复制到 Shopify。先为每个国家/地区列出域名或子文件夹、默认语言、币种、价格、税显示、支付、运费、退货和可售商品，再映射到 Shopify Markets。Shopify 的Markets 文档说明市场可控制货币、语言、价格、商品可用性、域名和税等设置；语言与域名文档列出子文件夹、子域名和顶级域名策略。
Shopify 会依据市场和语言配置生成 hreflang、canonical 和国际 sitemap；自动地域重定向主要服务顾客，搜索爬虫会被排除，以便抓取各语言版本。仍要人工检查翻译覆盖、URL slug、邮件、结账、应用文案、右到左语言、市场回退和选择器。不要用 IP 强制所有访问者到同一语言，也不要假设同一产品在每个市场都拥有相同价格和库存。
以“国家 × 语言 × 旅程”做本地化样本
至少选每个核心市场的一条首页、一条集合、一条高收入商品、一篇内容、购物车、结账、订单邮件和退货页。用当地地址和币种验证价格格式、税、支付、运费、承运商承诺和法律文本；再用无痕窗口、不同浏览器语言和手动选择器检查是否能回到正确市场。多语言翻译若只覆盖产品标题而漏掉政策和应用错误提示，仍属于不完整迁移。
支付、税务和物流：重建资格与规则，不能搬配置截图
Shopify Payments 只对特定国家/地区和业务类型开放；官方支持国家列表要求核对主体、银行账户和验证文件，不符合时需要第三方提供商。Shopify 的第三方支付说明也提醒，第三方交易费和支付处理商费用要按目标市场确认。WooCommerce 的支付方式通常是网关插件连接处理商，资格、费率、退款、拒付和 token 由提供商决定。
税务不能由迁移工程师替代判断。Shopify 的税务文档说明商家仍负责注册、征收、申报和缴纳，除非启用适用的自动申报服务；WooCommerce 的税务设置文档也区分软件配置与法律意见，并要求决定含税/不含税、按送货地址还是账单地址计算以及运费税类。历史订单要保留原税行和税务事实，新订单再按目标规则计算，不能为了“统一”而重算历史。
Shopify 配送区域与费率依赖市场、地点、shipping profile、重量、尺寸和承运商；WooCommerce 的 shipping zones、shipping classes、实时费率插件和仓库规则需要重新建模。逐市场测试免费、固定、按重量、按金额、偏远地区、数字商品、拆单和退货运费，并核对包裹尺寸，否则结账可能少收运费而由商家承担差额。跨境场景还要把关税、进口税、清关责任、承运商追踪、欺诈审核和订单通知放进同一张测试矩阵；支付成功、订单创建或邮件送达都不能替代履约和财务对账。
建立支付—税—履约的真实回放矩阵
回放成功授权、失败授权、3DS、钱包、本地支付、重复回调、部分退款、全额退款、拒付、免税客户、税含价、折扣后税、多个地点库存、拆单、取消、退货和物流追踪。支付成功不等于 ERP 收到订单；订单创建、支付捕获、库存扣减、税务记录、履约和客户通知必须逐事件对账。
应用与集成：按能力而不是插件名称替代
建立 WooCommerce 插件能力矩阵：商品/搜索、评价、会员、优惠、订阅、税、支付、运费、库存、ERP、WMS、OMS、CRM、邮件、客服、分析、广告和隐私。每个能力标记 Shopify 原生配置、Shopify 应用、Flow/Functions、外部中间件、自建 API、人工流程或淘汰，并记录价格、权限、数据出口、性能、责任人和退出步骤。不要因为 Shopify App Store 有同名应用，就认定业务行为相同。
Shopify 的webhook 文档说明 webhook 适合近实时同步，但不保证送达顺序或完整性，并建议用定期 reconciliation 补偿；还应验证 HMAC 并用 X-Shopify-Webhook-Id 去重。WooCommerce 的webhook 文档则说明可监听订单、产品、优惠券和客户事件，连续失败超过阈值后 webhook 会自动禁用并保留日志。两边都不能只依赖 webhook。
给每个集成画出生命周期和死信路径
为创建、修改、取消、退款、删除、重试和补数分别写源系统、目标系统、业务键、方向、延迟、幂等键、失败队列、告警和人工处理。切换时只允许一个系统成为商品、价格、库存、订单或客户的权威写入端；另一个系统可以只读、订阅事件或按计划补数。下线旧插件前保存导出、凭证撤销记录和历史查询方案。
导入架构：CSV、应用和 API 各自承担可控的部分
CSV 适合基础产品、客户或库存的大批量人工可复核导入；应用适合历史订单、评价、媒体和扩展对象，但要审查权限、数据驻留、重试、计费、卸载和支持边界；API 适合需要身份映射、幂等、增量、复杂转换和机器对账的项目。Shopify 的批量导入文档描述 JSONL、staged upload、bulk mutation、状态和结果文件；不要把 HTTP 200 或 bulk completed 当成每一行成功。
WooCommerce REST API v3 默认分页，返回资源时应保存 X-WP-Total、X-WP-TotalPages 或 Link header；订单接口支持 modified_after 等筛选，可作为增量设计的一部分。对 8,000 个商品、数十万订单或大型媒体库，先测量单批内存、API 延迟、失败比例和结果下载，再决定并发，而不是复制一个固定 sleep。
让每一批都有输入、输出和重试边界
每批保存对象范围、源快照时间、payload 哈希、请求 ID、目标 ID、成功/失败/跳过数量、错误码和最后核验时间。可重试的网络、限流和暂时性 5xx 与不可重试的字段错误、权限错误、重复键分开；不可重试行进入隔离队列，修规则后只重放隔离行。输入文件和结果文件用加密存储与哈希保护，过期后按合规期限删除。
增量同步：用高水位、重叠窗口和对账捕捉变化
第一次全量导出结束后，源站仍可能收到订单、客户、退款、库存、价格和内容修改。以 modified_at 做唯一游标容易漏掉同一秒的多条记录、时钟漂移、删除、合并和独立库存事件。记录高水位加稳定 ID，下一次查询保留安全重叠窗口，再用身份映射和 payload 哈希去重；只有批次提交、结果落盘和对账成功后才推进游标。
删除、取消和退款必须进入 delta
为删除、下架、客户合并、退订、订单取消、退款、礼品卡使用、库存调整和 URL 删除设事件或差异查询。Shopify webhook 不保证完整送达，WooCommerce webhook 会因连续失败被禁用，所以要有定期全量/增量 reconciliation：源有效集合、目标集合、事件日志和业务账务四者互相检查。对冲突先按主责系统和业务时间裁决，不要让最后抵达的请求无条件覆盖新值。
| 变化类型 | 捕获方式 | 幂等键 | 质量门 |
|---|---|---|---|
| 新订单/客户 | API 高水位 + webhook | 源类型+源 ID+版本 | 目标对象唯一 |
| 修改价格/内容 | modified_after 重叠查询 | 源 ID+更新时间+哈希 | 只覆盖允许字段 |
| 库存变动 | WMS 事件或受控快照 | SKU+地点+版本 | 地点级数量一致 |
| 取消/退款/删除 | 事件、审计表或 tombstone | 源事件 ID | 目标状态与财务一致 |
| 漏事件 | 周期 reconciliation | 运行 ID+对象范围 | 差异归零或签字 |
彩排：先用难样本，再做两次可计时全量
第一轮在开发店或隔离店导入难样本：三层变体、重复 SKU、特殊字符、缺图、长富文本、多地址客户、游客订单、部分退款、多币种、礼品卡、订阅、下架内容和多语言页面。记录字段缺口、手工动作、通知副作用、API 耗时和清理方法。修正规则后做第二轮全量彩排，验证吞吐、增量追赶和回滚时间；最后再做一次带冻结窗口的切换演练。
把彩排结果变成可签字的门
每轮彩排输出源/目标数量、字段抽样、关系闭合、金额差异、URL 状态、支付/履约回放、同步延迟、人工小时、失败行和清理步骤。P0/P1 差异必须为零；低风险差异必须有负责人、截止日期和业务签字。若彩排耗时超过可接受冻结窗口，优化批处理、减少范围或改为分阶段切换，不能只在正式夜间冒险。
切换运行手册：按分钟写负责人和停止条件
运行手册应包含变更冻结、源站备份、最终全量/增量、库存与订单水位、旧站通知暂停、应用 webhook、支付、税、物流、DNS/域名、SSL、缓存、robots、sitemap、监控、客户沟通和首单路径。Shopify 官方迁移指南建议在转移域名前预先创建旧地址的 URL redirects；切换前确认旧域名不会被旧平台继续占用而导致 SSL 或解析冲突。
用有证据的时间线执行切换
每个时间点只有在前一项证据签字后才可继续；时间是相对切换点的示例，实际冻结长度应来自彩排而不是承诺一个通用小时数。
| 时间点 | 负责人 | 前置依赖 | 必须留存的证据 | 回滚触发 |
|---|---|---|---|---|
| T−30 至 T−14 天 | 项目负责人 | 范围、方法和负责人已批准 | go/no-go、对象台账、彩排报告 | 关键对象没有去向 |
| T−7 天 | 数据/SEO 负责人 | 目标店结构和 URL 目标稳定 | 最终字段映射、301 清单、备份恢复记录 | 高价值 URL 或字段未映射 |
| T−1 天 | 运营/财务 | 支付、税、物流、通知回放通过 | 集成矩阵、库存水位、通知暂停清单 | 付款/履约仍有 P1 差异 |
| T−0 冻结 | 迁移负责人 | 人员在线、快照哈希相符 | 冻结时间、最终 delta、写入锁记录 | delta 无法追赶或快照不一致 |
| T+0 至 2 小时 | 站点/支付负责人 | 域名、SSL、重定向和结账就绪 | 首单、支付、库存、ERP、邮件回放 | 结账或捕获持续失败 |
| T+1 天 | 业务/SEO/财务 | 监控和支持队列已接管 | 对账报告、404/301 日志、签字 | 订单/金额/库存差异超阈值 |
冻结窗口只冻结会影响关系的写入
提前宣布商品、价格、SKU、库存、优惠、内容、插件和设置的冻结范围与负责人。若旧站不能完全停写，用高水位和增量队列缩短窗口；订单、客户和库存要有清晰的最终水位。切换后先用测试支付或小额真实订单验证结账、通知、ERP、库存和履约，再逐步放开广告和邮件流量。
验收：从数据数字升级为业务旅程证据
验收分五层：数量、字段、关系、价值和行为。数量看源有效记录是否闭合；字段看标题、价格、重量、地址、状态、时间和自定义字段；关系看客户—订单—行项目—变体—库存地点；价值看币种、税、折扣、运费、支付、退款和礼品卡余额；行为看浏览、搜索、加入购物车、结账、支付失败、履约、退货、登录、邮件和客服查询。
用风险加权样本而不是只抽随机记录
样本优先最高收入商品、最复杂变体、最近和最旧订单、最大金额、跨币种、订阅、退款、游客、重复客户、多地址、特殊字符、主要语言和每个市场。记录截图、API 响应、订单号、时间和环境，不把截图当唯一证据。每个差异标记严重级别、根因、补救、复测结果和批准人。
| 验收层 | 代表性检查 | 通过定义 | 证据 |
|---|---|---|---|
| 数量 | 产品、变体、客户、订单、媒体和 URL | 差异有解释且达阈值 | 对账报告 |
| 字段 | 价格、重量、地址、状态、语言、SEO | 必要字段与源/规则一致 | 字段抽样 |
| 关系 | 订单行到变体、客户到订单、SKU 到地点 | 关键关系无孤儿 | 关系查询 |
| 价值 | 总额、税、折扣、退款、礼品卡、库存 | 业务方程和余额通过 | 财务/库存签字 |
| 行为 | 结账、支付、履约、退货、账户、搜索 | 关键旅程可重复 | 回放记录 |
用同一张对账矩阵覆盖数量、金额和地点
每次全量、增量和切换后检查都使用相同的键和统计口径。0 是默认容差；任何非零差异必须列出原因、补偿、负责人和到期时间，不能在报告中用四舍五入或全局总数掩盖地点、币种和状态差异。
| 对账对象 | 源数量/价值 | 目标数量/价值 | 容差 | 负责人 |
|---|---|---|---|---|
| 产品与变体 | 有效 SKU 数 / 可售价格总览 | Shopify SKU 数 / 目标价格总览 | 数量 0；价格按批准规则 | 商品负责人 |
| 客户身份 | 客户数 / 可处理同意数 | 客户数 / 已映射同意数 | 身份差异 0；待激活单列 | 客户与隐私负责人 |
| 历史订单 | 订单数 / 币种分组总额 | 订单数 / 币种分组总额 | 数量 0；金额按币种 0 | 财务负责人 |
| 退款与礼品卡 | 退款笔数与金额 / 余额与使用记录 | 目标退款与余额 / 使用记录 | 财务批准的四舍五入以内 | 财务负责人 |
| SKU × 地点库存 | 每地点可售、预留、在途 | 每地点目标数量与状态 | 默认 0；WMS 解释需签字 | 供应链负责人 |
| URL 入口 | 高价值旧 URL 数 / 流量收入分层 | 301/200/下线去向数 | 未映射 0；异常逐条审批 | SEO 负责人 |
回滚：恢复业务连续性，而不是删掉 Shopify 数据
回滚方案先区分“域名回退”“继续在旧站运营”“补偿已写入对象”和“财务/支付回退”。切换后若已产生新订单、退款、库存扣减或客户注册，把 DNS 指回旧站并不会让这些事实消失；必须锁定写入、导出切换后事件、确定权威系统、补回旧站或保留新站只读，并由财务批准任何退款或重新扣款。
为每类故障预设触发阈值
例如：核心结账持续失败、支付捕获与订单不一致、库存地点出现不可解释负数、订单遗漏超过阈值、关键 URL 大规模 404、P1 集成队列无法追赶或个人数据权限错误。阈值要在切换前写入手册；触发后先暂停流量和下游自动化，保存证据，再执行最小范围补偿。不要为了“看起来完成”重复全量导入。
上线后 30 天：保留只读证据并逐步关闭旧系统
第 1–3 天按小时观察结账成功率、支付失败、订单同步延迟、库存差异、404/301/5xx、邮件、退款和客服问题；第 4–7 天每日对账；第 2–4 周每周复盘市场、税、物流、应用账单、搜索抓取和回滚准备。旧 WooCommerce 至少保持受控只读查询、加密备份和隐私响应能力，不要在数据确认前删除唯一副本。
以关闭清单完成稳定期
30 天结束时确认 P0/P1 为零、差异有签字、所有集成有负责人、备份可恢复、旧凭证已撤销、应用和主机费用已审查、客户通知已完成、sitemap/重定向持续正常，且财务完成首月支付税务对账。只有在业务、技术、SEO、隐私和财务共同签字后，才决定停用旧站、续订旧插件或转入常态运维。
常见问题
WooCommerce 数据可以全部自动迁移到 Shopify 吗？
不能保证。基础产品、客户或库存可以采用官方 CSV 或 API 路径，但插件自定义字段、评价、组合商品、礼品卡、订阅、支付 token、历史订单和多语言内容需要分别评估。先做对象台账、字段映射和难样本，再选择 CSV、应用、API 或只读归档的组合。
迁移期间必须关闭 WooCommerce 店铺吗？
不一定需要长时间停店，但必须有数据冻结或增量同步窗口。若旧站继续接受订单、客户注册、退款或库存变化，必须捕获这些 delta，并在最终水位后对账；没有可靠增量能力时，宁可延长维护页或缩小切换范围，也不要让两个系统同时写同一事实。
历史订单、客户密码和支付卡能一起迁移吗？
不应默认可以。历史订单可通过迁移应用或 API 处理，客户 CSV 不能迁移外部密码，客户通常需要重新激活或重置；卡号和支付 token 受支付提供商、合规和订阅应用限制。先决定哪些历史进入 Shopify、哪些留在只读归档，并让支付与隐私负责人批准任何 token 或订阅迁移。
换到 Shopify 会自动保住 Google 排名吗？
不会自动保证。逐 URL 301、目标内容、canonical、hreflang、sitemap、内链、图片、状态码和上线监测共同决定连续性。旧商品、分类和文章不要无差别跳首页；上线后持续查看抓取、404、重定向链和自然入口，发现高价值页面异常就按台账修复。
什么时候才算迁移完成？
当数据、关系、金额、库存、支付、税务、物流、账户、邮件、SEO、应用集成和团队 SOP 都通过书面验收，且回滚/补偿演练有证据，才算完成。域名能打开只是发布动作，不是项目验收；30 天稳定期结束前，旧数据也应保留受控的可查询和可恢复状态。
一手来源与版本说明
- Shopify：Migrate to Shopify
- Shopify：Migrate from WooCommerce
- Shopify：Importing products with CSV
- Shopify：Product CSV field rules and inventory CSV, inventory CSV
- Shopify：Importing and exporting customer lists
- Shopify：Creating and managing URL redirects
- Shopify：Markets and international SEO
- Shopify：Payments, taxes, shipping, taxes, shipping zones
- Shopify developer：Bulk Operations, webhooks, gift cards, subscriptions, webhooks, giftCardCreate, subscription contracts
- WooCommerce：Backups and database
- WooCommerce developer：REST API v3 and webhooks, webhooks
- WooCommerce：Customer/order/coupon export extension
- WooCommerce：Product import/export, coupons, gift cards, subscriptions, taxes, coupons, gift cards, subscriptions, taxes