Migrate from ApplicantStack to Crelate

ApplicantStack Positions map to Crelate Job Order records. Job metadata — title, description, status, and opening count — transfers as structured field data. ApplicantStack's job board distribution settings (Indeed, JobTarget, custom branded boards) are configuration-only data that do not carry forward; the job posting content migrates but the distribution connections must be re-established in Crelate's job distribution settings by the customer's admin. We flag any active job distribution configurations during discovery so they are not silently dropped.

Candidate records from ApplicantStack map to Crelate Contacts with the Recruit subtype. We extract name, email, phone, application date, resume, status, source, and notes as structured fields. The ApplicantStack duplicate detection gap is a known risk for this migration: we run deduplication against the destination Crelate org using email address, phone number, and normalized name strings, and flag likely duplicates for customer review before final import so that ApplicantStack's duplicate record accumulation does not carry forward into Crelate.

ApplicantStack Questionnaires (custom application forms) store responses as field-value pairs tied to the candidate record. We extract all custom field responses and map them to Crelate's custom field equivalents on the Contact record, creating the destination custom fields during the schema setup phase. Crelate's field mapping feature allows these form responses to write directly to Contact, Company, or Opportunity columns — we configure these mappings before migration so questionnaire data surfaces correctly in the candidate record. Any questionnaire logic (knockout questions, conditional branching) is documented separately as a configuration rebuild item for the customer's admin.

ApplicantStack user role assignments (Administrator, Recruiter, Hiring Manager) map to Crelate Users with equivalent access roles. We extract all user records with their role assignments and resolve them by email match against the destination Crelate org. Crelate's role model differs from ApplicantStack's three-role structure — we document the nearest equivalent role assignment for each migrated user during scoping. Users without a matching Crelate account go to a reconciliation queue for the customer's admin to provision before record import completes.

ApplicantStack's configurable pipeline stages (Applied, Screening, Interview, Offer, Hired, Rejected) migrate as Crelate Pipeline stage values. We export the full ApplicantStack pipeline configuration and the per-candidate stage history, replaying the stage progression timeline as timestamped activities attached to each Contact in Crelate. The stage names are preserved as-is unless they conflict with Crelate's default stage vocabulary, in which case we map them to the nearest equivalent during transformation.

Resume files, cover letters, and uploaded documents attached to ApplicantStack candidate records are extracted as binary blobs with their original file names preserved. We attach them to the corresponding Contact record in Crelate. File-type validation runs during extraction to confirm documents are PDF, DOCX, or other standard resume formats; any non-standard file types are flagged for customer review before import.

When ApplicantStack Onboard is active, new hire onboarding packets include I-9 data, tax forms, and custom onboarding documents. We extract these as structured records and separate document blobs. Crelate does not have a native onboarding module with the same I-9 tracking depth as ApplicantStack Onboard — we extract the onboarding data in its entirety and present it as a structured document set that the customer re-imports into their chosen onboarding tool (Crelate's onboarding portal if included in plan, or a third-party onboarding platform) rather than migrating onboarding as native records. We confirm which ApplicantStack product SKU (Recruit only, Onboard only, or bundled) is active during discovery to calibrate this scope.

Candidate tags and job labels from ApplicantStack export as flat tag arrays. We preserve all tags and apply them to the corresponding Contact records in Crelate. Crelate supports tagging on Contacts, Companies, and Job Orders. Where identical tags exist on multiple record types, we apply them to the relevant records. Tag merge logic handles cases where slightly different tag names may have resulted from ApplicantStack's duplicate detection gaps (e.g., a tag applied separately to two duplicate candidate records that we consolidate into one Crelate Contact).

ApplicantStack stores email template content used in candidate communication sequences. We export the template body text and variable placeholders as a content inventory. The automated trigger logic associated with these templates — the conditions under which emails are sent, timing delays, and enrollment rules — does not migrate because it is automation logic rather than content. We deliver a written inventory of each template with its trigger conditions and recommended Crelate automation rebuild, which uses Crelate's Automation and Sequencing tools (available from Business Plus tier). The customer's admin configures sequencing post-migration.

Custom properties added to Candidates or Jobs beyond ApplicantStack's standard schema are captured as key-value pairs. We map them to custom fields in Crelate, creating the destination properties during schema setup before any data import. Crelate's field type system (text, number, date, picklist, multi-select, checkbox) governs the mapping — we perform type inference from the ApplicantStack export values and flag any ambiguous mappings for customer confirmation before import. Employer-defined fields on Job Orders map to custom fields on the Crelate Job Order object.

ApplicantStack's CSV exports are our primary data source for migration. We parse the flat-file structure output by the Reports builder and normalize it into the relational schema required by Crelate's import. This includes expanding multi-valued fields (tags, sources), normalizing date formats, and resolving foreign-key-style references (e.g., Owner ID to a user email) that ApplicantStack embeds as raw values. We build a mapping configuration file during the development phase that governs how each ApplicantStack CSV column maps to the Crelate import field.

ApplicantStack Workflows and automation rules are configuration data that do not export. We document every active ApplicantStack workflow — its trigger, conditions, actions, and active/enrollment status — as a written handoff item for the customer's admin to rebuild in Crelate's Automation and Sequencing tools (Business Plus tier). This includes any custom workflow automation built at the Business tier. The document includes recommended Crelate equivalents for each automation pattern so the admin has a rebuild guide rather than a blank slate.