Use this after acceptance, before live use
Suggested workflow practice: use this guide only after the custom system’s agreed workflow has been built and accepted for the intended release. Its purpose is to rehearse the record cutover, not to reopen the design, select software, compare CRM options, or decide whether a spreadsheet should remain in use.
A cutover is the moment when the team stops treating the old record location as the live operational source and starts using the agreed system for new work. That change can be unclear even when the system itself works. Staff may continue updating a chat, spreadsheet, paper list, or older tool while also entering records in the new system. A rehearsal makes the boundary visible before real work depends on it.
Bring the dated agreed scope, the accepted workflow examples, a current export or view of old records, the planned system view, and the people who own daily operations. Do not rebuild missing agreement from memory. If an important rule was never agreed, mark it as an unresolved decision and give it to the responsible owner before go/no-go.
- Confirm the accepted workflow release
- Bring the dated scope record
- Identify current record locations
- Name operational decision owners
Set one final legacy-record boundary
Write a short boundary statement that a busy staff member can apply. It should name the record types affected, the old source or sources, the exact event that separates old from new handling, and who may approve an exception. For example, a boundary might say that records created before a named handover event remain in the legacy list for reference, while records received after that event are entered and updated only in the agreed system.
Avoid a vague instruction such as “start using the new system tomorrow.” It leaves open whether an in-progress record should be copied, whether late messages belong in the old file, and whether corrections to historic records can still be made. State what happens to open records, completed records, cancelled records, and records that arrive during the transition.
Choose a boundary that fits the actual workflow rather than a convenient calendar label. It may be the completion of a final reconciliation, the end of a scheduled operating period, or a named release meeting. Record the boundary in one shared place and make sure staff can find it without asking a different person each time.
- Define affected record types
- Write the boundary statement
- Decide handling for open records
- State legacy correction rules
- Publish one shared boundary
Reconcile records before changing authority
Reconciliation is a practical comparison between what the old source says should exist and what the agreed system will be relied upon to show. Start with a small reconciliation sheet or controlled list. For each record group, state the source, selection rule, expected count or identifiable set, observed result, reviewer, date, and exception reference. Counts can help, but a matching count alone does not prove that the right records are present.
Check the record properties that matter to the agreed workflow. Depending on the scope, that may include a stable reference, current status, responsible person, meaningful dates, and a link to an associated customer or job. Do not introduce extra fields merely because they might be useful later. The purpose is to establish enough evidence to use the agreed workflow safely.
Reconcile active and exceptional records separately from closed historic records. Active work usually needs closer review because a missing owner, status, or next action can affect immediate operations. Historic records may need only the access or retention treatment already agreed. Record the method used so another reviewer understands what was compared.
- Create a reconciliation record
- Separate active from historic records
- Compare workflow-critical values
- Link every mismatch to evidence
- Record reviewer and review date
Log exceptions without changing scope
An exception is a specific record or condition that prevents the planned boundary from being applied cleanly. Examples include a duplicate identifier, an incomplete old record, a record that exists in two old sources, a missing attachment, or a status that cannot be mapped using the agreed rules. An exception is not automatically a defect and not automatically a request for a new feature.
Give each exception an identifier, a plain description, affected record reference, operational impact, temporary handling, named decision owner, next action, and target decision point. Keep it linked to the cutover record. This prevents a conversation in chat from becoming an invisible change to the release plan.
Use an explicit decision path. If the issue can be handled using an agreed rule, record the rule and proceed. If it is a build defect against an accepted example, send it through the agreed defect route and reassess the checkpoint. If it needs a new field, rule, report, integration, or workflow, record it as a separate future scope decision; do not quietly add it to the cutover. If no safe temporary handling exists for an active record, it is a go/no-go issue.
- Give each exception an identifier
- Describe the operational impact
- Name one decision owner
- Separate defects from new scope
- Set temporary handling clearly
Run a fictional rehearsal and rollback
Fictional example: North Pier Services has an agreed internal job workflow. Before cutover, the team selects a final old-list boundary after its afternoon reconciliation. They find that one active job has a legacy status that does not match an agreed system status, and another has two old references pointing to the same job. The operations owner records both exceptions rather than editing the system design during the rehearsal.
For the first record, the owner applies an already agreed temporary status and assigns a staff member to confirm the correct status before the next operating period. For the duplicate-reference record, the owner chooses one agreed primary reference and records the second as legacy evidence. The team then checks that active jobs visible in the new system have a responsible owner and usable next action.
The rollback checkpoint is not simply “go back if anything feels wrong.” Define the observable condition that would stop reliance on the new system, who may call that decision, where staff should record work during the pause, how new entries made after the boundary will be preserved, and who will announce the restart. Rehearse these actions with a small set of representative records. A rollback may mean pausing new-system authority while evidence is corrected; it should not mean deleting records or overwriting the trail.
- Label the example as fictional
- Test representative active records
- Define observable pause conditions
- Protect post-boundary entries
- Name restart communication owner
Make the go or no-go decision
Hold a short decision review at the checkpoint. The named go/no-go owner should see the boundary statement, reconciliation result, open exceptions, temporary handling, rollback plan, and confirmation that staff know the first action after release. The owner should record one of three outcomes: go, no-go, or go with documented constraints. “Go with constraints” is appropriate only when each constraint has safe handling, an owner, and a review point; it is not a way to hide unresolved operational risk.
If the outcome is no-go, keep the old source authoritative for the affected activity and state exactly what must be resolved before another checkpoint. Do not create competing live sources by telling some staff to use the new system and others to use the old one without an explicit temporary plan. If the outcome is go, communicate the boundary, first required action, support contact, and rollback trigger in the same message.
After the first live operating period, perform a narrow read-back. Check a sample of new records against the agreed workflow and review whether any staff continued to update the legacy source. Capture observations as evidence or separately logged improvement requests. This guide does not promise outcomes; it provides a repeatable way to make the transfer decision visible.
- Review evidence at the checkpoint
- Record go or no-go outcome
- Communicate one live authority
- Perform a first-period read-back
- Log later improvements separately
中文指南
验收之后才进行切换排演
建议的流程做法：只在自定义系统已按既定流程完成并获验收、但尚未正式依赖其处理日常工作时使用本指南。这里处理的是记录切换排演，不是重新设计系统、选择软件、比较 CRM，或判断是否继续使用表格。
记录切换，是团队不再把旧聊天、旧表格、纸本清单或旧工具视为实时运营依据，转而使用已同意系统的时点。即使系统功能正常，这个时点也可能混乱：员工可能同时更新旧表和新系统。排演让边界在真实工作依赖它之前变得清楚。
准备已签定日期的范围记录、已验收的流程例子、旧记录的当前导出或视图、计划使用的系统视图，以及负责日常运营的人。若关键规则从未被同意，不要凭记忆补写；应标记为未解决决定，并在 go/no-go 前交给指定负责人。
- 确认已验收的流程版本
- 准备已签日期的范围
- 列出当前记录存放处
- 指定运营决定负责人
设定唯一旧记录截止边界
写一段忙碌员工也能执行的边界说明。说明应写明受影响的记录类别、一个或多个旧来源、区分旧处理与新处理的明确事件，以及谁可批准例外。比如，某个已命名交接事件之前建立的记录留在旧清单供查阅；之后收到的记录只在已同意系统中建立和更新。
不要只说“明天开始用新系统”。这没有回答进行中的记录是否要转入、迟到的信息属于哪里、历史记录能否仍被修正。应分别说明未完成、已完成、已取消，以及切换期间进入的记录如何处理。
边界应配合实际流程，而不是只配合方便的日期。它可以是最后一次核对完成、一个运营周期结束，或一次指定发布会议。将边界写在一个共用位置，确保员工无需逐一询问别人也能找到。
- 定义受影响的记录类别
- 写下明确边界说明
- 决定未完成记录处理
- 说明旧资料修正规则
- 发布一个共用边界
变更权威前先核对记录
核对是比较旧来源中应存在的内容，与团队即将依赖的新系统内容是否相符。先建立小型核对表或受控清单。每个记录组写明来源、筛选规则、预期数量或可识别集合、实际结果、审核人、日期及例外编号。数量有帮助，但数量相同并不能证明记录正确。
检查既定流程真正需要的属性。依范围而定，可包括稳定编号、当前状态、负责人、有意义的日期，以及客户或工作记录的关联。不要因为以后可能有用而加入额外字段；目的只是取得足够证据，以便安全地依赖既定流程。
将活跃记录和例外记录，与已关闭的历史记录分开核对。活跃工作通常需要更仔细审阅，因为缺少负责人、状态或下一步会影响即时运营。历史记录可能只需按既定要求保留或可查阅。写下比较方法，让另一位审核人知道比较了什么。
- 建立核对记录清单
- 分开活跃与历史记录
- 比较流程关键资料
- 每个不符都链接证据
- 记录审核人员和日期
记录例外但不要扩张范围
例外是令计划边界无法顺利执行的具体记录或情况，例如重复编号、不完整旧记录、同一记录存在于两个旧来源、缺少附件，或无法按既定规则映射的状态。例外不自动等于缺陷，也不自动等于新功能需求。
每个例外应有编号、简单描述、受影响记录编号、运营影响、临时处理、指定决定负责人、下一步及目标决定点。让它链接到切换记录，避免聊天中的讨论变成看不见的发布计划改变。
使用明确决定路径：若既定规则可处理，记录规则后继续；若它违反已验收例子，应走既定缺陷流程并重新评估检查点；若需要新字段、新规则、报表、整合或流程，应登记为未来范围决定，不能悄悄加入切换。若活跃记录没有安全临时处理，它就是 go/no-go 问题。
- 为每个例外设置编号
- 说明实际运营影响
- 指定唯一决定负责人
- 区分缺陷和新增范围
- 清楚写下临时处理
进行虚构排演和回退检查
虚构例子：North Pier Services 有一套已同意的内部工作流程。切换前，团队在下午核对结束后选择旧清单的最终边界。他们发现一个活跃工作有无法直接对应既定系统状态的旧状态，另一个工作则有两个旧编号指向同一工作。运营负责人先记录两个例外，而不是在排演中修改系统设计。
对于第一个记录，负责人采用已同意的临时状态，并指派员工在下一个运营周期前确认正确状态。对于重复编号记录，负责人选择一个已同意的主编号，并把另一个编号记录为旧资料证据。随后，团队检查新系统中可见的活跃工作是否都有负责人和可执行的下一步。
回退检查点不能只是“感觉不对就回去”。应定义会停止依赖新系统的可观察条件、谁可作出决定、暂停期间员工在哪里记录工作、边界之后的新输入如何保留，以及谁宣布重新开始。用少量具代表性的记录排演这些动作。回退可以是暂停新系统的权威性以修正证据，不应删除记录或覆盖轨迹。
- 明确标示例子为虚构
- 测试代表性的活跃记录
- 定义可观察的暂停条件
- 保护边界后的新输入
- 指定重启沟通负责人
作出上线或不上线决定
在检查点举行简短决定复核。指定的 go/no-go 负责人应看到边界说明、核对结果、未关闭例外、临时处理、回退计划，以及员工知道发布后第一步的确认。负责人应记录三种结果之一：上线、不上线，或带有已记录限制的上线。“带限制上线”只适用于每项限制都有安全处理、负责人和复核点的情况；它不能用来隐藏未解决的运营风险。
若结果为不上线，应让旧来源继续作为受影响活动的权威记录，并写明下次检查点前必须解决什么。不要在没有明确临时计划时，让部分员工使用新系统、部分员工使用旧来源，从而制造两个并行的实时来源。若结果为上线，应在同一则通知中说明边界、首个必须动作、支持联系人和回退触发条件。
第一个正式运营周期后，进行小范围读回检查：抽查新记录是否符合既定流程，并查看是否有人继续更新旧来源。把观察结果作为证据或独立改善请求记录。本指南不承诺结果；它提供一种可重复的方法，让记录转移决定清楚可见。
- 在检查点复核全部证据
- 记录上线或不上线结果
- 通知唯一实时权威来源
- 完成首周期读回检查
- 后续改善另行登记
Sources and next step
Discuss your workflow scope with BossFlow · Compare system categories at SME Systems · All articles