Switching Background-Screening Providers: Transition and Cutover Playbook
Changing background-screening providers is usually a workflow transition — not a migration of the outgoing provider’s entire database.
In the most common model, the outgoing provider finishes cases already in progress, while the incoming provider receives new screening requests from an agreed cutover date. Completed reports remain in the employer’s authorised HR records, applicant-tracking system (ATS), human resources information system (HRIS), secure archive or the outgoing provider’s platform for an agreed access period.
Candidate documents, historical reports and partially completed verification work are not routinely imported into the new provider’s platform. Limited information may occasionally need to move, but this should be treated as an exception supported by a defined purpose rather than the default meaning of a provider switch.
Executive Summary
The safest background-screening provider transition is usually a prospective cutover with a controlled run-off period. New orders move to the incoming provider from an agreed date, while the outgoing provider remains responsible for the legacy cases it has already started.
Historical screening data does not normally need to be imported into the new provider’s production platform. Employers should instead preserve only the records they genuinely need, maintain clear case ownership, test integrations before go-live, reconcile open cases and close the outgoing service through a documented retention, return or deletion process.
The key governance principle is simple: move the screening workflow, not the entire legacy database.
For broader programme design, see eeCheck’s Background Screening Vendor Questions in Asia, In-House vs Outsourced Screening in Asia, Background Check SLA Template for Asia and Asia Background Check Compliance Guide.
The Short Answer: Does Screening Data Normally Move to the New Provider?
Usually, no.
The incoming provider generally does not need an employer’s old screening reports in order to conduct future checks. It needs the configuration required to process new orders: screening packages, country rules, service levels, user roles, billing details, candidate communications, integrations and escalation arrangements.
| Item | Usual Approach |
|---|---|
| New screening requests | Sent to the incoming provider from the cutover date. |
| Open cases | Completed by the outgoing provider wherever practicable. |
| Completed reports | Kept in the employer’s authorised record system or accessed through a time-limited legacy arrangement. |
| Candidate documents | Not transferred routinely. |
| Partially completed verification work | Usually not adopted by the incoming provider. |
| Screening policy and service configuration | Recreated and validated with the incoming provider. |
| ATS / HRIS integration | Reconfigured, tested and activated for new orders. |
| Essential case-status list | Shared only where needed to manage the transition. |
| Outgoing provider’s copies | Retained, returned or deleted according to contract, applicable requirements and documented instructions. |
This separation is important. Switching providers does not mean the incoming provider should become the archive for work performed by another screening company.
Why Full Historical Migration Is Uncommon
1. The Employer May Already Hold the Records It Needs
Many employers already retain final reports or decision-relevant records in their ATS, HRIS, document-management environment or other controlled system. If the required historical evidence is available there, copying it into another screening platform adds little operational value.
2. Background-Screening Information Is Sensitive
Reports may contain identity information, employment and education histories, criminal or litigation information, credit information, professional records, addresses and supporting documents. Moving an entire historical dataset creates another transfer, another storage location and another group of people or systems requiring access.
3. The New Provider Did Not Perform the Old Checks
An incoming provider generally cannot validate or assume responsibility for another provider’s verification methods, source communications, conclusions or report wording. Importing a legacy report must never make it appear that the incoming provider performed the work.
4. Partially Completed Checks Are Difficult to Transfer Safely
The incoming provider may use different consent wording, source channels, search methods, report standards or subcontractors. It may be unable to rely on the outgoing provider’s candidate documents, authorisations or incomplete source responses.
5. Data Minimisation Favours a Narrower Approach
A defensible transition begins by asking what information is genuinely required for continuing operations or legal obligations. It does not begin with a request to copy everything simply because the technology permits it.
For related compliance considerations, see eeCheck’s Compliant Background Screening Policy in Asia and Background Screening Policy Template for Asia-Pacific.
The Recommended Transition Model
For most employers, the cleanest approach is a prospective cutover with a controlled run-off period:
- Configure and test the incoming provider.
- Select a date and time after which all new orders go to that provider.
- Stop creating new orders with the outgoing provider.
- Allow the outgoing provider to complete cases already underway.
- Maintain appropriate access to legacy reports and open cases during the run-off period.
- Reconcile unresolved cases, corrections, invoices and records.
- Export only employer-required records that are not already held elsewhere.
- Close access and obtain appropriate return or deletion confirmation.
For a limited period, the employer may use two platforms — but for different populations. The outgoing platform owns the defined group of legacy cases; the incoming platform owns new cases created after cutover. This is not an uncontrolled dual run.
What Might Legitimately Be Transferred?
| Potential Transfer | Why It May Be Needed |
|---|---|
| Open-case register | To monitor the run-off and assign ownership. |
| Employer or business-unit codes | To configure the incoming service. |
| Screening package definitions and country rules | To recreate the approved screening programme. |
| Authorised user and role information | To establish appropriate access. |
| Billing references / purchase-order details | To maintain commercial continuity. |
| Cases under correction, dispute or legal hold | To preserve accountability and required follow-up. |
| Selected employer-owned reports | Where required records are not available elsewhere. |
| Limited cutover metadata | To reconcile cases close to the transition boundary. |
Before candidate-level information is transferred, document why it is needed, which exact fields or files are required, who will access it, where it will be stored, how it will be protected, whether the processing is supported by relevant notices or contractual terms, how provenance will be preserved and when temporary copies will be deleted.
Seven-Phase Provider-Switch Playbook
Phase 1: Define the Transition Scope and Owners
Appoint one accountable transition lead. The working group will commonly include HR or talent acquisition, screening operations, procurement, privacy or legal, information security, HR technology and major hiring markets.
Confirm the countries, employing entities, screening packages, check types, expected volumes, ATS/HRIS/API/SSO dependencies, target cutover date, proposed run-off period, candidate communications, go-live decision rights and the outgoing provider’s contractual exit obligations.
Phase 1 Exit Criteria
- Transition owner and decision-makers appointed.
- Countries, services and integrations confirmed.
- Contractual notice and exit requirements reviewed.
- Target cutover and run-off approach agreed in principle.
- Risks, dependencies and unresolved decisions recorded.
Phase 2: Inventory Open Cases and Required Records
The most important operational exercise is not a historical data inventory. It is an accurate open-case inventory.
| Open-Case Category | Transition Consideration |
|---|---|
| Invitation issued but not accepted | Decide whether to leave with the outgoing provider or cancel and reissue. |
| Awaiting candidate information | Confirm ownership and candidate communication. |
| Screening in progress | Usually remain with the outgoing provider. |
| Awaiting employer / institution / authority | Usually remain with the outgoing provider. |
| Partially completed | Prefer one provider to finish the package where practicable. |
| Under correction, dispute or review | Keep responsibility with the provider that performed the original work. |
| Legal or regulatory hold | Preserve required records and access. |
Phase 2 Exit Criteria
- Open cases reconciled with the outgoing provider.
- Every open case assigned a treatment and owner.
- Location of required historical records confirmed.
- Disputes, corrections and legal holds identified.
- Final export needs narrowed to what is genuinely necessary.
Phase 3: Configure the Incoming Service
Build the new service from the employer’s approved screening policy rather than copying the old platform mechanically. Configuration should cover packages by role and country, candidate communications, consent workflows, required documents, report formats, status terminology, discrepancy categories, service levels, escalation paths, user permissions, billing codes, retention settings, management reporting and integrations.
Map business meanings, not merely labels. “Completed,” “verified,” “clear,” “consider” and “discrepancy” may not mean the same thing across providers.
Phase 4: Pilot New Cases
The pilot should use new screening cases rather than a bulk import of historical reports. Test the complete journey from recruiter order through candidate communication, document submission, provider processing, status updates, report access, discrepancy handling, management information and invoicing.
| Pilot Acceptance Criterion | Expected Outcome |
|---|---|
| Candidate-to-report identity | No mismatch. |
| Privacy and security | No unresolved critical defect. |
| Go-live readiness | No unresolved critical defect at go-live. |
| Priority workflows | Successful end-to-end processing. |
| Packages and country rules | Correctly configured. |
| Role-based access | Verified before go-live. |
| Status and report delivery | Accurate and timely. |
| Escalation routes | Tested and operational. |
Phase 5: Prepare the Cutover and Run-Off
Cases ordered before the cutover time remain with the outgoing provider; cases ordered from the cutover time onward go to the incoming provider, unless a documented exception is approved.
Seven to fourteen days before cutover, reconfirm the open-case register, finalise users and permissions, complete recruiter training, communicate the new ordering route, test production integrations, confirm escalation contacts and agree go/no-go and rollback criteria.
Phase 6: Cut Over New Orders
At the agreed time, stop new orders entering the outgoing workflow, activate the incoming provider in the ATS/HRIS or ordering process, place and verify a production order, confirm invitations and status callbacks, record the go-live decision and begin daily transition monitoring.
During the first days, monitor:
- orders sent to the wrong provider;
- duplicate orders;
- failed invitations or integration messages;
- incorrect packages or country rules;
- access problems;
- candidate questions and complaints;
- delayed legacy cases; and
- cases created close to the cutover boundary.
Phase 7: Close the Outgoing Service
Do not close the old platform immediately after go-live. First complete a final reconciliation covering legacy cases, corrections, delayed source responses, reports, invoices, user access, integrations, temporary exports and the agreed return, retention or deletion process.
A post-implementation review after approximately 30 days should compare actual turnaround, service failures, candidate enquiries, recruiter workload, escalation volume and billing against expectations.
How to Handle Open Cases
| Case Position at Cutover | Generally Preferred Treatment |
|---|---|
| Invitation not accepted | Consider cancelling and reissuing through the incoming provider if communications and permissions allow. |
| Candidate submitted information; checks not started | Assess whether restart is practical and whether fresh action or notice is required. |
| Checks already in progress | Usually allow the outgoing provider to complete them. |
| Awaiting source response | Usually allow the outgoing provider to complete them. |
| Partially completed package | Prefer completion by the outgoing provider to preserve one accountable report. |
| Completed but under correction or dispute | Keep with the provider that produced the report until resolved. |
| Long-stalled case | Decide explicitly whether to continue, cancel or restart. |
Historical Reports: Four Practical Options
| Option | Approach |
|---|---|
| 1. Keep reports in the employer’s system of record | Often the simplest model where required reports already sit in an authorised ATS, HRIS or archive. |
| 2. Maintain time-limited read-only legacy access | Useful while open cases finish and records are reconciled. |
| 3. Export a limited employer-required archive | Appropriate where required reports exist only in the outgoing platform. |
| 4. Selectively provide a legacy record to the new provider | Use only where the new provider genuinely needs the record for a defined service purpose and provenance is preserved. |
A bulk import into the new provider should be exceptional and supported by a clear business or legal requirement, due diligence, field mapping, secure transfer, reconciliation and deletion of staging files.
Go / No-Go and Rollback Criteria
- candidate-to-report mismatch;
- unauthorised access;
- incorrect screening packages or country rules;
- failure of order creation, invitations or status callbacks;
- an inability to identify which provider owns a case;
- mandatory candidate communications not being issued; or
- inadequate operational coverage for the cutover.
The rollback plan should state whether new orders temporarily return to the outgoing provider, use an approved manual procedure or pause. It must also address cases already created in the incoming system so candidates are not screened twice unintentionally.
Transition Checklist
| Control | Evidence |
|---|---|
| Transition owner and decision rights confirmed | Project charter or RACI |
| Contractual notice and exit provisions reviewed | Contract review record |
| Open-case register reconciled | Case-level register |
| Every open case assigned to one provider | Approved treatment column |
| Historical record location confirmed | Records inventory |
| Unnecessary historical migration ruled out | Documented transition decision |
| Incoming packages and country rules approved | Configuration record |
| Candidate forms and communications reviewed | Approved templates |
| Users and permissions validated | Access review |
| ATS / HRIS / API testing completed | Test evidence |
| New-case pilot accepted | Pilot results and defect log |
| Recruiters and administrators trained | Attendance or communication record |
| Go / no-go criteria passed | Time-stamped approval |
| Legacy cases and records reconciled | Final reconciliation |
| Outgoing access and integrations closed | Decommission record |
| Return, retention or deletion process confirmed | Provider confirmation |
| Post-implementation review completed | Review report |
Questions to Ask the Incoming Provider
- How will you configure our screening packages by country, role and entity?
- How do your statuses and result categories differ from those of our outgoing provider?
- What candidate notices, authorisations or actions are required for new cases?
- Can you accept an open case from another provider? If so, what can you legitimately rely on and what must be restarted?
- How will you prevent duplicate orders during cutover?
- How will ATS, HRIS, API, single sign-on and notification workflows be tested?
- What support and escalation coverage will be available during go-live?
- If a specific legacy record must be provided, how will its provenance and access be protected?
- How will temporary transition files be deleted?
- How can employer-owned records be returned or exported at the end of the relationship?
Questions to Ask the Outgoing Provider
- Can you produce an accurate open-case report by status and outstanding action?
- Which cases can reasonably be completed before or during the run-off period?
- How will delayed source responses, corrections and disputes be handled after cutover?
- How long can restricted legacy access remain available?
- What standard report export is available if the employer lacks required copies?
- What transition assistance is included in the contract?
- Which information must the provider retain, for what reason and for how long?
- How will production data, temporary exports, subprocessors and backup copies be addressed at closure?
- Will the provider supply an appropriate return or deletion confirmation?
How eeCheck Supports a Provider Transition
eeCheck can work with an employer’s HR, procurement, privacy, security and technology teams to establish the incoming operating model for new screening orders.
| Transition Area | eeCheck Support |
|---|---|
| Package and country configuration | Build role- and jurisdiction-specific screening settings for the incoming programme. |
| Candidate workflow setup | Configure candidate-facing communications, documentation and process requirements. |
| User and permission design | Establish role-based access for authorised users. |
| ATS / HRIS / API integration | Support testing of order, status and report workflows. |
| New-case pilot | Validate end-to-end processing before full go-live. |
| Cutover planning | Define routing, timing, support coverage and transition controls. |
| Open-case reconciliation support | Help maintain clear ownership between legacy and new cases. |
| Training | Support recruiter and administrator readiness. |
| Post-go-live monitoring | Enhanced monitoring during the initial transition period. |
eeCheck would not normally require an employer’s complete historical screening database in order to become its new provider. Where limited legacy information is genuinely required, the scope and handling method should be agreed only after considering purpose, provenance, access, technical feasibility, contractual rights and relevant privacy requirements.
Related reading: ATS Background Check Integration Workbook, Background Check SLA Template for Asia, Top Background Check Firm in Asia, MNC Background Screening in Asia and Asia Background Check Guide.
Frequently Asked Questions
Must historical background-check reports be imported into the new provider’s platform?
No. This is generally unnecessary. Reports can remain in the employer’s authorised records or, for a limited period, in the outgoing provider’s legacy environment. Transfer should occur only where a defined need exists.
Who should complete checks that are already in progress?
The outgoing provider will usually complete them. This preserves continuity, source communications, report provenance and accountability.
Can the incoming provider rely on checks already performed by the outgoing provider?
Not necessarily. Verification methods, candidate authorisations, sources, standards and report structures may differ. The incoming provider should not present another provider’s work as its own.
Is temporary use of two providers acceptable?
It can be operationally appropriate when the populations are clearly separated: legacy cases remain with the incumbent and new cases go to the incoming provider. Each case should have one accountable provider.
How long should the run-off period last?
There is no universal period. It should reflect the age and complexity of open cases, expected source response times, correction rights, contract terms and access needs.
What if the employer does not hold copies of old reports?
Identify which reports must remain available and obtain an appropriate standard export or archive arrangement before closing the outgoing account. This does not mean those reports must be loaded into the incoming provider’s platform.
When should the outgoing provider delete its copies?
Return, retention and deletion should follow the contract, applicable requirements, documented instructions and any legitimate preservation need.
What is the greatest cutover risk?
Unclear case ownership. If recruiters, candidates or providers cannot tell which company is responsible for a case, the result may be duplicated checks, abandoned cases, missed communications or inconsistent reports.
Final Strategic Takeaway
The safest provider switch is usually simpler than a large-scale data migration.
Configure and test the incoming provider for new orders. Establish one clear cutover point. Let the outgoing provider finish the cases it has already begun. Preserve only the historical records the employer genuinely needs, in an authorised location, and close the legacy environment through a documented reconciliation and retention process.
The governing principle is straightforward: move the screening workflow, not the entire legacy database.
This guide provides operational information and does not constitute legal advice. Requirements differ by jurisdiction, sector, check type, contract and organisational policy. Employers should involve privacy, legal, information-security and procurement teams where appropriate.
