How to get your health, safety, quality and environmental data out of any system

The short answer

Ask for the export in writing before you give notice, demand the attachments and the sign-offs as well as the rows, and verify the whole thing against real records while you still have read access to the old system. Those three sentences prevent almost every migration failure we have seen. The rest of this page is the detail behind them.

The reason this matters more in HSEQ than in most software categories is that your records are not merely operationally useful — a good number of them are things you are legally required to hold, sometimes for decades, and that duty stays with you rather than with whichever provider happens to be storing the file. A migration that loses a training certificate or an incident attachment does not just lose data. It creates a gap in evidence you may have to produce years later, for a regulator, an insurer, a certification auditor or a court.

What you must keep, and for how long

Start here, because the retention requirement decides the migration scope rather than the other way round. The periods vary enormously by record type — from five years for some incident records to forty years for some health monitoring — and they are set by law, not by your vendor's data retention policy. Work out what binds you first, then design the export around it.

New Zealand

Two anchors are worth knowing precisely, because they set the outer bounds. Under section 57 of the Health and Safety at Work Act 2015, a PCBU must keep a record of each notifiable event for at least five years from the date on which notice of the event was given to the regulator under section 56. WorkSafe states the same requirement in its own guidance on notifiable events.

At the long end, the Health and Safety at Work (General Risk and Workplace Management) Regulations 2016 set far longer periods for monitoring records. Regulation 42 requires a health monitoring report to be kept for 40 years after the date the record is made if the monitoring was undertaken to detect asbestos-related disease, and 30 years in any other case. Regulation 32 applies the same 40-and-30-year split to exposure monitoring results — and adds a requirement that is easy to miss during a migration: those results must remain readily accessible to any person at the workplace who may be, or may have been, exposed to the health hazard. A record sitting in an unindexed archive folder that nobody can search is arguably not readily accessible.

Those are the two ends of the range. Plenty of other records — employment and wage records, tax records, personal information held about workers — carry their own retention periods set by employment, revenue and privacy law rather than by health and safety law. Check those separately, and check the current text of anything before you rely on it: legislation is amended, and a guide written in 2026 is not a substitute for the version in force when you read it.

Australia

The structural point comes first, because it changes how you look everything else up. The model WHS laws published by Safe Work Australia are not law in their own right — the Commonwealth, states and territories each have to implement them as their own legislation, and each makes variations. Victoria is the only jurisdiction that has not implemented the model laws at all, and runs its own OHS regime instead. So "the Australian rule" is not a thing; your jurisdiction's rule is.

Within that, the shape mirrors New Zealand closely, which is unsurprising given the New Zealand regulations carry explicit comparison notes to the Australian model regulations. Under the model WHS Act, a record of each notifiable incident must be kept for at least five years. The model WHS Regulations impose much longer retention on health monitoring and exposure or air monitoring records — decades, and longer again where asbestos is involved.

We have deliberately not quoted a specific number for the Australian health monitoring period here. The periods differ between the model text and the implemented text in each jurisdiction, and we could not verify a current figure directly from Safe Work Australia while writing this. Take the principle — these records are kept for decades, not years, and asbestos is longer than everything else — and confirm the exact period that binds you with your own state or territory regulator before you decide what to archive and what to discard. Being approximately right about a forty-year duty is not good enough.

The practical rule

If you take one thing from this section: you cannot delete your way out of a retention obligation by changing software vendor. Leaving a provider does not end the duty, and "our old system was decommissioned" is not an answer anyone will accept. So the export is not an optional convenience at the end of the project — it is the part that discharges a legal obligation, and it belongs at the front.

What to ask for, and in what format

Ask for five distinct things, not one. Most providers, asked for "an export", will produce structured data and consider the job done — and structured data is the easiest fifth of what you actually need. Name each of the five separately in writing so nobody can deliver one and claim they delivered all.

