# The Sourced-Candidate Migration Playbook: Consent, Clocks, and Tombstones

*Run an ATS or CRM migration from freeze to decommission and sign a reconciliation where no opted-out or erased person is re-contactable and no retention clock restarts on import day.*

- Canonical URL: https://www.refolk.ai/guides/sourced-candidate-migration-playbook
- Pillar: Process, data, and compliance
- Format: Playbook
- Published: 2026-10-28
- Last reviewed: 2026-10-28
- Reading time: 22 min
- Keywords: ATS migration candidate consent retention, how to migrate suppression list to new ATS, recruiting CRM migration GDPR checklist, keep retention dates when migrating candidate data, migrate sourced candidates without re-contacting opt-outs, ATS data migration reconciliation report

## Key takeaways

- Sourced candidates never gave application consent, so a migration has to carry six facts per record: origin source, lawful basis, notice-sent evidence, last meaningful interaction date, suppression status, and retention disposition.
- Greenhouse tags every bulk-imported candidate with the date and time of import and its activity feed can't be backfilled, so any purge rule computed from created dates restarts the retention clock on import day.
- The CNIL caps talent pools at two years from last contact, so last_meaningful_interaction_at has to travel in its own custom field or the purge fires late and the evidence is gone.
- Erased and opted-out people should go across as a minimal tombstone (hashed email, date added, reason), because deleting without one removes the only key that can block a stale export from bringing them back.
- Reconcile per entity rather than by one overall total, give every record one of three dispositions (imported, excluded under an approved rule, or unresolved exception), and spot-check 20 to 50 records after cutover.
- In Refolk's index, 67% of UK recruiting-operations titles read Recruitment Operations while US titles favour Recruiting Operations, so a search for migration help that uses only one variant misses most of the other market.

This playbook is for the recruiting ops or revenue ops lead moving sourced, never-applied candidates from one ATS or recruiting CRM to another. Everything in it is aimed at four outcomes: opt-outs stay suppressed, erased people stay gone, retention clocks keep their original start dates, and every record can still say where it came from and when the person was told. It covers the field crosswalk, the order of operations, the failure modes, and a reconciliation you can sign and defend in an audit.

## What has to survive a sourced-candidate migration?

Every sourced record needs to arrive with six facts intact: origin source, lawful basis, notice-sent evidence, last meaningful interaction date, suppression status, and retention disposition. Applicant migrations carry a consent timestamp. Sourced records never had one, so their compliance depends on fields that an import overwrites by default.

Most migration checklists are written for applicants and agencies. They give compliance one line, along the lines of "process erasures, carry consent timestamps". A sourced candidate never applied and never consented to anything. What makes holding the record defensible is three things: where you got the data, the notice you sent, and a retention clock that runs from your last real contact. Everything else in this playbook protects those three.

### The notice obligation behind the fields

Article 14 of the GDPR covers personal data you didn't collect from the person themselves. It sets three deadlines for telling them, and the earliest one applies:

- within a reasonable period after you receive the data, and no later than one month
- at your first communication with the person
- at your first disclosure of their data to another recipient

In recruiting, the one-month limit is almost never the one that bites. You usually message the candidate, or forward their file to a hiring manager, well before a month is up. The notice has to give the source, the retention logic, the objection route, and accessible privacy information before that first message goes out.

One public checklist names the evidence to keep for sourced candidates: the first-contact template that contained the notice link. In practice that means three fields have to survive the move: `notice_sent_at`, `notice_version`, and the channel or template ID. If you lose them, you can no longer show that the notice went out, even though it did.

No regulator has published a mandatory field list for this, so the six facts above are a working standard, not a statutory schema. Before you finalise the crosswalk, check them against your own privacy notice and your DPO's record of processing.

## Which retention rules set the floor and the ceiling?

US rules set a minimum retention period, the floor. The CNIL sets a maximum for talent pools, the ceiling. Your job is to apply both per record, starting each clock from the right event, and an import tool won't do that for you.

