网站建设策划书：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /234e570c1635.html
📄
网站建设策划书：旧系统字段无法完整迁入时怎样决定保留项
先给结论：字段保留项不应由“旧系统里有没有”决定，而应由“新站当前业务是否还需要它、迁移后能否被正确读取、缺失会否阻断关键流程”三项共同决定。缺少完整数据或权限时，仍可先做一张字段用途与依赖清单，把字段分成必留、可替代、可放弃三档，再决定是否进入迁移开发。
假设情境：字段只迁过来一半
假设某企业准备把旧官网迁到新系统，旧库里有产品型号、规格参数、库存状态、内部负责人、备注、创建时间等字段。新系统只提供标题、正文、图片和少量自定义字段，且旧库导出缺了几列，后台账号权限也不完整。此时若要求“全部迁入”，项目会卡住；若直接放弃，又可能影响产品页展示和后续筛选。决策的关键不是追求字段数量一致，而是判断哪些字段仍承担当前网站任务。
先判断字段是否仍被当前业务使用
可以按下面顺序逐个字段过一遍：
- 这个字段是否出现在现有页面、筛选、表单或对外展示中？
- 它是否被其他字段或页面逻辑依赖，例如“库存状态”影响购买按钮？
- 它是否只服务旧后台流程，新站已不再需要？
- 缺失后，用户能否仍完成主要任务，例如查产品、看规格、提交咨询？
如果字段只出现在旧后台，且新站没有对应展示或流程，可以归入可放弃；如果字段虽不直接展示，但被筛选或结构化数据引用，应归入必留或可替代；如果字段只是运营备注，不影响前台任务，可先不迁，后续按需补录。
缺少完整数据或权限时的最小动作
在没有完整导出和权限的情况下，先不要承诺全量迁移。可执行的最小动作是：导出能拿到的字段样本，按页面截图或模板逐一对照，标出每个字段的用途、是否公开、是否参与筛选、缺失后果。这个动作的结果会直接影响下一步：如果必留字段都能找到替代承载方式，迁移可以继续；如果必留字段无法被新系统读取，应先调整字段方案或暂缓上线，而不是先迁完再补。
这里要说明不能推出的结论：导出量少、抓取量下降或某字段为空，不能单独证明该字段不重要，也不能证明迁移方案正确。它们也可能来自权限限制、导出条件设置不同、旧数据本身未填写等原因。需要结合页面用途和流程依赖再判断。
用三档分类决定保留项
把字段分成三档，比逐字段争论更可执行：
- 必留：缺失会阻断产品展示、筛选、询价或合规信息呈现，必须在新系统中找到承载位置。
- 可替代：不直接保留原字段，但可用正文、标签、附件或统一备注承接，且不影响主要任务。
- 可放弃：只服务旧后台、已无对外用途、缺失后无人依赖，暂不迁入。
假设“库存状态”属于必留，因为页面需要显示是否有货；若新系统没有独立库存字段，可先把它并入正文固定位置，并确认前端能读取。若“内部负责人”属于可放弃，就不应为了字段齐全而增加迁移复杂度。这个判断的结果是：开发范围缩小，验证重点集中在必留字段是否可读、可展示、可更新。
迁移前必须验证的字段条件
决定保留项后，还要验证三个条件：新系统能否存储该字段、前台能否按预期读取、后续编辑能否维护。缺少权限时，至少用样本数据做一次假设性对照：把一条旧记录手工填入新结构，检查页面是否显示正确、筛选是否生效、修改后是否同步。若验证不通过，应回到字段方案调整，而不是继续批量迁移。字段保留项定稿后，再进入页面模板、内容录入和上线检查，顺序更稳。
