Migrate your Jobylon data

Jobylon exposes Jobs as the primary container with per-company custom fields configured via /config/companies/{companyId}/job. We map standard job fields (title, department, location, description) directly and flag any required custom fields that lack counterparts in the destination schema.

Applications are the core record linking a Candidate to a Job, with workflow status tied to Pipeline Stages. We preserve the stage-history timeline and map stage names to the destination's pipeline model. Custom application fields are tenant-specific and require pre-migration schema review.

Candidates may have multiple Applications across Jobs. We deduplicate by email and merge application histories. GDPR-related fields (consent, erasure dates) are carried as custom properties unless the destination has native GDPR modules.

Pipelines are per-Job and fully configurable. Active and inactive stage names are not standardised, so we map them explicitly and flag inactive stages with assigned Lost Reasons as termination records rather than open pipeline nodes.

Scorecards are tied to Pipeline Stages and record evaluations by specific Users. We export the scorecard schema, the rating values, and the evaluator name. If the destination lacks a scorecard object, we store them as structured custom fields on the Application.

Custom fields for Jobs and Applications are defined per-company via the Partner API. Dynamic custom fields — which build secondary forms based on prior submissions — are not automatically available and require contacting Jobylon support to activate before migration scoping.

Users map to recruiters, hiring managers, and admins with configurable permission levels. We map User IDs as Owner/Assignee fields on Applications and Jobs, and flag permission-level differences where the destination has a flatter role model.

Lost Reasons are predefined classification labels assigned when an Application moves to an inactive stage (e.g. Rejected). We carry these as a tagged field on the Application record rather than a native object in most destination systems.

Offer letter documents and details are stored as attachments associated with Applications. We export the attachment URLs and filenames but do not migrate the document content itself due to the lack of a document content API endpoint.

Free-text evaluator notes and assessor feedback are exported as structured comment records. We preserve the author, timestamp, and content body, mapping them to the destination's notes or activity log.