从 Tomoson 类工具迁移：别只搬走达人用户名

先界定迁移边界

列出当前使用的工具、表格、合同文件、付款与物流系统，明确哪个保存什么事实。只搬名单会丢掉关系；把全部文件不加区分地上传，也可能扩大无关数据访问。

确认项目是否有临近发布、寄样在途、待审核或待付款。指定切换期间的主记录，避免两边同时催促同一位达人。迁移不是暂停履约的理由。

保留账号身份与历史证据

记录平台、完整链接、用户名、显示名、联系来源和观察日期。重复显示名先保留，不自动合并。若一个人有多个平台，关联身份也需要依据。

导出能力应在当前账户中确认；不能导出的资料，通过已授权的现有记录整理，必要时询问供应商。不要猜测旧工具 API 或假装拿到了不存在的字段。

权益、承诺和停止联系优先

比标签更重要的字段包括最后联系、拒绝或停止联系、当前范围、付款节点、素材使用期限与负责人。状态名相似也可能含义不同，例如“完成”可能只是内容发出，而非付款结清。

将这些含义写成映射表。旧素材授权不因软件迁移而扩大；不确定的期限标为待核验。资料少可以补，错误放行的素材和重复联系往往更难修复。

用小批记录测试新工具

选二十条覆盖不同情况的记录：同名、跨平台、停止联系、已结束合作、在途样品和到期权益。这是操作样本，不是完整统计测试。

在新工具检查身份、状态、附件、权限和下一步是否仍然可读。Modash、Collabstr 与 Aspire 的官方产品方向不同，具体导入字段与账户权限须现场验收，不能因产品支持管理就推断迁移无损。

对账不仅是比较行数

假设旧资料有 500 行，去掉已确认重复后剩 470 个账号，并保留 12 条跨平台关联。新工具显示 470 行并不足够，还要确认停止联系和未完成事项数量及含义一致。

对无法迁移的备注或附件保留可用参照，不把信息丢失隐藏在“成功导入”里。所有数量只是算例。让未参与迁移的同事随机接手一项工作，检查能否继续执行。

分阶段切换并保留恢复路径

先让新项目在新工具执行，旧项目按指定主记录收尾。设置观察期，检查重复消息、状态滞后和权限问题。只在关键记录通过后停止旧流程。

QuickKOL 可以进入发现与外联准备环节，但本文不承诺未经测试的 Tomoson 直接导入。保留记录、负责人和恢复方案，让切换服务于合作连续性，而不是仅完成一次软件采购。

算例：先迁移五条记录，再决定整体搬迁

选择五条代表记录：已合作、待回复、有许可、已退出和存在争议的项目。检查身份、状态、合同、素材和历史沟通是否能正确对应。

在新系统核对权限与导出后，由第二位同事复核。若某字段无法迁移，明确保留在哪里与谁负责；不要批量导入后才发现合作状态全部重置。

常见问题：旧数据不完整，要不要全部补齐

先判断哪些字段对现有承诺和后续工作必要。已失效的线索与活跃合作可以采用不同处理方式，但都要有可追溯状态。缺失资料标未知，不凭记忆补合同。

迁移完成还需明确旧系统何时停止编辑、谁处理迟到回复，以及取消后的数据访问。旧系统保留不代表大家应继续双向随意更新。

研究依据、日期与边界

2026-10-21 资料核验。未实际访问任何供应商后台，不声称测试过导出、导入或迁移接口。记录数量为假设。