Moving Away from Legacy Occupational Health Software: A Practical Migration Guide

Occupational health providers often keep using software after everyday work becomes awkward. That is not necessarily reluctance to modernise. The existing system may hold years of sensitive clinical information, alongside commitments to employers and Employees that cannot pause during replacement.

A move may involve thousands of records, open Cases, future Appointments, outstanding Reports and historical health surveillance assessments. Each record has a place in the work. A Report attached to the wrong Employee, or a recall detached from its programme, can be harder to use than a record left in the old system.

The difficult part of occupational health software migration is preserving those relationships, histories and unfinished tasks. A well-planned migration should be a controlled transition, not an operational leap of faith. This guide sets out what to move, how to check it and how to keep the service working during the change.

When should you consider replacing your occupational health software?

Software age is a poor measure of quality. A mature platform may remain appropriate if it is supported, maintained and effective. The question is whether it still carries the work, or whether staff have built a second system around it.

Look for repeated manual entry, key processes in external spreadsheets and Cases whose owner or next action is unclear. Limited reporting or difficult data extraction hinders oversight. Inflexible Forms, costly configuration changes and supplier-specific workarounds make ordinary pathway changes harder.

Employer experience matters too. A portal that cannot handle Referrals or appropriate updates may push sensitive information into email. Difficult integrations cause further duplicate entry. Ask how the supplier maintains supported versions, responds to security issues and keeps essential work available during interruptions. These are business-continuity questions, not assumptions that older software is insecure.

Record the problems and their consequences before comparing occupational health software alternatives. A replacement is worthwhile when it addresses real operational constraints and the cost and risk of changing are understood. Compare subscription, implementation and migration costs together.

What occupational health data actually needs migrating?

Occupational health data is not simply a folder of PDFs or rows in a spreadsheet. A useful inventory describes the records and the links between them:

• Employer Clients: Organisation details, contacts, sites and relationships with Employees.
• Employees: Identity, employment history and associations with current or former Clients.
• Referrals: Original requests, submission dates and history. A Referral records what was asked; see our guide to occupational health referrals.
• Cases: Status, ownership, Appointments, progress and outstanding work. A Case is the managed response to a request, distinct from its Referral or Report. Our Case management guide explains the difference.
• Clinical records: Assessments, notes, amendments and historical context.
• Health surveillance: Earlier assessments, longitudinal findings, programme membership and recalls. A due date without its associated risk and results may mislead. See our health surveillance software guide.
• Documents and Reports: Files, versions, access restrictions and associated records.
• Operational configuration: Users, permissions, Forms and workflow settings. Document how old settings affected historical records.

An assessment imported without its Employee, Case or surveillance programme may exist but be hard to interpret. Map source identifiers to destination identifiers for reconciliation. Review duplicates, inconsistent dates, missing employer links and conflicting names. Do not silently merge people or infer clinical dates from file names.

Decide how to handle records where one Employee has worked for several Clients, or where a Client has changed its name. A current employer relationship should not rewrite the historical context of an earlier assessment. Test these cases explicitly rather than relying on a matching name or email address.

Not every historical item must become a live record. Some may remain in a secure, accessible archive where clinical, operational and legal requirements allow. Agree retention and test retrieval.

A practical seven-step occupational health software migration plan

1. Audit the existing system

List record types, volumes, export formats and integrations. Include future Appointments, open Cases, outstanding Reports and recalls. Identify retention requirements and who understands older fields. Exported tables alone do not explain how a service used them.

2. Define what needs to move

Separate active work, historical clinical records, configuration and material suitable for an archive. Decide what must be searchable on day one and what can be retrieved through a documented route. Budget staff time for cleaning and validation.

3. Confirm data ownership and export arrangements

Review contract and termination terms, supplier assistance, export functions, formats and charges. Establish who supplies files and how completeness is checked. Discuss portability before choosing a replacement. A right to information does not imply a particular export format.

Agree responsibilities across the existing supplier, replacement supplier and provider. A quote should specify who extracts attachments, cleans data, maps fields, resolves exceptions and signs off. This is where switching costs sit.

4. Map records into the replacement system

Map fields and relationships to the destination. Preserve distinctions between a Referral, Case, Appointment and clinical assessment. Define rules for Employee identity, statuses, dates, document versions and unknown values. Record decisions that affect clinical meaning and assign unresolved exceptions.

5. Perform a test migration

Sample long clinical histories, open Cases, multiple employments, recalls and restricted documents. Use protected real records or synthetic data as appropriate. Compare counts, relationships, file integrity, chronology and permissions. Have clinical and operational users retrieve records through normal screens.

6. Plan the transition

Agree a cutover window, owners, training, communications and contingencies. Decide where new Referrals and Case updates belong during the move. Specify how changes made during migration will be reconciled. Keep any freeze as short as practicable.

7. Verify, retain and retire

Reconcile counts and exceptions after cutover. Check open work, future Appointments, unreleased Reports and recalls. Confirm backups, archive access, retention and deletion. Keep the original platform accessible under controls until relevant obligations are satisfied. Do not retire it on the strength of the first import alone.

Migration checklist:

• Confirm inventory, exports and retention decisions.
• Review field and identifier mapping with clinical and operational leads.
• Test counts, relationships, files, dates and permissions.
• Assign cutover, reconciliation, training and rollback responsibilities.
• Verify open work, recalls, archives and backups after cutover.

Preserving clinical history and confidentiality

Health information is special-category personal data, and occupational health communications also engage a duty of confidence. The ICO's guidance on workers' health information calls for security appropriate to its sensitivity. Software alone does not satisfy data-protection duties.

