Moving to a new platform is an opportunity to connect the agency around shared records and reduce duplicated work. Plan the migration around the information your team needs to keep making placements, the workflows you want to improve and the reporting managers will use. Treat it as a project with an owner, a plan and a sign-off at each step, not a file transfer. The runbook below follows a practical order: protect live work, clean and map the data, test, run in parallel, cut over, then support the team through the first weeks.

Start with the work you need to protect

Identify active candidates, current clients, open vacancies and live placements. Include the documents, rates and contact history your teams need to continue that work. Agree how historical records will be retained and accessed before deciding what to move.

Build an inventory of every source

List where information lives today. In a healthcare staffing agency it is rarely one place. A typical inventory includes:

Candidate spreadsheets kept by each desk or branch, often with different columns.
Shared drives or email folders holding compliance documents, references and contracts.
Booking spreadsheets showing shifts, sites and rates.
Client and contact lists, including the ward or department contacts who approve timesheets.
Exports from any existing recruitment system, accounts package or payroll tool.

For each source, record its owner, roughly how many records it holds, when it was last updated and whether it is the master or a copy of something else. Sources without an owner need the most checking.

Agree the scope

Decide which records move as live data, which move as history and which stay behind. A practical rule is to move every candidate with recent activity or current compliance documents, every client with live or recent work, and every open vacancy and live placement. Older records can be archived under your agency's retention policy rather than imported. Write the rules down and agree them with the managers who will rely on the data, because they will be the first to notice what is missing.

Name the owners

Give the migration one accountable owner with authority to make decisions, and name a data owner for each area: candidates, clients and contacts, compliance documents, and placements with their rates and finance records. Data owners answer mapping questions, approve merges and sign off test imports for their area. Without them, decisions fall to whoever is running the import, who rarely knows which of two conflicting rates is correct.

Clean and map the records

Review duplicates, missing information and inconsistent statuses. Map fields into the new platform, including the relationships between candidates, vacancies, contracts and clients. Those relationships matter for reporting as much as the individual records.

Cleanse before you move

Fix data quality in the source, or in a working copy, before the import. Moving a problem into a new system only makes it harder to see. Typical issues in spreadsheet data include:

The same nurse registered by two branches with different phone numbers or email addresses.
Statuses typed by hand, so "Available", "avail" and "on books" all mean the same thing.
Grades and specialities written as free text in several forms.
Dates entered in mixed formats, which an import can misread without warning.
Rates stored as text with notes attached rather than as numbers.

Agree who decides when two records are the same person and which version of each detail survives. Never merge automatically on name alone.

Map each field

Build a mapping document with one row per source column: the target field, any transformation, the default when a value is blank and who signed it off. Give particular attention to value lists such as grades, specialities, statuses and compliance document types, because candidate matching, compliance checklists and reports all depend on them. Avoid the shortcut of putting every unmapped column into a notes field. Information held in notes cannot be searched, matched or reported reliably.

Preserve the relationships

In spreadsheets, relationships are often held by name: a booking row names the hospital and the nurse in plain text. A new platform links records by identity, so each relationship has to be resolved explicitly. Match candidates, clients, sites and contacts to a single record before importing the placements, rates and timesheets that point at them. If one hospital appears under three spellings, decide which record they all belong to first, or its placement history and margin will be split across three clients.

Plan the documents

Compliance documents need more than the file. For each one, capture the candidate it belongs to, the document type, the issue and expiry dates and its current review status. A folder of scanned certificates without that information will need re-checking by hand after go-live. Decide which documents move, how they will be named and who will confirm that expiry dates came across correctly.

Test a complete workflow

Import a representative sample and follow a placement from vacancy capture and candidate matching through document collection, booking, timesheet approval and finance. Check that information carries forward correctly and that the reports reflect the result. Resolve mapping gaps before the full migration.

Choose a sample that includes the awkward cases as well as the routine ones. For example:

A locum doctor on a long assignment that was extended at a new rate.
An agency nurse working nights and weekends across two wards, with different rates for each.
An allied health professional placed permanently, with a fee rather than timesheets.
A care worker with a compliance document about to expire.

For each case, check record counts against the source, open the linked records, confirm that rates and documents arrived intact and compare report figures with the numbers you expected. Log every difference, fix the mapping, then import the sample again. Repeat until a full pass is clean and the managers involved have signed it off. Then rehearse the full load at least once, if the provider supports it, and time it so you know how long the cut-over window needs to be.

Run old and new side by side

A short period of parallel running lets you compare outputs before the old sources are retired. Focus it on the processes where an error costs most: timesheets, pay and invoicing. Run one cycle through both and check the results line by line, including at least:

Hours, shifts and rates on each approved timesheet.
Candidate pay, client charge and margin for each placement.
Invoice totals for each client in the period.

Keep the period short and its rules explicit. Agree which system is the master for each activity while both are live, otherwise consultants will update whichever is nearer to hand and neither will be complete. Parallel running without an end date is how migrations stall.

Prepare people for go-live

Train each team on its daily workflows, including AI-supported tasks, approvals and exceptions. Agree when the new system becomes the source for live activity and how historical information will remain accessible under your retention arrangements.

Train by role

Train with the agency's own data where possible, and by role rather than by feature. A consultant needs to find candidates, log calls and progress a booking. A compliance officer needs checklists, uploads and document review. Finance needs timesheets, pay runs and invoices. Short sessions close to go-live, followed by a named contact for questions, work better than one long session weeks before.

Plan the cut-over

Choose a cut-over point that avoids the middle of a timesheet or pay period, and publish it in advance. A practical checklist:

Freeze changes to the old sources at the agreed time.
Import the records created or changed since the last full load.
Reconcile counts of active candidates, clients, open vacancies and live placements.
Confirm that open timesheets and the current pay period are in the right place.
Connect the inboxes and calendars the new platform will use.
Make the old sources read-only and tell the team who to contact with issues.

Avoid going live just before a weekend or public holiday, when shifts are being filled out of hours and support is thinnest. Make sure the people who can fix problems are available for the first days.

RecSphere's onboarding follows the same shape: agree the scope, map the data, test a sample import, train each team and support the agreed go-live.

Review the first weeks

Check adoption, missing records and unfinished handovers. Compare the new reports with your agreed starting figures, then use them to review consultant productivity and placement progress. Focus on getting the shared workflow established before adding further automation.

Run a hypercare period

For the first few weeks, treat the platform as a project still in progress. Hold a short daily check-in, keep a single issue log and give each issue an owner and a priority. Expect most issues to be missing or mismatched records, unfamiliar steps and exceptions nobody mapped. Watch the first client timesheet approvals, the first pay run and the first invoices closely, because that is where data problems turn into cost.

Signs that the migration needs attention:

Consultants keeping personal spreadsheets alongside the new system.
Reports that differ from the agreed starting figures with no clear reason.
Repeated questions about the same workflow, which point to a training or configuration gap.

Close the hypercare period once the issue log is quiet and the reports reconcile.