Move safety records without losing the history people need

Moving records into a new system can look like a simple import until someone asks for the attachment, old asset name or decision behind a closed action. The visible rows are only part of the history. A useful migration plan identifies what colleagues need to retrieve later and tests whether those relationships survive the move.

Begin with the operational questions, not only the file format. Which inspection belongs to this asset? Why was the action extended? What evidence supported closure? Who can access a sensitive record? These questions help define the migration scope and acceptance checks. They also reveal material that may need to remain in a controlled archive rather than being forced into an unsuitable field.

Inventory the sources before promising a date

List the systems, spreadsheets, folders and attachments in scope. Identify the owner and purpose of each source. A spreadsheet used for current actions may coexist with a separate document folder containing their evidence. Migrating one without the other can leave a complete-looking list that no longer answers useful questions.

Record uncertainty about the sources. If nobody knows whether a folder is current, investigate before treating it as authoritative. Avoid combining conflicting datasets simply because their columns resemble each other. Establish which records represent the current position and how older versions should be retained under the organisation's record practices.

Migration review context photographed by Mikhail Nilov on Pexels.

Map meanings as well as column names

A field called complete may mean work performed in one source and independently checked in another. Document these differences before mapping values into the new system. Otherwise migration can change the apparent meaning of historical records without changing their text. Ask the process owner to resolve ambiguous statuses and preserve relevant context.

Keep original identifiers where they are needed to connect records. Decide how old and new identifiers relate and how users can search for familiar references. Asset names, site names and action numbers may appear in external supplier reports that cannot simply be renamed. A mapping table can preserve that connection if maintained and accessible to the right users.

Decide how to handle imperfect information

Existing data may contain duplicate entries, missing owners and inconsistent dates. Define how each issue will be handled. Some records can be corrected from reliable evidence; others need a visible limitation. Do not invent a date or owner merely because the target system requires a value. Escalate the design question and document the agreed treatment.

Keep a record of consequential transformations. If categories are combined or statuses translated, future reviewers should understand the change. Avoid cleaning historical records so aggressively that the original account becomes unrecognisable. Improving search and structure is useful, but it should not quietly rewrite what the organisation recorded at the time.

Treat attachments as part of the scope

Confirm which file types, sizes and relationships the receiving system supports. Ask the supplier to demonstrate how migrated attachments are linked and retrieved. A successful row count does not establish that every photograph or report remains accessible. Include records with multiple attachments and corrected versions in the test sample.

Where information remains outside the new system, define the reference and access arrangement. Test the link as an ordinary authorised user, not only as the administrator performing the import. A private path on someone's computer is not a durable reference. The receiving team needs a clear way to find the information after the migration project ends.

Operational record context photographed by Tiger Lily on Pexels.

Test permissions and retrieval together

Have the relevant privacy, security and records colleagues review the proposed access model. Migration can accidentally broaden access when previously separate files enter one shared environment. Confirm which roles should see which information and test representative examples. Keep test material appropriately fictional or anonymised where practical during early demonstrations.

Also check whether the people who need operational information can actually reach it. Excessively narrow access can create a different failure when an authorised reviewer cannot see the evidence behind a finding. The appropriate balance depends on the record and responsibilities. Establish it deliberately rather than inheriting default settings without review.

Run a pilot that includes awkward records

Choose a varied sample: a moved asset, an open action, a closed action with evidence and a record with a later correction. Trace each from source to destination. Compare both the visible data and the story it tells. Ask a person familiar with the work to retrieve it using the new system's normal interface.

Document discrepancies and resolve them before expanding the import. Retest the affected mappings after changes. The pilot should establish what works and what remains uncertain, not serve as a ceremonial milestone. A small but representative sample is more useful than a large set of simple records selected because they are easy to import.

Reconcile the result at more than one level

Compare record totals where that is meaningful, but also inspect a sample of relationships and content. Matching row counts can conceal a missing attachment or a status mapped incorrectly. Conversely, an explained consolidation of duplicates may produce different counts without representing lost information. Record the basis for the comparison so the acceptance decision can be understood later.

Ask the process owner to review the exceptions rather than treating them as purely technical import errors. A missing owner on an active action needs an operational decision; an unsupported file type needs a retrieval arrangement. Different problems require different people. Keep their resolutions connected to the relevant records and mapping notes.

Confirm that the final test uses the actual agreed configuration and scope. Results from an early demonstration may not apply after field mappings or access settings change. Retest affected parts when consequential changes are made. A clear acceptance record states what was checked, what limitations remain and who owns them, giving the receiving team a practical account of the migrated information.

Plan the handover into normal use

Decide how new records will be handled during the transition so the same issue is not maintained independently in two places. Communicate the agreed cutover arrangements and the route for reporting migration problems. Preserve required source material through the organisation's approved retention process; do not delete it solely because an import finished.

Assign ownership of the mapping notes, unresolved exceptions and archive access after launch. A migration team may disband while users still need answers. Make the remaining work visible in a controlled list with accountable owners. Review a few real retrieval requests after the system is in use to see whether the history remains understandable.

The references in HSE's Great Britain work equipment inspection guidance illustrate why accessible records matter for relevant equipment. Actual retention, access and migration requirements vary by record type and jurisdiction. This article provides planning questions, not a universal retention schedule.

Explore Asset Management and Compliance Management. Read Choosing safety management software to make migration evidence part of the supplier evaluation before committing to a rollout plan.