用途：把商品目录从任意来源系统一次性迁移到 commercetools。核心思路是数据契约而非代码模块：任意来源 → 适配器 → 规范化目录 feed（NDJSON，经 schema 校验）→ 可复用管道 → commercetools。管道（commercetools/ct-catalog-migration-pipeline）从不解析源系统，契约文件为 schema/catalog-feed.schema.json。若需求是来自 PIM/ERP/OMS 的周期性同步，则属于集成而非迁移，不适用本方法。
主要能力与流程：先运行文档检索脚本 scripts/docs-search.mjs（带 --query、--app-name、--model 等参数）获取最新文档作为依据；随后在 migration/INTERVIEW.md 中逐题访谈并停止，待全部回答后写出 migration.config.json；同时开启决策日志，记录每个决策与未决问题。接着编写适配器（先做一个商品），跑通薄切片，再按顺序执行离线阶段：npm run pipeline -- validate / derive / plan / audit（均需 --config，plan 可加 --payloads），这些阶段无需凭据。之后用 preflight 检查目标项目是否接受计划，load 默认干跑并输出 out/load-requests.json，加 --execute 才真正写入，且每次 --execute 前必须获得用户明确同意。最后用 verify 回读项目并与计划核对。
适用场景：一次性、决策密集的目录迁移，需要明确记录哪些被翻译、近似或丢失。
限制与风险：属性约束只能放宽不能收紧；产品选择的模式创建后固定；Product 的 ProductType 创建后不可更改；productCatalogModel 在 map 时固定。金额为最小货币单位且各币种小数位不同；本地化值不可作为变体轴；省略字段在导入时会被删除；未解析的 KeyReference 48 小时后过期；不存在的 SKU 库存仍可导入成功；无税类目的商品无法计税；publish: false 会取消发布。属性名在项目内只能有一种类型；slug 在项目内按语言唯一。渠道、客户组、税类目不能通过导入创建。以上限制依据 2026 年 9 月公开文档，使用前应重新核对。