| Rule | Period | Clock starts | Status |
|---|---|---|---|
| EEOC 29 CFR 1602.14 | 1 yr, until any charge is resolved | Record date or personnel action, whichever is later | In force |
| OFCCP 41 CFR 60-1.12 | 2 yr (1 yr if small) | Same as EEOC | Unenforced |
| Cal. Gov. Code 12946 | 4 yr | Record created or action taken | Secondary source; verify |
| CNIL talent pool | 2 yr maximum | Last contact | Recommendation |
| CNIL archive | 5 yr | Position filled | Recommendation |

How to read the table:

- **EEOC is the federal floor.** It is one year. If a charge or action is open, it extends to "all personnel records relevant to the charge or action until final disposition".
- **OFCCP's two years is still on the books but not enforced.** Under 41 CFR 60-1.12 the period is not less than two years from the making of the record or the personnel action, whichever is later, and one year for employers below 150 employees or a $150,000 contract. The regulation remains in the CFR while rescission is pending, but OFCCP is not enforcing it.
- **California's four years comes from a secondary source.** It cites Cal. Gov. Code 12946 as amended by SB 807. Have counsel read the statute before you rely on it.
- **The CNIL ceiling runs from last contact, not from record creation.** Talent pools can be kept for two years from the last contact with the candidate, provided they agree or don't object. Evidentiary data can then sit in an intermediate archive for five years. That archive should be consulted only occasionally, with justification, by specifically authorised people.
- **UK agencies have their own rule.** The Conduct Regulations add a one-year record rule.
- **There is no EDPB figure.** No EDPB retention period for talent pools is publicly established. Don't cite one.

> **Note:** OFCCP's two years is not your floor
>
> At least one ranking migration checklist still presents OFCCP's two years as binding. Set timers from the EEOC year plus any charge hold, the state rules counsel confirms, and the CNIL two-year maximum, and re-check OFCCP's status with counsel at each migration.

The disposition for each record comes from two questions: is there an active legal hold, and is the record still inside its retention window? Answer the hold question first, every time.

#### Record disposition before load

Horizontal axis runs from Inside retention window to Past retention limit. Vertical axis runs from No legal hold to Active legal hold.

| Quadrant | What it means |
| --- | --- |
| Held, still in window | Migrate with original clock and a hold flag |
| Held, past limit | Archive under hold; do not purge until disposition |
| No hold, still in window | Migrate with original clock in a custom field |
| No hold, past limit | Delete in source before load and log the rule |

*Answer the legal hold question before the retention timer, and give every opted-out or erased record a tombstone whatever quadrant it lands in.*

## The field crosswalk: where each compliance field lands

The crosswalk is the document that maps each legacy compliance field to a pre-created custom field in the target, with a type and a validation rule. Build it before you configure anything, because the target's own created and modified dates will record the import, not the history.

This is the mechanism behind the most expensive failure in sourced-pool migrations. Greenhouse's historical bulk import lets you set each application's status, map it to an interview stage, add a rejection reason, and include key application dates. But every candidate imported this way also gets a custom tag with the date and time they were added. A migration vendor reports that the activity feed is system-generated: you can add notes, but you can't recreate the full activity history with original timestamps. Greenhouse also doesn't let you backdate interviews, though scorecards can be backdated. For Lever, one vendor guide says to preserve `applied_at` as `createdAt`. That helps applicants and does nothing for sourced records, which have no application.

Whether a candidate-level created date or last-activity date can be written is not publicly established for Greenhouse, Lever, Ashby, or Workday. Test it in your rehearsal import, but don't build on it. The documented workarounds are custom fields, notes, and a "container job" that holds historical records. Custom fields are the only one of these that a purge rule can read.

> An import tool records when you loaded a person, not when you last spoke to them.