1. 1.Structured records, as CSV or Excel, one file per record type. Incidents, hazards and risks, audits and inspections, corrective actions, training and competency records, assets, contractors, documents register, obligations. Ask for every field including the ones that are hidden in the interface, and ask for internal record IDs — you will need them to reconnect attachments to records later.
2. 2.The original file attachments, as actual files. Photographs, certificates, PDFs, signed forms, SDS sheets, insurance documents. Not thumbnails, not links into a system you are about to lose access to. Ask for them in folders named by record ID, or with a manifest file mapping each filename to its record — otherwise you will receive nine thousand files called IMG_0423.jpg with no way to tell what any of them belong to.
3. 3.Signatures and sign-offs, with who and when. Every electronic signature, acknowledgement, read-receipt, induction completion and approval, with the name of the person, the timestamp, and what exactly they signed. This is the item most likely to be missing, and the one hardest to reconstruct afterwards.
4. 4.The audit trail. Who created, edited, approved or closed each record and when. If you are certified or heading for certification, this is what demonstrates the record was not written after the fact, and an auditor who suspects backdating will ask for precisely this.
5. 5.A human-readable rendering of the complete record. A PDF of each closed incident or completed audit, as it appeared on screen, with its attachments referenced. Structured data is for importing; the PDF is what you hand to an auditor, an insurer or a lawyer in five years when the system that produced it no longer exists. Ask for it for the significant records at minimum — notifiable events, serious incidents, completed audits.

On formats: insist on open, boring ones. CSV, Excel, PDF and the original file types for attachments. A proprietary backup file that only the vendor's own software can open is not an export — it is the same lock-in wearing a different hat. If a provider offers an API instead of a file export, that is fine and often better, but ask who is going to run it, because "there is an API" frequently means "you can pay a developer to build your export".

The email to send your current provider

Put it in writing, send it to an address that creates a record rather than raising it in a phone call, and send it before you give notice — while you are still a paying customer and the relationship is still cordial. Adapt the wording, keep the specificity. The point is that every item has to be answered individually.

Question seven is the one that most often produces a surprise, and question eight is the one that settles it. Read the answers against your contract rather than instead of it. If the answers are vague, ask again and ask for the clause — a provider who will not put their own contractual terms in writing has told you something useful about how the exit will go.

What usually goes wrong

Two things account for most of the damage, and neither is exotic: attachments and historical sign-offs. Both share a characteristic that makes them dangerous — the record appears to have migrated perfectly, because the row arrived, and the loss is only discovered when someone opens that record for a reason that matters.

• Attachments arrive as references, not files. The export column says incident_4471_photo.jpg or holds a URL pointing back into a system you are about to stop paying for. Nothing is technically missing from the spreadsheet; everything is missing from the evidence.
• Signatures were rendered, not stored. An induction sign-off or a document acknowledgement often exists as something the interface draws from several fields rather than as an exportable column. It looks permanent on screen and has no representation in the export at all.
• Closed records lose their closure. The corrective action imports as open because the destination system does not have a matching status, or the closure date and the person who verified it land in fields nobody mapped. You end up with hundreds of apparently overdue actions and no way to tell the real ones from the artefacts.
• Dates shift. Date formats between systems, and timezone handling, are a reliable source of records that appear to have been raised the day before they were reported or closed before they were opened. Check a sample against the old system rather than assuming.
• People records break the links. Staff who have left, name changes, and duplicate user accounts mean training records and sign-offs attach to the wrong person or to nobody. Former employees matter here — their records are frequently the ones with the longest retention requirement.
• The export is taken too late. Notice is given, the account moves to a wind-down state, and access ends on a date somebody agreed to without reading. Everything above becomes unfixable at that moment.

A sequence that avoids a compliance gap

Run the export and the switch as two separate projects, in that order, with an overlap between them. The compliance gap happens when organisations treat the migration as a single event on a single date — old system off, new system on — because everything that did not make the journey is discovered afterwards, when there is no longer anywhere to go and get it.

