Set the handover boundary
Use this guide after the custom system and its intended record groups have already been scoped, and before or during handover. The purpose is modest but important: agree whether a recipient can open the supplied files and understand enough of their contents without relying on the application. The deliverable is an export acceptance sheet, not a backup certificate, migration plan, permission matrix, cutover rehearsal, or general acceptance checklist.
Start with the dated scope and name the record groups that belong in this review. Examples may include jobs, customers, tasks, payments, notes, or attachments only where those groups are already in scope. State the export date or date range, the filter used, the file location or delivery method, and the person preparing the package. A reader should be able to tell whether the files represent all agreed records, a defined period, or a deliberately limited sample.
Do not silently expand the request into every table the system contains. Conversely, do not assume that an omitted group was accidental. List exclusions plainly, with the reason and the person who can confirm the decision. This keeps the package useful without suggesting that it is a complete application backup or that it can be imported into another product.
- Name agreed record groups
- Record export date
- State applied filters
- List known exclusions
Design a readable package
Use a small package structure that a non-specialist can follow. A practical starting point is one tabular file per agreed record group, an attachment manifest where files are included, and a field-definition sheet. A plain, documented format may make review easier, but there is no universal format mandate in this guide. Choose a format the intended recipient can actually open and inspect.
Give each file a clear name that identifies its record group and export date. Include a short package note identifying the system release or scope reference, the preparation date, contact person, and any assumptions. Keep the note descriptive: it should say what is present, not claim that the files recreate screens, rules, permissions, calculations, automation, or the full system.
The field-definition sheet is the bridge between columns and meaning. For each exported field, record the file and column name, plain-language meaning, expected value type, date or time convention, allowed status values where relevant, and whether a blank has a defined meaning. GOV.UK guidance treats metadata, consistent structures, and formats as useful for understanding and reusing data; apply that as a design example, not as a local legal requirement.
- Label every file
- Add package note
- Define each field
- Explain blank values
Preserve links and attachments
A readable export is not only a collection of rows. It must also show how related records connect. Export a stable record reference for each relevant group, such as a job reference, customer reference, or task reference already used by the scoped system. Use that same reference consistently in related files. Do not substitute row numbers, display order, or a person’s name for identity when those can change or repeat.
For linked data, document the relationship in the field definitions. For example, a task file may contain a job reference that points to the job file. A reader should be able to choose a small set of records and trace the connection without asking someone to inspect the application. If a relationship cannot be represented clearly, record it as an exception rather than inventing a link.
Where attachments are included, supply a manifest rather than leaving a folder unexplained. The manifest can identify the parent record reference, attachment filename, file type, relative path or delivery location, and an indication when the file was unavailable or intentionally excluded. Do not put sensitive content into a test package merely to demonstrate the process; use synthetic data for the read-back exercise.
- Export stable references
- Document record links
- Provide attachment manifest
- Use synthetic test data
Run a representative read-back
Test the package as a recipient would. Ask a reviewer who did not prepare the files to open the package outside the application. Give them a short set of synthetic, representative cases that cover ordinary records and meaningful variations, such as a record with a linked task, a record with a blank optional field, a record with an attachment entry, and a record outside the chosen date filter.
For each case, ask the reviewer to locate the record by its stable reference, identify the meaning of key fields from the definitions, follow one stated relationship, and confirm whether an attachment entry can be understood. The test is a comprehension check, not proof of every record’s accuracy and not a promise of compatibility with a future system. Record the reviewer, date, files tested, cases used, observations, and result.
If a file opens but dates are ambiguous, encoding corrupts names, a status cannot be interpreted, or linked rows cannot be traced, treat that as a failed or conditional check. Correct the package where the agreed scope supports it, then rerun the affected read-back. Keep the original observation in the acceptance sheet so the decision trail remains clear.
- Use independent reviewer
- Open files externally
- Trace linked records
- Log read-back result
Decide exceptions explicitly
Not every issue needs the same response. If an excluded record group was outside the dated scope, record it as excluded and name the confirming owner. If the group was in scope but absent because the export failed, mark the package incomplete and assign correction before acceptance. If a field exists but its meaning is unknown, do not guess; place it in an unresolved exception with an owner and next action.
Use conditional acceptance only when the responsible people can describe the exact limitation, its practical effect, and the decision needed. For example, an attachment manifest may be understandable while historical file contents remain unavailable. The sheet should distinguish “not supplied”, “supplied but unreadable”, “not applicable”, and “awaiting decision”; these states should not be compressed into a blank cell.
A fictional example: Cedar Lane Repairs is not a client. Its handover package contains job and task files for April, plus an attachment manifest. During read-back, the reviewer can trace task TS-204 to job JB-118, but the date column does not state whether it uses day-month or month-day order. The team records a conditional exception, updates the field definition to state the convention, repeats the test, and accepts that limited package. They do not claim it is a restore point or a migration-ready archive.
- Classify each exception
- Name decision owner
- State practical effect
- Retest corrected items
Complete the acceptance sheet
Use one acceptance sheet as the handover record. Include the scope reference; export date and filters; file inventory; record groups; field-definition version; stable identifiers; attachment-manifest status; excluded fields or groups; synthetic read-back cases; reviewer results; exceptions; decision owners; and the final outcome. Link or attach the actual files where the team’s delivery method permits, so the evidence and decision are not separated across messages.
Acceptance means only that the named reviewers have checked the stated package against the stated criteria. It does not establish who may access future exports, prove that all data is correct, replace retention or legal advice, prove a disaster-recovery process, or promise that another application can import the files. Keep operational permissions, cutover, support, and broader acceptance decisions in their respective records.
Before closing, ask one final practical question: could a reasonably informed recipient identify each agreed file, understand its fields, locate representative records, follow their stated links, and see what was not included? If yes, record acceptance with any limitations. If no, leave the relevant exception open rather than using a broad handover statement that hides the gap.
- Capture evidence links
- Confirm stated limits
- Obtain named review
- Leave gaps visible
中文指南
明确交付边界
本指南适用于自定义系统及其记录范围已经确认之后、交接之前或交接期间。目标并不扩大：确认接收方即使不进入应用程序，也能打开所交付的文件并理解其内容。产出物是数据导出验收表，不是备份证明、迁移计划、权限矩阵、切换演练或通用验收清单。
先查看带日期的范围文件，并列出本次审阅包含的记录组。例如，工作单、客户、任务、付款、备注或附件，只有原本已纳入范围时才应列入。写明导出日期或日期区间、所用筛选条件、文件交付位置或方式，以及准备人。读者应能判断这些文件代表全部已同意记录、某个期间，还是有意限定的样本。
不要把请求悄悄扩大为系统里的所有数据表。同样，也不要假定缺少的记录组一定是疏漏。应清楚列出排除项目、理由及能确认该决定的人。这样既保留文件的实用性，也不会暗示它是完整应用备份或可直接导入其他产品。
- 列出记录范围
- 写明导出日期
- 说明筛选条件
- 列明排除项目
设计可读套件
采用让非技术读者也能跟随的小型套件结构。实用起点是：每个已同意记录组一份表格文件；附件已包含时提供附件清单；另有一份字段定义表。本指南不规定通用格式；应选择预定接收方确实能够打开和检查的格式。
每个文件应有清楚名称，显示记录组和导出日期。加入简短套件说明，写明系统版本或范围编号、准备日期、联系人及任何假设。说明应描述文件包含什么，而非声称文件能够重建画面、规则、权限、计算、自动化或整个系统。
字段定义表是栏目名称与实际含义之间的桥梁。每个导出字段应写明文件与列名、白话含义、预期值类型、日期或时间写法、相关状态的允许值，以及空白是否有固定含义。GOV.UK 指南把元数据、一致结构和格式视为理解及复用数据的有用做法；这里仅把它作为设计参考，不视为本地法律要求。
- 清楚命名文件
- 加入套件说明
- 定义所有字段
- 解释空白含义
保留关联附件
可读的数据导出不只是许多数据行，还须显示相关记录如何连接。每个相关记录组应导出稳定业务编号，例如范围内已有的工作单编号、客户编号或任务编号；在关联文件中持续使用同一编号。不要用可改变或可重复的行号、显示顺序或人名取代记录身份。
对于关联数据，应在字段定义中写明关系。例如任务文件中的工作单编号对应工作单文件。读者应能够选择少量记录并追踪关系，无须再进入应用程序查看。若无法清楚表达某个关系，应将它记录为例外，不应虚构连接方式。
如包含附件，应交付附件清单，而不是留下无法理解的资料夹。清单可列出父记录编号、附件文件名、文件类型、相对路径或交付位置，以及文件不可取得或有意排除的状态。不要为了演示流程而在测试套件中加入敏感内容；读回测试应使用合成数据。
- 导出稳定编号
- 说明记录关联
- 提供附件清单
- 使用合成数据
执行代表读回
请以接收方的方式测试套件。安排没有准备这些文件的审阅人，在应用程序以外打开套件。给他一组简短而具代表性的合成案例，覆盖普通记录和有意义的变化，例如含关联任务的记录、含可选空白字段的记录、含附件条目的记录，以及不在所选日期筛选内的记录。
每个案例都要求审阅人以稳定编号找到记录，根据字段定义辨识关键字段的含义，追踪一个已说明的关联，并确认附件条目是否可理解。此测试是理解程度检查，不是每条记录准确性的证明，也不承诺未来系统的兼容性。记录审阅人、日期、测试文件、所用案例、观察结果及结论。
若文件能打开但日期写法含糊、编码令姓名损坏、状态无法解释，或关联记录无法追踪，应视为未通过或有条件通过。若已同意范围支持修正，先修正套件，再重复受影响的读回。原始观察结果也应保留在验收表中，以维持清楚的决定轨迹。
- 安排独立审阅
- 外部打开文件
- 追踪关联记录
- 记录读回结果
明确处理例外
并非每个问题都应以相同方式处理。若某记录组本来就在带日期的范围之外，应记录为已排除，并写明确认负责人。若该记录组在范围内却因导出失败而缺少，应标示套件未完成，并在验收前指定修正责任。若字段存在但含义未知，不要猜测；应把它放入未解决例外，列出负责人和下一步。
只有当负责人员能够说明准确限制、实际影响及所需决定时，才使用有条件验收。例如附件清单可能可理解，但历史附件内容仍无法取得。验收表应区分“未提供”“已提供但无法阅读”“不适用”和“等待决定”；不应把这些状态压缩为一个空白格。
虚构例子：Cedar Lane Repairs 并非客户。其交接套件包含四月份的工作单和任务文件，以及附件清单。读回时，审阅人可把任务 TS-204 追到工作单 JB-118，但日期栏没有说明采用日月还是月日顺序。团队记录有条件例外，在字段定义写明日期规则，重复测试后接受这份有限套件。他们不会称它为恢复点或可迁移的档案。
- 分类每项例外
- 指定决定负责人
- 说明实际影响
- 复测修正项目
完成验收记录
以一份验收表作为交接记录。内容包括范围编号、导出日期和筛选条件、文件清单、记录组、字段定义版本、稳定编号、附件清单状态、排除字段或记录组、合成读回案例、审阅结果、例外事项、决定负责人及最终结论。若团队的交付方式允许，应把实际文件连结或附在该记录，使证据和决定不会散落在不同讯息里。
验收只表示已点名的审阅人按照已说明标准检查了该套件。它不决定未来谁可导出，不证明所有数据都正确，不替代保留或法律意见，不证明灾难恢复流程，也不承诺其他应用程序可以导入这些文件。权限、切换、支持及更广泛验收应留在各自的记录中处理。
结束前问一个实际问题：具备合理业务理解的接收方，能否识别每个已同意文件、理解其字段、找到代表记录、追踪已说明的关联，并看见未包含的内容？若可以，就连同限制记录验收；若不可以，应保持有关例外开放，而不要用笼统交接声明掩盖缺口。
- 保存证据连结
- 确认明确限制
- 取得具名审阅
- 保留未解缺口
Sources and next step
Discuss your workflow scope with BossFlow · Compare system categories at SME Systems · All articles