| Field | What it proves | How it lies | Target handling |
|---|---|---|---|
| origin_source | Where the data came from (Article 14 source) | Reads "Bulk Import" or an unmatched value | Pre-create every source value before load |
| lawful_basis | Why you hold the record | Defaulted to one value for the whole pool | Picklist, required, no default |
| notice_sent_at + notice_version + template ID | That the notice went out and what it said | Blank, or equal to the import date | Date-time with offset, plus text fields |
| last_meaningful_interaction_at | Start of the CNIL two-year clock | Equal to created_at or the import date | Date-time with offset; drives purge |
| suppression_status | Opt-out or erasure is respected | Clean in the ATS, opted out in the sequencer | Picklist, set from suppression master |

Three Greenhouse specifics belong in the crosswalk itself, not in someone's head:

- **Pre-create sources.** Source values must match an existing source or be created in Greenhouse before you load. Unmatched values get overwritten.
- **Carry a timezone offset on every date.** Greenhouse treats timestamps without an offset as UTC, which can shift a date across midnight and move a purge date by a day.
- **Check your tier.** Greenhouse's bulk candidate import is limited to the Plus and Pro tiers. Confirm the method you're relying on exists on your contract before you plan around it.

**Sourced-record crosswalk header and validation rules**

```
legacy_candidate_id,email_sha256,origin_source,origin_source_detail,lawful_basis,notice_sent_at,notice_version,notice_template_id,last_meaningful_interaction_at,suppression_status,suppression_reason,suppression_added_at,retention_disposition,legal_hold_ref,disposition_rule_id

VALIDATION
origin_source: must exist in target source list before load; reject "Bulk Import" and blanks
lawful_basis: required; picklist only; no default value
notice_sent_at: ISO 8601 with offset (e.g. 2021-03-04T09:15:00+00:00); must not equal import date
notice_version: required where notice_sent_at is present
last_meaningful_interaction_at: ISO 8601 with offset; must not equal import date; must be <= today
suppression_status: one of none / opted_out / erased; set from suppression master, never from source system alone
retention_disposition: one of migrate / archive / delete; delete rows must not appear in load file
legal_hold_ref: required where retention_disposition = archive under hold
```

*Rename the target column names to your target's custom field API names; keep the validation lines as written.*

## Who should run and sign this migration?

Three people own it. A recruiting ops lead runs it, the DPO owns the suppression master, and counsel owns the legal-hold and purge decisions. All three sign the reconciliation. If you're hiring or contracting for the ops role, search on both title variants and treat ATS skill tags with suspicion.

This is a small community. In Refolk's index of professional profiles, 143 people in the US hold recruiting, recruitment, or TA operations titles, against 18 in the UK.

| Country | Total | Top title (count) | Second title (count) |
|---|---|---|---|
| United States | 143 | Recruiting Operations (16 of 25 sampled) | TA Operations (5) |
| United Kingdom | 18 | Recruitment Operations (12 of 18) | Recruiting Operations (3) |
| US:UK ratio (derived) | 7.9x | | |

**67% - of UK recruiting-ops titles in Refolk's index read "Recruitment Operations"**

US titles favour "Recruiting Operations" (16 of 25 sampled), so a search that uses one variant misses most of the other market.

The skill tags are even noisier than the titles. Use them as a weak filter at best:

| Skill (US profiles) | Profiles | Multiple vs Lever (derived) |
|---|---|---|
| Greenhouse | 6,347 | 8.8x |
| Lever | 725 | 1.0x |

The top sampled titles for both skills include CEOs and founders. A Greenhouse tag tells you someone has used the product, not that they've run a migration in it. What does count as evidence is a described migration, an admin role, or a consultancy that names the source and target systems. The employers in the index's sample point to where that experience tends to sit. In the UK they include Anthropic, Jane Street, British Airways, and Justice Digital, Data and Science. In the US they include Plaid, Hudson River Trading, Susquehanna, and honeycomb.io.

