Migrate your CATS data

Candidates are the core object in CATS. Every candidate record includes contact details, status, source, and custom fields. We export candidates via CATS' built-in XLS/CSV export or direct API pull, map all standard fields 1:1, and preserve custom field data. Attachments are pulled separately and re-associated after primary record import.

Job Orders in CATS represent open positions with internal IDs, status, department, and pipeline stage. We map Job Orders to the destination ATS's equivalent job or requisition object. CATS' pipeline stages may not map directly to another platform's stage names — we discuss stage mapping during scoping.

Activities (calls, emails, notes, interviews) are linked to candidates and job orders. CATS stores them with timestamps, owners, and type flags. We preserve activity history and owner attribution, but the activity schema varies — calendar-based activities may need re-formatting to match the destination's event model.

CATS supports custom fields on Candidates and Job Orders. Custom field types include text, dropdown, date, and checkbox. We export the full custom field schema and data values, then re-create the custom field definitions in the destination system before importing records. Dropdown values require explicit mapping when the destination uses a different picklist.

CATS workflows govern record state transitions and automated actions. Workflows are configuration-level objects, not data objects, and cannot be exported directly. During migration scoping, we identify which workflow rules are business-critical and document them for manual reconfiguration in the destination or recommend a post-migration automation pass to replicate them.

CATS user accounts include name, email, role, and department. We export the user list and map each to the corresponding user in the destination system. If the destination has fewer seats than CATS, we flag which inactive users should be deprovisioned after migration.

CATS uses a configurable pipeline with stages like 'New', 'Screening', 'Interview', 'Offer', 'Hired', 'Rejected'. Pipeline stage IDs and names vary by CATS instance. We extract the current pipeline configuration, map it to the destination's stage model, and flag any stages that have no equivalent in the target system.

CATS allows tagging candidates and job orders with free-text or pre-defined tags. Tags are exported as a comma-separated list and mapped to the destination's tag or label field. If the destination uses a structured taxonomy, we create matching categories and reassign tags accordingly.

Candidate sources (e.g., 'LinkedIn', 'Referral', 'Job Board') are stored as a field in CATS. We preserve source attribution during migration. If the destination uses a different source taxonomy, we map values to the closest equivalent or create new source entries.

CATS stores resumes, cover letters, and other file attachments linked to candidates. We pull attachments via the API or export tool, preserve file names and association metadata, and re-upload them to the destination. Large volumes of attachments may require a chunked upload approach to avoid timeout.

Departments in CATS are used to categorize job orders and sometimes users. We export the department list and recreate it in the destination system before importing job orders that reference departments.

CATS generates reporting data (time-to-fill, source effectiveness, pipeline metrics) that is derived from transactional records, not a standalone data object. We do not migrate reporting snapshots because they are not independently meaningful in the destination system. Post-migration reporting will populate naturally as new data is recorded.