ATS migration guide: Keep candidate context intact.

Start with the candidate work that must continue on the first day in the new ATS. List open vacancies, active applications, upcoming interviews and unresolved messages. Give each vacancy a recruitment owner. Decide whether its existing candidates will move together, stay temporarily in the old system or follow an explicitly agreed split. Write the decision before requesting an export.

Historical records need their own scope. A completed application may have no immediate hiring action, while its retention, access and permitted future use still need review. Ask your responsible internal reviewers which records can move, which must remain restricted and which should be excluded. Record any consent evidence, its source and date, and any withdrawal, deletion request or processing restriction that affects the proposed transfer. Have your responsible reviewer decide the permitted handling before import; do not infer consent from a populated email field. This guide proposes a migration method and does not set legal retention periods.

Workable describes migration from a prior ATS as an agreed process involving data collection, a statement of work, stage mapping and, where applicable, sample verification before the full move. Its guidance also asks customers to coordinate the end of activity in the old ATS. Confirm the equivalent scope and dependencies with your selected supplier rather than assuming every product moves the same information.^[1]

Build an inventory in your existing project tool. For each source, record its owner, export date, record types, expected totals and access restrictions. Count people, applications, jobs and attachments separately. One person can have several applications, and an application can have several files. A single total labelled candidates can hide whether those relationships survived the move.

List information that does not fit a basic profile: recruiter notes, messages, interview feedback, stage history, source attribution and scheduled activity. Ask the supplier what transfers, in which form, and what must stay in an approved archive. A summary field is not automatically an equivalent replacement for a dated conversation or a history of decisions. Let the recruitment owner decide what users need to continue the work.

Capture the limitations alongside the inventory. An export may omit attachments, private fields or records visible only to a particular role. Obtain an approved sample through the agreed secure transfer route before estimating the rest of the migration. Avoid placing candidate files or access credentials in a general project discussion. Name the person who can resolve an incomplete extract and the decision that depends on it.

For every field in scope, record the source name, its meaning, the destination, any transformation, an example value and its reviewer. Mark unsupported fields explicitly. Keep an excluded field separate from one that is temporarily unresolved. The map should tell the importer what to do and tell a recruiter how to recognise a wrong result.

Preserve a stable source identifier through the agreed migration process wherever the destination supports it. Record how a person connects to each application and how each application connects to its vacancy. Confirm how dates, time zones, blank values and closed jobs are handled. A missing date should remain distinguishable from a default date inserted by an import process.

For example, a source field called owner might name the recruiter responsible for an application, while the destination field might identify the hiring manager for the whole vacancy. Mapping those labels directly would change responsibility. Describe the required meaning as the recruiter who owns the next candidate action, then agree the appropriate destination and check it using a representative record.

Ask the recruitment lead to approve a stage map for each hiring workflow. Record the source stage, destination stage, next action and responsible person. If two source stages become one destination stage, explain how users will still identify the next action. If a stage has no safe equivalent, leave its records in an exception group until its owner decides how to proceed.

Keep application status separate from interview feedback. An archived, withdrawn or rejected application needs the agreed status and access treatment. Moving its profile does not make it an active prospect. Preserve the distinction between one person applying to two vacancies and two duplicate copies of the same person. Avoid using an email address alone as proof that every application should collapse into one record.

Greenhouse's bulk-import documentation distinguishes active candidate imports from historical application imports. It also describes mapping jobs and fields and handling resume attachment failures. These product-specific differences illustrate why a completed upload is insufficient evidence of a complete migration. Ask your chosen supplier to demonstrate the operations included in your own scope.^[2]

Create an attachment inventory that ties each required file to its source record, application and intended destination. Record file type, filename, expected association and review status. Where your migration team uses checksums, agree what an exact match means and how a supplier transformation will be reviewed. Count files that failed, were excluded or need manual investigation separately from successful transfers.

Open a representative set through the destination interface using the intended role. Check that the correct file is attached to the correct application, that it opens, and that a user outside the approved scope cannot retrieve it. Check sensitive documents separately from ordinary recruitment attachments. Seeing a filename or a successful upload message does not establish readable content or appropriate access.

Greenhouse documents that candidate attachment visibility depends on user permissions and, for some documents, attachment settings. That is evidence about Greenhouse's model, not a promise about every ATS. Make the destination's actual access rules part of your review with IT and the hiring owner. Record who approves any difference from the source permissions before production access is enabled.^[3]