Set out who may access clinical notes, who may coordinate a Case without seeing them, and what an employer may receive. The employer may need advice on fitness, adjustments or timing, but that does not give general access to an Employee's clinical history. The ICO's occupational health guidance explains that medical details should be disclosed to managers only where needed for their responsibilities.

Protect files during transfer and temporary storage. Limit and audit access, then delete temporary copies under an agreed plan. Preserve amendments and context. After import, test clinical and employer-facing permissions across search, downloads and Reports. A correct file in the wrong view is a failed migration. Occentra's security approach describes its role boundaries.

What the October 2026 PHP vulnerabilities teach us about software dependency

On 21 October 2026, two critical PHP vulnerabilities were publicly disclosed. NHS England's advisory assigns each a CVSS v4 score of 9.2. CVE-2026-109618 concerns out-of-memory handling that could leave request memory in an invalid state, creating a route to memory corruption and remote code execution. CVE-2026-109619 concerns internal request state retained after its backing memory was freed; a later request could use that invalid state and potentially execute code. Ubuntu's security notice covers both issues, and its CVE-2026-109618 record describes the first in more detail.

The UK National Cyber Security Centre urged affected organisations to identify their PHP systems and apply updates promptly, prioritising internet-facing services. PHP supports many web applications, from longstanding commercial products to actively maintained frameworks such as Laravel. Using PHP does not make a product legacy, and changing programming language is not a security plan. A serious dependency issue can affect a well-maintained product too.

For buyers, the useful questions are operational. How quickly does a supplier identify and assess critical vulnerabilities? Does it maintain supported runtime versions and deploy patches promptly? Is there an incident-response procedure, a documented business-continuity approach and a way to continue essential work during an outage? How will customers hear about security incidents or service interruptions?

Precautionary downtime can be a responsible response to a serious issue; it is not evidence that a supplier was attacked. The lesson is to evaluate how a supplier maintains, patches and recovers its software, alongside what the product can do on an ordinary day. No platform can promise immunity from future vulnerabilities.

How to avoid disruption during migration

Several transition patterns can work. Parallel operation keeps both systems available for a short, controlled period while users verify new workflows. It can reduce uncertainty but creates a risk of duplicate records, conflicting changes and unnecessary exposure of clinical information. Define which system is authoritative for each activity and close the overlap once checks are complete.

Phased migration moves a defined group of Clients, Employees or workflows first. It can expose mapping problems before they affect the whole service, but cross-system Cases and shared staff need careful handling. A planned cutover uses an agreed window, a short freeze where necessary and a reconciliation of changes recorded during the transfer. Rollback arrangements should say what happens if validation fails, who makes that decision and how work recorded since cutover is retained.

Train staff before the first live Referral arrives. Give them one clear rule for where new work belongs and a contact for exceptions. A migration can be technically complete while the service is still confused about where to record a follow-up. Choose the pattern that fits the provider's workload, available export and tolerance for duplicate work; there is no universal approach.

Questions to ask a prospective occupational health software supplier

Use a real Referral, open Case and surveillance history when asking these questions:

1. What import formats do you support?
2. Can historical clinical information and its context be preserved?
3. How do you handle existing Referrals and open Cases?
4. Can documents and Reports be linked to the correct records and versions?
5. How are clinical access permissions controlled and tested after import?
6. What migration assistance is available, and what does it cost?
7. Who is responsible for data mapping, exceptions and validation?
8. What happens if the test or final migration fails?
9. How are critical vulnerabilities assessed, patched and communicated?
10. How can we export all our information, including files and relationships, if we leave your platform?

Ask for written scope and evidence where it matters. A good supplier should be prepared to discuss exit arrangements before a customer signs up. That conversation also tests whether the supplier understands that occupational health business continuity depends on more than keeping a login page available.

Where Occentra fits into a modernisation project

Occentra organises Clients, Employees, Referrals, Cases, Forms, Documents and operational workflows as related records. This helps teams see the original request, accepted work, clinical assessment and released Report as distinct parts of one service.

The relationships matter during migration as much as in daily use. They give a provider concrete questions for mapping source data: which Employee does this assessment concern, which Case produced this Report and who may see it? The answers still have to be established and checked for each source system.

Configurable Forms and workflows support different pathways without bespoke development for every change. Role-based access separates clinical work from operational and employer views. A shared product core supports ongoing maintainability.

Migration still needs a source-specific plan. Confirm import formats, historical relationships, mapping and validation responsibilities, assistance and cost during a walkthrough. Some records may be better archived. Considering a move away from your current software? Book an Occentra walkthrough to discuss your requirements.

Final thoughts: Migration is a project, not a product feature

Replacing occupational health software takes more than choosing a platform with an import button. It requires decisions about clinical meaning, record relationships, active work, access and the point at which the old system can safely be retired. Those decisions belong to the provider and its suppliers together, with named people responsible for checking the result.

Done carefully, the move need not lose years of useful history or create avoidable disruption. The replacement should improve how work is managed while preserving the information needed for continuity of care and service delivery. The most useful question to bring to any supplier, including Occentra, is: can we show how one real Case and its history will survive the move?

Frequently asked questions

How long does it take to migrate occupational health software?

Timelines depend on data volume, export availability, relationships, quality and validation. Ask for a plan based on your records.

Can historical occupational health records be migrated?

Feasibility depends on source formats, relationships and destination import capabilities. Test a representative history before agreeing scope.

Do we have to migrate every historical clinical record?

Selective migration and secure archiving may be appropriate if clinical, operational and legal obligations are met and records remain retrievable.

How can we avoid downtime when switching systems?

Plan cutover, brief parallel operation where appropriate, reconciliation and contingencies. Make clear which system holds new work.

What if our existing supplier cannot provide an export?

Review contractual rights, reporting or export functions, data-protection obligations and specialist assistance. UK GDPR does not guarantee a particular technical export format.