1. 1.Weeks 1–2: establish what you must retain. List your record types and the retention period that applies to each, checking current regulator guidance rather than memory. This produces the scope for everything that follows.
2. 2.Week 2: send the email above. Before notice. Get the answers and the costs in writing, and read them against your contract.
3. 3.Weeks 3–4: take the full export and archive it. Everything, not just what you intend to import. Store it somewhere you control — your own cloud storage or file server, not a folder inside either software product — with a dated README saying what it is, when it was taken and what system it came from. This archive is what discharges your retention obligation for anything you do not migrate.
4. 4.Week 4: verify it, using the checks below. Before you go any further, and while you still have the old system to compare against. If something is missing, you are still a customer and you can still ask.
5. 5.Weeks 5–6: import the working set into the new system. Typically the last three years of incidents, audits and corrective actions, all current registers, and all live training and competency records. Reconcile record counts per type, then spot-check.
6. 6.Weeks 6–8: run both in parallel for one full cycle. One monthly inspection round, one incident from report to close, one training expiry. New records go in the new system only; the old one is read-only reference. This is when you find out what you missed, while it is still recoverable.
7. 7.Then, and only then, give notice. With the archive verified, the working set imported and one full cycle behind you. Confirm in writing the date access ends and the date the provider will delete your data, and diarise both.

Do not do this in the eight weeks before a certification, ACC or client audit, and do not do it in your busiest operational season. The best window is immediately after an audit: a clean baseline, a list of findings worth carrying, and the longest possible run before anyone examines it again.

Verifying the export before you cut over

Verification is sampling, not reading everything, and it takes about half a day. The aim is to prove each of the five things you asked for actually arrived, using real records rather than the count at the bottom of a spreadsheet. Do it while you still have the old system open beside you, because that is the only moment a discrepancy is cheap.

1. 1.Count first. Records per type in the export against the same count in the old system, for the same date range. Any difference at all gets explained before you proceed — an unexplained difference of three records is a process fault, and process faults do not stay small.
2. 2.Open your five worst incidents. The most serious events you have, including anything notifiable. Every photograph, statement, investigation document and sign-off should be present and openable. These are the records that will be asked for; they are the ones to check by hand.
3. 3.Count the attachment files. Total files in the export against the total attachment count in the old system, and open twenty at random to confirm they are the real file and not a placeholder, a thumbnail or a zero-byte stub.
4. 4.Prove one signature end to end. Pick an induction or document acknowledgement from two years ago and confirm the export shows the person's name, what they signed, and when. If you cannot find it, signatures did not come and you need to say so now.
5. 5.Check the oldest and the newest. The earliest record in your retention window and yesterday's. Boundary records are where truncated date ranges and off-by-one filters show up.
6. 6.Check a leaver. Someone who left two years ago. Their training records, inductions and incident involvement should all still be present and attached to them.
7. 7.Open the archive somewhere else. On a different computer, with nothing but standard software — Excel, a PDF reader, an image viewer. If it needs the vendor's product to be readable, it will not be readable in five years, and you do not have an archive.

Write down what you checked, when, and who did it, and keep that note with the archive. It takes two minutes and it is the difference between telling an auditor "we migrated in 2026" and showing them that the migration was verified.

Where we come in

Teammate App is our product — an all-in-one health, safety, quality and environmental platform built and supported in New Zealand — and yes, we help people migrate into it, including mapping an export from another system into incidents, risks, audits, training and asset records so the history arrives with the attachments and the dates intact. If you are considering us, ask us to do the verification checks above on your data and show you the result before you commit to anything.

The reason this guide is deliberately vendor-neutral is that the advice does not change based on who you pick, and a page that only worked if you chose us would not be worth writing. The checks above apply to leaving us as much as joining us — and if you ever do leave, ask us the eight questions in that email and hold us to the same standard. A provider who is comfortable telling you how to leave is telling you something about how they expect to keep you.

Questions we get asked