Writing a search that covers both title variants, specifies migration experience rather than a skill tag, and is pinned to a city is tedious with boolean strings. With [Refolk](/) you describe the person in plain English instead.

I ran this search: `Recruitment operations managers in London who have run an ATS migration to Greenhouse or Ashby` - [see the full result list](https://www.refolk.ai/s/nzkpmsd80k).

*Returns UK recruitment-ops people whose public profiles describe a migration into those systems, not just a skill tag.*

## The migration procedure, freeze to decommission

The procedure runs in eight stages. The order matters more than the speed: the suppression master and the disposition tags must exist before any data moves, and the old system stays readable until the reconciliation is signed. Greenhouse documents 4 to 6 weeks for historical data migration from a former ATS. That is the only published duration. Every other duration here is a practitioner estimate.

#### Order of operations for a sourced-pool migration

1. **Freeze** - Inventory every store, name an owner, count per entity
2. **Suppress** - Merge opt-outs and erasures into one hashed master
3. **Decide** - Tag each record migrate, archive, or delete
4. **Map** - Crosswalk compliance fields to pre-created custom fields
5. **Load** - Rehearse, full load, screen and load the delta
6. **Reconcile** - Per-entity dispositions, spot check, sign, then decommission

*Suppression and disposition decisions happen before any data moves, and the old system stays readable until reconciliation is signed.*

#### Sourced-candidate migration procedure

1. **Freeze and inventory every candidate store** - List the ATS, CRM, sequencer, enrichment tool, and spreadsheets, and give each a named owner and a record count per entity. Allow about a week; this is a practitioner estimate.
2. **Consolidate suppression and erasure into one master** - Ops and the DPO merge sequencer opt-outs, ATS opt-outs, and the deletion-request log into keys of hashed email, date added, and reason. Done when every opt-out and erasure has a key.
3. **Tag every record migrate, archive, or delete** - Counsel checks the legal-hold list first, then applies EEOC one year plus any charge, California four years (verify), and CNIL two years from last contact. Done when every record has a tag and the rule that set it.
4. **Build the field crosswalk and pre-create targets** - Map origin source, lawful basis, notice fields, last meaningful interaction, and suppression status to custom fields created before load. Done when each has a source column, a type, a validation rule, and pre-created source values.
5. **Configure the target and rehearse the import** - Turn off consent auto-emails and other automated outreach, then import 10 to 20 records that include edge cases. Done when original dates sit in custom fields, sources are intact, suppressed records are flagged, and nothing was sent.
6. **Run the full load, then screen and load the delta** - Load in batches of no more than 8,000 rows in Greenhouse, and screen every inbound email hash against the suppression master before the full load and before each delta. Done when every batch and screen is logged.
7. **Reconcile per entity and sign** - Count source against target per entity, give every record one of three dispositions, spot-check 20 to 50 records, and run a checksum-and-open pass on attachments. Done when ops, the DPO, and counsel have signed.
8. **Run in parallel, then decommission** - Keep the old system under controlled access or in an approved archive until reconciliation, privacy review, and operational validation are complete, with enrichment re-pulls blocked. Done when the old system is retired and archive access is documented.

### Notes on the stages that go wrong most often

**Stage 2: the suppression master.** The ICO says that when someone objects to direct marketing you should put their details on a suppression or "do not contact" list instead of deleting them, keeping just enough information to make sure their preference is respected in future. Its data-minimisation guidance gives a close parallel: an agency keeps only the minimum needed for a basic record of someone it has removed from its search, so they aren't contacted again. Secondary sources describe the usual tombstone as a hashed email or identifier, plus the date added and the reason. A tombstone here means that minimal record: enough to recognise the person, nothing else. The ICO doesn't specify a field list or require hashing, so the hashing choice is yours to document.

**Stage 3: where the sources disagree.** One ranking migration checklist says that if a record is subject to a deletion request, you should delete it in the source, not migrate it, and log the deletion. The ICO approach implies the tombstone itself has to migrate. These two positions can both hold: the profile is deleted and never loaded, and the key travels to the new system's suppression list. The ICO also treats a suppression list as not being used for direct marketing, so nobody has an automatic right to have their entry on it deleted.

> **Rule:** The tombstone always migrates
>
> Delete the erased person's profile in the source and never load it, but carry their hashed key, date added, and reason into the target's suppression list. Without that key, nothing can stop a stale export from bringing them back.

**Stage 6: batches and limits.** The recommended maximum for a Greenhouse bulk import is 8,000 candidates per batch, and the resume zip is capped at 5 GB. Split large pools by entity or by source, not at random. That keeps each batch reconcilable on its own.

## How sourced-pool migrations go wrong

Eight failure modes account for most of the damage. Every one of them can pass a headline count check, so each comes with a specific check that catches it. Run every check on the rehearsal import and again on the full load.

1. **The retention clock resets.** Imported records get a created date equal to the import date, so a two-year purge rule computed from that date keeps people past their limit. *What it looks like:* the pool seems younger than it is. *Check:* for a sample, compare the target's created date with the legacy `last_meaningful_interaction_at`. Any record where the clock field equals the import date is a failure.
2. **Erased people come back.** An export taken before an erasure brings the person back, and with no tombstone nothing matches them. *What it looks like:* a clean load with a person in it whom your deletion log says is gone. *Check:* hash every inbound email and run it against the suppression master before the full load and again on every delta.
3. **Opt-outs stay stranded in the sequencer.** The ATS shows the record as clean while the opt-out lives only in the sequencer. *What it looks like:* suppressed counts in the target that are lower than total unsubscribes. *Check:* count sequencer unsubscribes against suppressed flags in the target and investigate every difference.
4. **The origin source is overwritten.** The source becomes "Bulk Import" or an unmatched value because the sources weren't pre-created. *What it looks like:* the record can no longer answer "where did you get my data?" *Check:* compare the distribution of the source field before and after. Any new value that matches the import label is a failure.
5. **People are re-contacted by accident.** Greenhouse will silently send GDPR and CCPA compliance emails to imported historical candidates unless you turn off the consent rules first. *What it looks like:* opted-out people receiving a consent request from a company they asked to leave them alone. *Check:* confirm the setting is off and confirm zero outbound messages in the import window.
6. **Totals match but records don't.** The overall counts agree while duplicates cancel out deletions. *What it looks like:* a reconciliation that balances and is still wrong. *Check:* reconcile per entity, with a disposition for every record.
7. **Attachments are silently lost.** The file link exists but the file is missing or corrupt. Practitioner sources call this common but publish no rate. *Check:* a checksum plus an open test on every attachment, or at least on a documented sample if your volume makes that impossible.
8. **Purging on the wrong rule.** Teams keep records for two years under OFCCP 60-1.12, which isn't enforced, or purge at one year despite a pending EEOC charge. *What it looks like:* a purge job that is correct by the timer and wrong by the hold list. *Check:* run the legal-hold list first, then the timer.

> **Watch out:** Consent auto-emails fire on import
>
> Turn off the target's consent rules and every automated outreach rule before the rehearsal, not before the full load. Then pull the outbound message log for the import window and confirm it shows zero.

What we don't know: failure rates for duplicates, orphaned records, and lost attachments are not published. The same goes for any accepted field-level error tolerance. A "5 to 10% sample tolerance" circulates, but it has no published basis. Treat any compliance-field mismatch in your sample as a defect to trace, not a rate to accept.

## The reconciliation report that stands up in an audit

An audit-grade reconciliation accounts for every in-scope record individually and carries its compliance fields across. Matching totals don't qualify. Practitioners say to reconcile source and target by entity, not by one overall total, and to end every record in exactly one of three states.

| Disposition | Meaning | Evidence required |
|---|---|---|
| Imported | Record is live in the target | Target ID, compliance fields match legacy values |
| Intentionally excluded | Not loaded under an approved rule | Rule ID, approver, deletion or archive log entry |
| Unresolved exception | Could not be placed | Owner, reason, due date; blocks sign-off |

For every imported sourced record, the report shows the carried-over origin source, lawful basis, notice-sent date, last meaningful interaction date, and suppression status, next to the legacy values. The spot check covers 20 to 50 records after cutover, chosen to include edge cases: erased people's tombstones, sequencer-only opt-outs, records under legal hold, and records with notices on old versions. Attachments get their own checksum pass. Suppression gets its own count: total tombstones in the master equals total suppressed entries in the target, with every difference explained.

**Reconciliation sign-off sheet**

```
MIGRATION RECONCILIATION - SOURCED CANDIDATES
Entity: ______________   Source system: ______________   Target system: ______________
Freeze date: __________   Full load date: __________   Final delta date: __________

COUNTS
In-scope records in source:                 ______
Imported:                                   ______
Intentionally excluded (rule IDs listed):   ______
Unresolved exceptions:                      ______  (must be 0 to sign)
Imported + excluded + exceptions = source:  YES / NO

SUPPRESSION
Keys in suppression master:                 ______
Suppressed entries in target:               ______
Sequencer unsubscribes reconciled:          YES / NO
Inbound hashes screened, full load + every delta: YES / NO
Outbound messages in import window:         ______  (must be 0)

CLOCKS AND ORIGIN
Records where last_meaningful_interaction_at = import date: ______ (must be 0)
Records where notice_sent_at = import date: ______ (must be 0)
Source values equal to import label:        ______ (must be 0)

SPOT CHECK
Records sampled (20 to 50): ______   Compliance-field mismatches: ______
Attachments checksummed and opened: ______   Failures: ______

SIGNED
Recruiting ops: ____________  Date: ______
DPO: ____________  Date: ______
Counsel (holds and purge rules): ____________  Date: ______
```

*One sheet per entity; attach the per-record export and the spot-check log, and do not sign with any unresolved exception open.*

Keep the old system readable until this sheet is signed. The decommission rule from practitioner guidance is plain: don't decommission the old system immediately. Keep controlled access or an approved archive until reconciliation, privacy review, and operational validation are complete. If you need a long-term archive for evidentiary data, the CNIL's model is a guide: occasional consultation, a justification for each access, and a named list of authorised people.

#### Before you call the migration done

- [ ] Every candidate store has a named owner and a per-entity count from the freeze date.
- [ ] Every opt-out and erasure from the ATS, sequencer, and deletion log has a hashed key in one suppression master.
- [ ] Every record carries a migrate, archive, or delete tag and the rule ID that set it, with legal holds applied first.
- [ ] Every source value existed in the target before the first batch was loaded.
- [ ] No imported record has last_meaningful_interaction_at or notice_sent_at equal to the import date.
- [ ] Consent auto-emails and outreach automations were off during every load, and the outbound log for the import window shows zero.
- [ ] Every inbound batch and delta was screened against the suppression master, and each screen is logged.
- [ ] Every in-scope record has exactly one disposition, and unresolved exceptions are at zero.
- [ ] The spot check covered 20 to 50 records, including tombstones and holds, and attachments passed checksum and open tests.
- [ ] Ops, the DPO, and counsel signed the reconciliation before the old system lost read access.

## Keeping the pool clean after cutover

After cutover, the risk moves from the import to everything that feeds the new system: deltas, enrichment re-pulls, and new sourcing. Point the purge job at the carried-over clock field, screen every new inbound record against the suppression master, and re-check the legal rules on a schedule.

- **Purge from the right field.** Configure retention automation to read `last_meaningful_interaction_at`, never the target's created date. Update that field only for interactions that count as meaningful under your policy. A system-generated touch shouldn't restart a two-year clock.
- **Watch the deletion obligations that reach your vendors.** The CPRA's temporary partial exemptions for HR and B2B data have expired. A business that receives a deletion request has to notify its service providers and contractors to delete the person's data, and that includes the sequencer and the enrichment tool as well as the ATS. California's DROP mechanism binds registered data brokers: they must access it at least every 45 days, process verified deletion requests within 45 days, and keep deleting newly collected data. Brokers face a penalty of $200 per request per day. Whether an employer's own sourced pool makes it a data broker is not publicly established. Your direct exposure is through enrichment vendors that are registered brokers.
- **Don't re-pull enrichment during the parallel run.** A re-pull in that window can bring back data that a broker's 45-day cycle, or your own erasure, has already removed. Freeze enrichment until reconciliation is signed, then screen the first post-cutover pull against the suppression master like any other delta.
- **Screen new sourcing at the door.** Anything you add after cutover, including people found through Refolk, should be hashed and checked against the suppression master before it enters the ATS. A plain-English search finds people quickly. The suppression check is what decides whether you're allowed to contact them.
- **Re-check the rules, not just the data.** OFCCP's status, California's period, and regulator priorities all change. One secondary source reports that the CNIL has made recruitment an inspection priority. Before each migration and at each annual retention review, have counsel confirm the current position of each row in the retention table against the primary source: the CFR text, the California statute, and the CNIL's current retention reference and inspection programme.

The next migration will be cheaper if this one leaves its artefacts behind. Keep the crosswalk, the suppression master's schema, the disposition rules, and the signed reconciliation together. They are the evidence an auditor will ask for, and the starting point for whoever runs the next switch.

## Frequently asked questions

### Should candidates who asked to be erased be migrated to the new ATS?

Don't migrate their profiles. Do carry a minimal tombstone across: a hashed email, the date added, and the reason. ICO guidance says to keep just enough information to respect someone's preference rather than deleting them outright. A tombstone is the only thing that lets your new system recognise an erased person when a stale export or an enrichment re-pull brings them back. Check with counsel that your tombstone fields count as the minimum.

### Can I keep original created dates when importing candidates into Greenhouse?

Don't count on it. Greenhouse tags every bulk-imported candidate with the import date and time, and you can't rebuild the activity feed with its original timestamps. Whether a candidate-level created or last-activity date can be written is not publicly established for Greenhouse, Lever, Ashby, or Workday. Carry last_meaningful_interaction_at and notice_sent_at in custom fields you create before loading, and point your purge rules at those fields.

### Do I still have to keep sourced candidate records for two years under OFCCP?

OFCCP's 41 CFR 60-1.12 is still in the Code of Federal Regulations, but it is not being enforced and the Department of Labor has proposed rescinding it. Some ranking migration checklists still treat it as binding. The working floor is EEOC's one year, extended until any charge reaches final disposition, plus state rules such as California's four years (a secondary source, so verify it against the statute). Ask counsel to confirm the current status before you set timers.

### How large should the post-migration spot check be?

Published practitioner guidance says to rehearse with 10 to 20 representative candidates and to spot-check 20 to 50 records after cutover. No published field-level error tolerance exists, so treat any compliance-field mismatch in the sample as a failure to investigate, not a rate to accept. Spot checks come on top of the per-entity reconciliation and don't replace it. Every record still needs a disposition.

### Our opt-outs live in the sequencer, not the ATS. Does that matter in a migration?

Yes, and it's one of the most common ways sourced-pool migrations fail. If you migrate only from the ATS, the new system shows the record as clean while the opt-out stays behind in the sequencer. Merge sequencer unsubscribes, ATS opt-outs, and the deletion log into one suppression master before loading. Then reconcile the count of sequencer unsubscribes against suppressed flags in the target and investigate every difference.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/sourced-candidate-migration-playbook*