Recruit CRM Data Migration: Validate the Import Before Cutover

The import finishes. The row count looks plausible. Then a recruiter opens a candidate and finds a placement history under the wrong record, an owner assigned to the person who ran the upload, or a custom field that quietly became free text. That is not a cleanup task. It means the migration was accepted before anyone proved what landed.

This is a validation plan for an agency moving data into Recruit CRM or reloading a large slice of its database. It does not describe a completed customer migration. Use it to decide what must be true before cutover, then test those conditions with your own records and policies.

Start with a recoverable source, not the import file

Save an export that people can inspect after the migration. Recruit CRM says its paid-plan account owners can request data and full exports, with different content and cadence. Those exports include CSVs for core entities and associations. They are a source snapshot, not proof that a restore will work. Check the account's plan, permissions, and current limits before scheduling the work. Recruit CRM's export guidance was checked November 2, 2026.

For an inbound migration, the legacy ATS or CRM supplies the source snapshot. It should have a date, timezone, row counts by entity, and a stable identifier where one exists. If this is a Recruit CRM reload, take a Recruit CRM destination snapshot before the pilot so the team can compare pilot writes; it is not a substitute for the legacy-system source. Keep unmodified exports somewhere access-controlled. The worksheet used to normalize columns is useful too, but it is not the record of what the old system contained.

If the old system cannot produce a usable export, pause. Manual re-entry may be safer for a small, active set of records than pretending an incomplete file is a migration.

Decide what each column is allowed to become

Build a field map before anyone uploads a file. Write down the source column, intended Recruit CRM entity and field, expected format, sample value, owner of the definition, and how the result will be checked. Include columns you plan to drop. A dropped field may be a deliberate decision. An unmapped field discovered after cutover is usually an argument. The CRM field-mapping workbook is a starting structure, not proof that the mapping fits this account.

Recruit CRM documents that custom fields are configured per entity. It also says field limits differ by plan and that deleting a custom field permanently removes the data stored in it. Confirm the subscription, permissions, and existing field inventory before creating new fields for an import. Its custom-field documentation is the current source.

Do not map values because their labels look alike. For example, an old-system "owner" might mean the recruiter who sourced a candidate, the account manager, or the user who should receive Recruit CRM notifications. Those are three different decisions.

Make importer behavior a cutover decision

Duplicates are where a technically successful import becomes a reporting problem. Do not collapse the new-UI bulk importer into manual merging. Recruit CRM's bulk-import guide describes selecting a matching identifier and choosing whether Override Data may replace populated fields; it also documents cases where company imports can merge a matching company despite a Do Not Merge choice. Record the selected key, override setting, and each populated before/after field in the pilot. Recruit CRM's bulk-import guide was checked November 2, 2026.

For a manual merge of two existing records, Recruit CRM says the chosen primary is retained, only empty primary fields are filled from the secondary, and the secondary is permanently deleted. Its manual-merge guide covers that separate behavior. Do not use a production merge as a casual undo button for a poor import. Decide first which record will remain primary and whether the incoming value is allowed to populate an empty field.

Run a pilot that can fail safely

Choose a small, varied pilot. Include a candidate matched by the selected import key, a record with a populated destination field, a custom field, an inactive record, and a job meant to attach to an existing company. Redact any exported sample used outside the operating team. Before retrying a pilot, decide whether to reset or isolate its writes, then reconcile the pilot records. Do not assume a second upload is a clean test.

Use an acceptance sheet like this one. The rows are synthetic examples, not a tested Recruit CRM import.

Recruit CRM's job-import guidance says a name match can link a job to an existing company and a nonmatch can create one. Inspect the association itself, not only the row count. Its job-import documentation was checked November 2, 2026. The correct response to a failed pilot is not a wider upload with a longer exception list. Fix the mapping, importer configuration, data preparation, or acceptance rule. Then rerun the pilot.

Reconcile by entity and by the records people actually use

After a successful pilot, reconcile counts separately for candidates, contacts, companies, jobs, and any other scoped entity. Counts alone are weak evidence. Pair them with a sampled review of records that drive real work: an active candidate, a live job, a company with several contacts, a placement-related record, and a record with a nonstandard custom field.

For each sample, compare the values that matter to the decision it supports. A stage report needs the right stage and history boundary. A recruiter needs the right owner and contact path. Finance may need a placement reference preserved for later reconciliation. Do not claim history was migrated merely because the current status appears on the destination record.

Recruit CRM's list and report exports let permitted users choose fields and download records. A selected-list export proves only the selected fields, so use it alongside targeted record checks when the acceptance question concerns associations or history. Its export documentation describes the permissions and entity-level export process.

Choose a cutover boundary that people can operate

Name the last old-system update that belongs in the migration. Decide who records changes after that moment, when the old system becomes read-only for ordinary users, who handles exceptions, and what condition permits rollback or a delayed cutover. If the agency must keep both systems active for a time, declare which system owns each field during that interval. Two editable copies of a candidate profile are not a migration plan.

If your question is whether Recruit CRM's native reporting answers a historical or cross-system question after the move, read the Recruit CRM reporting guide. Use the migration go/no-go worksheet to record the decision and exceptions. For a data model, import controls, or integration that needs defined ownership and acceptance evidence, Recruit CRM consulting can help scope the work. Bring a redacted source export, the field map, and the one report the migration must preserve.