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

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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: ______

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.

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.