How to Move COSHH Records from Spreadsheets to Software

Moving COSHH records from spreadsheets to software is a controlled change of source, ownership and workflow. Start by inventorying every file and record type, clean product and location data, match each SDS, map relationships, run a pilot and reconcile the result. Do not treat a successful CSV upload as a completed migration.

What should you inventory before migration?

Find every active and historical source before designing the import. Include:

• chemical and product spreadsheets;
• site and location lists;
• SDS folders, shared drives and paper files;
• COSHH and DSEAR assessments;
• action trackers and review calendars;
• training or acknowledgement records;
• purchasing and waste lists;
• personal copies used by departments.

For each source, record owner, purpose, scope, row count, last update, sensitivity and whether it is active, archive-only or redundant. Shadow spreadsheets discovered after cutover usually reveal an omitted workflow.

What data should be cleaned before import?

Clean identifiers and duplicates while the source is still understandable. Standardise product names without deleting original trade names. Match supplier, product code, concentration and physical form. Separate shared product data from container and location data.

Resolve:

• duplicate products with spelling differences;
• one row containing several products;
• products linked to generic or wrong-supplier SDSs;
• free-text locations that mean the same place;
• missing owners and departments;
• stale stock and deleted locations;
• ambiguous review dates;
• assessments with no product or task link.

The chemical register features can support the target model, but migration decisions should be recorded outside the import file too.

How should SDS files be matched?

Verify each SDS against product name, code, supplier, concentration and form. Capture version, revision date, source and status. Do not attach the first PDF with a similar name.

HSE states that the SDS provides information for assessment but is not itself a COSHH assessment (HSE SDS guidance). Preserve separate links between product, document and task assessment.

How do you map spreadsheet columns to software?

Create a signed-off mapping that states transformation and ownership. For every source column, define the target field, type, required format, allowed values, default, validation and treatment of blanks.

Never convert uncertainty into a confident default merely to make the importer accept it.

What should the pilot include?

Choose a representative site or department with real complexity. Include duplicate products, multiple locations, revised SDSs, open actions and different assessment types.

Validate:

1. record counts by type;
2. product-to-SDS matches;
3. product-to-location quantities;
4. assessment relationships and versions;
5. user permissions;
6. review dates and open actions;
7. search and export;
8. audit history;
9. mobile or point-of-work access;
10. rollback export.

Have local users perform receiving, lookup, assessment review, transfer and disposal tasks. A migration can be technically correct but operationally unusable.

How should the cutover be controlled?

Set one source of truth and a clear freeze window. Communicate when spreadsheet editing stops, capture changes during the freeze, run the final import, reconcile totals and approve release.

Keep original files read-only under retention controls. Do not delete them simply because the new system is live. Define rollback triggers, decision authority and how to export data if the launch fails.

The Safe Foundry workflow can support ongoing records after the cutover, while the migration log proves what moved and what did not.

How do you validate after launch?

Perform a physical and document sample, not only database counts. Start from selected containers at several sites, trace the product, current SDS, assessment, location and owner, then reverse-check expected stock.

Track exceptions such as unmatched SDSs, duplicate products, missing owners, invalid locations, failed permissions and overdue assessment reviews. Assign owners and deadlines.

What should happen to old spreadsheets?

Remove them from active workflows once validation is complete, but retain approved archives where required. Mark them superseded, restrict editing and direct users to the new source.

Do not leave exported copies in email or personal drives. Apply access, retention and secure disposal rules. Use the help centre for setup and record guidance.

A successful migration gives every record a trustworthy identity, relationship and owner. The software adds value after that foundation is established; it cannot infer which duplicate or document was right.

How should locations and quantities be migrated?

Build the location hierarchy before importing stock. Give every site, building, room, store and cabinet a stable identifier, owner and status. Map each spreadsheet location to that list and quarantine ambiguous entries such as “main store” or “workshop cupboard”.

Decide whether the target tracks products, stock lines or individual containers. Preserve units and do not add quantities with incompatible measures. Record whether a value is nominal container size, estimated remainder or exact measured amount. Reconcile totals by site and location before and after import.

Where a container appears at two locations, investigate the movement history rather than choosing the newest row automatically. Duplicate location records can conceal real unregistered stock.

How should permissions be tested?

Validate what every role can view, create, edit, approve, export and delete. Include site users, central EHS, supervisors, auditors and administrators. Test cross-site boundaries with real scenarios rather than relying only on a role matrix.

Chemical inventories, private documents, assessment signatures and location data should be accessible only to authorised users. Check that a shared product record can be read where needed without exposing another site's private records. Confirm that exports and API credentials follow the same boundaries.

What training is needed for cutover?

Train each role on the event that creates or changes data. Receiving staff need product matching and quarantine. Users need search, QR or location access and discrepancy reporting. Assessors need source verification, version review and approval. Administrators need import, recovery and audit procedures.

Use real pilot records and exception cases. A perfect “happy path” demonstration does not prepare a user for a wrong label, duplicate product or unavailable SDS. Provide a support and escalation route for the first weeks.

Which migration measures show readiness?

Use reconciliation and quality measures before declaring success. Track source rows, imported records, rejected rows, duplicates resolved, products with verified SDSs, assessments with valid relationships, locations with owners and permissions tested.

Set acceptance thresholds and require explanations for differences. Keep a signed exception list for records intentionally excluded or retained only in the archive. After launch, monitor new duplicates, unresolved imports and continued spreadsheet use.

How should rollback be designed?

Rollback should restore operational access without erasing evidence created during cutover. Preserve the final source snapshot, import manifest, transformation rules, target export and record of changes made after launch. Define who can order rollback and how new records will be reconciled.

Test the export and restoration path during the pilot. A statement that data “can be exported” is not enough until files, attachments, relationships and timestamps have been inspected.

How should historical files be classified?

Choose a treatment for every record group before migration. Options include structured import, indexed document archive, external controlled retention, manual re-entry or exclusion with an approved reason.

Do not mix active and historical assessments in the same status. Preserve effective dates, superseded state and the product or task they applied to. Where a PDF bundle cannot be separated economically, index its scope and owner so it remains discoverable.

What should the first post-launch review cover?

Review data and behaviour after users have completed real work. Check new product creation, duplicate rate, receiving exceptions, transfer accuracy, assessment review queues, document access and support requests.

Compare a fresh physical stock sample with the system and interview users about workarounds. Close migration actions, update training and decide when read-only legacy access can be restricted further under the retention plan.