Use an authorised test setup and synthetic records to rehearse the mapping first. Include a person with two applications, an application with a missing owner, a changed interview time, a restricted attachment and a deliberately unresolved stage. Ask the supplier how to prevent messages and other automated actions during rehearsal. Do not use real candidates as test recipients.

After the synthetic checks, the data owner can approve any representative real-data sample required by the agreed process. Document its purpose, access, transfer route and disposal. Compare the source and destination for the same records. Ask a recruiter to find the next action without relying on the migration lead to explain an undocumented workaround.

Maintain an exception record with source identifier, failed check, effect on recruitment, owner, resolution and retest evidence. A sample that contains no difficult records cannot demonstrate how those records will migrate. Choose cases for the variety of relationships and permissions in scope; this guide does not prescribe a universal sample size or an acceptable error threshold.

Consider a hypothetical 180-person employer moving two open vacancies. The approved source scope contains 120 distinct people, 150 applications and 180 attachments. Thirty people have one application to each vacancy. The remaining ninety have one application each. These invented numbers demonstrate reconciliation and are not CapoFine customer results or a recommended batch size.

The first trial produces 120 people, 147 applications and 178 readable, correctly associated attachments. The application coverage is 147 divided by 150, or 98%. Attachment coverage is 178 divided by 180, approximately 98.9%. The people count matches, but three applications and two attachments remain unresolved. Keep the measures separate because matching people does not prove their job context or files are complete.

Suppose two missing applications refer to an unmapped job and the third uses a stage the team has not approved. One attachment is associated with the wrong application and one cannot be opened. The recruitment lead approves the missing mapping; the data owner corrects the file issues through the agreed process. A new import alone does not close the findings. Recheck the affected records and confirm that the correction has not duplicated successful applications.

The team requires every in-scope active application to have an approved destination or an explicitly approved exception before cutover. After corrections, its record shows 150 reconciled applications and 180 verified attachments. This threshold belongs to the hypothetical team's decision. A real team must also check content, permissions and ongoing work; coverage percentages alone do not authorise launch.

Set an explicit cutover time with the recruitment and supplier owners. Define when the source stops accepting changes, how new applications are handled and where recruiters record urgent work. Tell users which system owns each vacancy. If the process allows activity during the transfer, agree how those changes will be captured and reconciled before the destination becomes authoritative.

Record the final source snapshot, mapping version and transfer scope. Compare final totals by record type and review the unresolved exceptions with their owners. Recheck upcoming interviews and candidate messages against the agreed operating plan. The person responsible for a live candidate should know where to find the next action throughout the move, including when a transfer is delayed.

Before enabling communication or reminders, confirm which imported records can trigger an action. Ask the supplier about scheduled sends, calendar events and integration behaviour. Use an approved preview or test route where available. Establish who can stop an unintended action and who will handle candidate contact if it occurs. A historical import should not silently become a new outreach campaign.

Define what happens if an important reconciliation or access check fails. The recruitment lead may defer cutover for the affected vacancy while the supplier investigates. An approved temporary process needs an owner and an end condition. Confirm how to correct or remove an unsuccessful import without losing new activity already created in the destination. Never assume that restoring an entire database is available or appropriate.

Keep the source access needed for the approved verification period under your organisation's access and retention rules. Give support staff a clear issue route and a way to locate the affected record without copying personal information into an unrestricted ticket. Review the first live hiring handoffs after cutover, including changed interview details and missing feedback, against the original acceptance record.

Retire the old system only after the responsible owners approve reconciliation, access, retention and retrieval arrangements. Record the supplier notice requirements and any export access that ends with the contract. Confirm removal of temporary extracts and credentials through the appropriate owners. A paid subscription ending does not by itself demonstrate that every retained copy has been handled correctly.

CapoFine Hire supports configurable hiring stages, candidate ownership, candidate communication, interview scheduling and structured feedback after interviews. Hire keeps hiring decisions with people. Its scorecards organise post-interview feedback and are not candidate tests. Use this workflow context to decide which active records your team needs to continue recruitment.

Bring a sanitised inventory, your field and stage maps, unresolved exceptions and the required cutover window. Ask which transfer methods, historical fields, attachment handling and implementation services are included in the proposed package and agreement. Confirm the exact transfer method, supported fields, duplicate handling and expected delivery date in writing.

Use the ATS implementation guide for the broader configuration and adoption plan. Review Hire plans for package boundaries, then arrange a discussion around the first vacancy that must move. Assign the open migration questions to a named owner and ask for a scoped demonstration before setting the final cutover date.