How to move a Word manual into a searchable policy library

Last checked 2026-10-13 · Original practical information

Moving a Word manual into a searchable library is a document-control project before it is a file upload. The goal is to help staff find the current approved instruction without losing the practice's local knowledge. A large manual may contain policies, procedures, forms, old amendments and helpful notes that do not belong in the same search result. Treat the import as the beginning of review rather than evidence that every page is ready to use.

Preserve the original before making changes

Save an untouched copy of the manual in the practice's authorised storage and note its date and source. Check whether it includes patient examples, staff personal details, tracked changes, comments or passwords. Remove unnecessary sensitive material from the copy prepared for the library, using the practice's approved process. Do not upload a clinical record simply because it has a policy attachment.

Retain the relationship between the import and the original file so you can investigate missing content later. Work on a copy with a clear name and keep a short migration log. Record who prepared it and what was deliberately excluded. Avoid overwriting the only version of the manual while trying to tidy its headings.

Inspect the structure of the Word document

Open the document's navigation pane and check whether the visible headings are real heading styles. Bold text can look like a heading without giving an importer a reliable boundary. Choose a consistent hierarchy: major groups at one level, individual policies at another and sections within each policy below that. Use a copy when changing styles so the original layout remains available for comparison.

Check tables, text boxes, footnotes, diagrams, embedded files and page headers separately. A searchable-text import may not retain every layout feature or attachment. Identify material that needs manual handling and keep the original available to authorised managers. Never assume that a successful upload means the policy's meaning, sequence or important warnings survived conversion.

Decide what should become an individual document

Give each policy or procedure a title that a staff member would search for. A heading such as Administration part three is less useful than the actual subject. Keep sections together when separating them would remove necessary context. Split a long policy only when the new pieces can stand on their own with clear references to related instructions.

Create a short draft index before importing: title, category, intended audience, responsible reviewer and any attached form. This helps you identify duplicate subjects and missing sections. There is no prize for creating the largest number of documents. A smaller library with clear titles and reliable current versions is often easier to maintain than hundreds of overlapping fragments.

Review the proposed split before approval

Use the import review screen to inspect boundaries and names. Merge fragments that belong together; split sections that cover different tasks; rename titles that came from page headers or contents lists. Keep every imported item as a draft until the responsible reviewer has checked it. A table of contents should not become a stand-alone policy accidentally.

Compare several examples to the source file, including the first and last sections, a table-heavy procedure and a document with an attachment. Check that numbered steps have remained in order and that important qualifications are present. If extraction is incomplete, retain the original and arrange manual review rather than filling the gap with guessed wording.

Preserve local wording deliberately

Separate published background from the practice's own arrangements. Local details may describe a role, a handover, a form location or an approved escalation route. Record their purpose so a future editor understands why they exist. Keep the source title and edition in metadata without suggesting that the local document is endorsed by the source publisher.

When an updated starter document or source becomes available, compare it to the existing local document. Review proposed changes as a draft. Do not replace local wording automatically or move the approved pointer before a person has made the decision. Test the update process with a fictional policy containing an obvious local instruction and check that the instruction survives the comparison.

Approve in a useful order

Start with the policies the team needs most often. Check the practical workflow with the people who use it and have the appropriately responsible person approve the exact saved wording. Record the version and next review date. Resolve blanks, uncertain references and outdated contact details before approval; do not make a document look finished by substituting invented practice details.

Make approved material available to the relevant staff while keeping unfinished drafts out of normal staff search. Communicate where the new library lives and what remains in the old manual during migration. Maintain a clear transition plan so staff do not have to guess which system contains the current instruction.

Test search as a staff member

Use the words people say at reception rather than only formal policy titles. Try a subject, a task and a phrase from an approved procedure. Check that results identify the document and version and allow the reader to inspect the source passage. An answer drawn from a policy should lead back to the approved wording, not float apart from it.

Also test what happens when nothing matches. A helpful system should say it has not found an approved answer and direct the person to the responsible role. It should not invent a practice procedure. Confirm that staff cannot find drafts, another practice's documents or material outside their permissions, including through downloads and exports.

Keep an exit and maintenance plan

Check how to export the approved index, versions and history, and how original files are retrieved. A source-code archive is not a backup of the practice's documents. Ask which data and file locations are backed up, how recovery is tested, and who is responsible. The ACSC provides official background on account protection and backups, but the practice must confirm its own arrangements.

Finish the first migration with a small staff walkthrough, a list of unresolved items and a review schedule. Keep the original until the responsible people are satisfied that the approved library and recovery arrangements meet the practice's needs. The work is complete when the team can find, use and maintain the instructions, not merely when the upload has finished.

Sources

• OAIC — Guide to health privacy
• ASD ACSC — Small business cyber security guide

See how this works in the practice hub · Download the original policy review schedule