API-to-API is the only migration path that preserves resume searchability and submittal history when moving from JobDiva to Ceipal. CSV imports bypass Ceipal's parser, leaving candidates invisible to recruiters.
Technical guide to migrating from JobDiva to Ceipal. Covers API constraints, data mapping, why CSV imports break resume search, and the only approach that preserves full relational data.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Ceipal does not support true custom objects
Any proprietary data structures you've built in JobDiva — custom screening templates, reference check forms, attribute lists — will need to be flattened into existing Ceipal fields or stored as structured notes. Ceipal does support layered conditional custom fields and attachment-type custom fields (referenced in release notes), and a Custom API surface for additional fields, but this is not the same thing as an open-ended custom-object model. Plan for this before writing any migration code. (developer.ceipal.com)
The CSV Trap
Data imported from CSV files into Ceipal cannot be searched by keyword. You must upload resumes programmatically through Ceipal's applicant creation or resume upload API to trigger the parsing engine and enable full-text search. This is slower per record but is the only way to guarantee searchability.
Watch for downstream automation triggers
When you bulk-create records through Ceipal's API, confirm whether those operations fire webhooks or trigger workflow automations — email notifications, status-change rules, job board pushes. Importing 100K candidates could trigger 100K welcome emails or status-update notifications if automations are active. Disable or pause all workflow triggers in Ceipal before starting a bulk import, and re-enable them only after validation is complete.
Store every legacy JobDiva primary key in Ceipal as an immutable custom field or external reference
Without that crosswalk, retries, validation, and rollback become much harder.
A migration can pass QA and still fail operationally
The fastest way to catch that is recruiter-led UAT with real searches, real submission lookups, and real pipeline views — not static record review.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Scope candidates, pipelines and the compliance obligations that come with them.
Objective Agreed scope across candidates, applications, jobs and interview history, with legal signed up on retention.
Keep these open
-
Inventory every object in JobDiva
Count candidates, applications (a candidate can have many), jobs and requisitions, interviews, scorecards, offers, and resume files. Applications and scorecards usually outnumber candidates several times over, and resume files dominate storage.
Data Profiler Get real record counts instead of estimating from memory -
Settle retention and consent with legal
Candidate data is heavily regulated: GDPR right-to-erasure, EEOC/OFCCP record-keeping, and per-region retention windows that conflict with each other. Decide what may be migrated at all before you scope anything else — this frequently shrinks scope substantially.
Migrating candidate records whose consent has lapsed or whose retention window has expired creates a new compliance breach in the target system.
-
Map the hiring pipeline and agree the target stages
Document every job's pipeline, stage, and rejection reason, then agree the Ceipal model with talent leadership. Stage definitions drive every funnel metric you report, so changing them silently rewrites your hiring analytics.
-
Catalogue integrations and the job-board estate
List job boards, careers-site integration, HRIS, background check, assessment platforms, calendar and email. The careers site and job boards are customer-facing, so their cutover needs its own plan and its own testing.
-
Build the business case and choose the window
Model licence delta, effort and recruiter productivity dip. Time the window against your hiring cycle: a migration during peak graduate recruitment or a hiring surge will fail on people, not technology.
Vendor Evaluator Score Ceipal against alternatives on weighted criteria -
Identify dead data
Candidates with no activity in 3+ years, closed jobs from expired contracts, duplicate records from resume harvesting. Migrating garbage into Ceipal wastes API calls and pollutes search results.
-
Map user-defined fields
Export the full list of userFieldsName values from JobDiva. For each, decide: does it map to a Ceipal standard field, a Ceipal custom field, a note, or does it get dropped?
-
Pull Ceipal master data
Fetch all picklist values (Applicant Statuses, Job Types, Employment Types, Industries, Work Authorizations, Countries, States) via the Master Data API endpoints and build transformation maps before writing migration logic.
JobDiva → Ceipal specifics
- Cost structure
- JobDiva's pricing is client-specific and historically premium. Ceipal's per-user model — starting lower per seat — appeals to mid-market staffing firms scaling recruiter headcount.
- AI-powered sourcing
- Ceipal's AI candidate matching and integrated resume parsing attract teams that want automated screening without third-party add-ons.
- Unified ATS + HRIS + VMS
- Ceipal bundles workforce management, timesheets, VMS, and onboarding into the same platform, reducing the tool sprawl that accumulates around JobDiva deployments. (jobdiva.com)
- Modern API surface
- While JobDiva offers a comprehensive API suite, Ceipal's developer portal and REST API feel more accessible for teams building custom integrations. (developer.ceipal.com)
- Big bang
- Migrate everything over a weekend. Recruiters work in JobDiva on Friday, start in Ceipal on Monday. Simplest operationally but highest risk.
Don't move on until
- Counts confirmed for candidates, applications, jobs and offers
- Retention and consent obligations confirmed with legal
- Hiring-stage model agreed with talent leadership
02 Data Audit Audit candidate data with compliance sitting next to you.
Objective Profiled exports with duplicates, expired records and resume files all quantified and triaged.
Keep these open
-
Export and profile candidates, applications and jobs
Profile each object separately and reconcile against API counts. Watch the candidate-to-application ratio: a mismatch usually means applications have been silently truncated by pagination.
Data Profiler Profile the JobDiva export for nulls, outliers and type drift -
Quantify duplicate candidates and agree survivorship
The same person applies repeatedly over years with different emails and name spellings. Measure the duplicate rate and agree survivorship rules — which record wins and what happens to the application history attached to the losers.
Merging candidates without agreed survivorship rules destroys application and interview history that you may be legally required to retain.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Identify records outside their retention window
Flag candidates whose consent has expired, who have exercised erasure, or who fall outside regional retention. Exclude them from scope and document the exclusion — you need to show the decision was deliberate.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Inventory resume files and attachments
Count files, total volume and MIME types, and check every attachment still resolves to a live URL. Expiring signed download URLs are the classic reason a resume migration completes with a large fraction of empty files.
Resume download URLs are often short-lived signed links. Fetch files close to load time or they will 404 mid-migration.
-
Verify relationship integrity
Confirm every application links to a live candidate and a live job, and every scorecard to a real interview. Orphaned applications produce a funnel report that does not tie to anything.
-
Clean, normalise and produce masked test data
Normalise emails, phone formats and locations, standardise timestamps to UTC, and generate a masked dataset for the sandbox. Real candidate data in a sandbox is a compliance breach in most jurisdictions.
PII Masker Generate a safe copy for sandbox and vendor testing -
Audit your JobDiva data
Count Candidates, Jobs, Submittals, Placements, Contacts, Companies, Hotlists, and Notes. Identify the date range of your oldest records.
JobDiva → Ceipal specifics
- Best for
- Small business, one-time cutover with limited history, few custom fields, and no dependency on submittal lineage or recruiter keyword search.
- Assess compliance requirements
- If your agency operates under GDPR, CCPA, or SOC 2 obligations, map out how candidate consent records, data retention policies, and data residency constraints will be handled during and after migration. Consent artifacts stored in JobDiva need explicit handling — they won't auto-transfer, and losing them creates regulatory exposure.
Don't move on until
- Duplicate candidate rate quantified with a merge policy agreed
- Records outside retention identified and excluded
- Resume and attachment inventory complete with total volume
03 Field Mapping Map the candidate-application-job triangle before anything else.
Objective A signed mapping covering objects, stages, rejection reasons, scorecards and EEO fields.
Keep these open
-
Map the candidate, application and job model
ATS platforms differ on whether a person or an application is the primary record. Establish this first: getting it wrong means one candidate becomes five, or five applications collapse into one, and the entire field map has to be redone.
Candidate-centric and application-centric models are not interchangeable. Confirm which Ceipal uses before mapping any field.
Schema Mapper Match JobDiva fields to Ceipal by uploading both schemas -
Map pipeline stages and rejection reasons exhaustively
Enumerate every stage and rejection reason across all jobs, including retired values on historical applications, and map each explicitly. Unmapped rejection reasons are both a reporting gap and, in regulated hiring, a compliance one.
-
Decide EEO and diversity data handling
These fields are separately regulated and often legally required to be stored apart from the candidate record. Confirm with legal whether they migrate at all, and how Ceipal isolates them.
EEO data usually cannot be migrated into ordinary custom fields without breaching the segregation rules that govern it.
-
Map interviews, scorecards and feedback
Structured scorecards rarely have a native equivalent. Decide whether to reconstruct them, flatten them into notes, or keep them only in the archive — and be explicit that flattening loses the ability to report on them.
JSON to CSV Converter Flatten nested API responses into a reviewable sheet -
Plan resume and file migration
Confirm size limits, MIME support and whether Ceipal re-parses resumes on upload. Re-parsing can overwrite carefully curated candidate fields with worse machine-extracted values, so test it deliberately.
-
Set load order and freeze the spec
Users, then jobs, then candidates, then applications, then interviews and scorecards, then files. Keep source IDs in custom fields, then version and sign off the spec.
JobDiva → Ceipal specifics
- Picklists
- Build explicit mapping tables for status, source, job type, employment type, work authorization, and industry. Values that don't match Ceipal's picklists will be silently rejected or defaulted.
- Multi-value text
- Split skills, certifications, and tag-like fields deterministically. Ceipal may use structured skill tags versus free-text.
- Attachments
- Separate binary handling from row handling — resumes need to go through the parsing path.
Don't move on until
- Candidate/application/job model mapped and reviewed
- Every stage and rejection reason explicitly mapped
- EEO and diversity field handling agreed with legal
04 Test Migration Pilot whole candidate journeys, not isolated records.
Objective A sandbox pilot where candidate journeys, funnel metrics and resume files all verify.
Keep these open
-
Configure the Ceipal sandbox with the agreed pipelines
Create jobs, pipeline stages, scorecard templates, user roles and custom fields first. Loading applications before the stages exist puts every candidate in a default stage and invalidates the pilot.
-
Select complete candidate journeys as the pilot slice
Take 100-200 candidates with all their applications, interviews, scorecards and files — including repeat applicants, hires, rejections at every stage, and candidates on multiple jobs. Repeat applicants are where the model mapping actually gets tested.
-
Run the load in dependency order with logging
Jobs, candidates, applications, interviews, then files, logging each request against its source ID. Track file uploads separately: they fail for different reasons and at different rates than record writes.
-
Verify journeys and funnel metrics
Confirm each candidate sits at the right stage on the right job with their history intact, and that per-stage funnel counts match JobDiva for the pilot jobs. Funnel mismatches point straight back to stage mapping.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Open every pilot resume and check re-parsing
Actually open the files rather than trusting the upload count, and check whether re-parsing has overwritten any candidate fields. A resume that uploaded as a zero-byte file still counts as a success in most logs.
-
Put recruiters in front of the pilot data
Have recruiters work their own pilot requisitions end to end. They immediately spot missing feedback, wrong stages and unreadable history that reconciliation cannot see.
Don't move on until
- Candidate-application-job relationships intact for the pilot
- Funnel counts per stage match source for pilot jobs
- Resume files open correctly for every pilot candidate
05 Cutover Switch recruiting without dropping a live candidate.
Objective All in-scope recruiting data live in Ceipal, careers site and boards repointed, recruiters working.
Keep these open
-
Pre-load historical candidates and closed jobs
Load closed requisitions, rejected candidates and archived applications while JobDiva stays live. Only active pipeline and the final delta need to move in the window.
-
Publish the runbook including the careers-site switch
A timed sequence with owners and abort criteria, treating the careers site and job boards as first-class steps. They are candidate-facing, so a failure there is publicly visible in a way a data defect is not.
-
Freeze JobDiva and take the final delta
Stop new applications and let recruiters finish in-flight actions, then export everything changed since the pre-load. Coordinate with anyone actively interviewing so feedback is not entered into the old system mid-freeze.
Interview feedback entered in the old ATS during the freeze is lost, and it is the data recruiters most immediately notice missing.
-
Load active pipeline and reconcile stages
Load active candidates and applications, then verify every active candidate is at the correct stage on the correct job before repointing anything. Active-stage accuracy is what recruiters check first on day one.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint careers site, job boards and integrations
Switch the careers-site integration, repost or migrate live job ads, and repoint HRIS, background check, assessment and calendar integrations. Then submit a real test application through the careers site and every major board.
Job ads left posted against the old ATS keep collecting applications that never reach the new system.
-
Go/no-go and switch recruiters over
Call the decision against the exit criteria, then move recruiters with support on hand for the first day. Keep JobDiva read-only — candidate records have retention obligations that outlast the migration.
-
Define your rollback plan
If Ceipal data is corrupt after import, what's your path back? Ceipal's API does not offer a bulk-delete endpoint for imported records, so rolling back means you're dealing with record-by-record cleanup or asking Ceipal support for a tenant-level restore. Any records that triggered downstream automations (status changes, notifications, job board pushes) before you caught the problem cannot be unsent. This is why dry runs in a sandbox matter — and why you should ensure JobDiva read-only access is retained for at least 90 days post-migration.
Cron Expression Builder Schedule the delta syncs that run through the freeze
Don't move on until
- Historical load complete and reconciled before the freeze
- Careers site and job boards posting into Ceipal and verified
- Active candidates confirmed at the correct stage
06 Validation Prove the funnel, the files and the compliance position.
Objective Reconciled recruiting data, funnel parity with baseline, and a defensible compliance record.
Keep these open
-
Reconcile every object including files
Compare counts for candidates, applications, jobs, interviews, scorecards and files, with field-level spot checks on a sample. Count files separately — they are the object most likely to be quietly short.
Migration Validation Tool Reconcile JobDiva and Ceipal record-for-record -
Tie funnel and time-to-hire reporting to baseline
Rebuild funnel conversion, time-to-hire, source effectiveness and offer-acceptance reporting and compare to pre-migration figures. Variances trace back to stage mapping and to how application timestamps were handled.
Time-to-hire depends on stage-transition timestamps. If those were approximated, the metric will differ even with identical records.
-
Verify file integrity at scale
Sample-open resumes across the whole load and compare file sizes against source. Zero-byte and truncated files are common and never surface in an upload success count.
-
Confirm retention, consent and EEO configuration
Verify retention rules, consent state and EEO segregation are correctly configured in Ceipal, and that excluded records genuinely did not migrate. File this as your compliance evidence.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Test workflow, notifications and candidate-facing paths
Fire every stage automation, interview scheduling flow, rejection template and offer approval, and submit a live application through the careers site. Candidate-facing emails going out wrong is a brand problem, not just a bug.
-
Sign off and schedule decommission
Get written acceptance against the Discovery criteria, retain JobDiva read-only for the period your retention policy requires, take a final archive export, and diarise cancellation.
-
Rebuild automations
JobDiva workflow triggers don't transfer. Recreate email templates, submittal notifications, and interview scheduling rules in Ceipal.
-
Monitor for 30 days
Watch for missing records, search gaps, duplicate rates, and integration failures. Keep JobDiva read-only access as a fallback.
-
Run a controlled delta-sync window
until you're sure no late source edits need replay.
JobDiva → Ceipal specifics
- Reconfigure integrations
- Job board connections, VMS integrations, email syncs — all need to be re-established in Ceipal.
- Recreate business rules
- Any logic that was implicit in JobDiva statuses, hotlists, or recruiter habits needs to be explicitly rebuilt in Ceipal's workflow tooling.
- Train recruiters
- Ceipal's UI and search work differently from JobDiva. Plan 1–2 days of hands-on training focused on candidate search, submission workflows, and reporting.
Don't move on until
- Reconciliation complete across candidates, applications and files
- Funnel and time-to-hire reporting tie to baseline
- Retention and EEO configuration verified, acceptance signed
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
Sample JobDiva Ceipal Field Mapping
| JobDiva field | Ceipal field | Notes |
|---|---|---|
| candidateId | legacy_candidate_id (custom field) | Store as immutable crosswalk key |
| firstName / lastName | first_name / last_name | Trim, title-case if needed; preserve raw in audit log |
| Lowercase, dedupe; primary email only — Ceipal may not support multiple | ||
| phone / mobilePhone | phone / mobile_number | E.164 normalize for consistent formatting |
| city / state / zip | city / state / zip_code | State must match Ceipal's States List master data |
| skills | skills | Split, trim, rejoin deterministically; Ceipal may use structured skill tags vs. free-text |
| workAuthorization | work_authorization | Map to Ceipal's Work Authorizations picklist |
| candidateStatus | applicant_status | Map via lookup table; do not free-type |
| resumeFile | Attached via Create Applicant | Must upload binary file, not reference path — triggers parsing |
| salary / payRate | pay_rate | Normalize to Ceipal's Pay Frequency Types |
| jobId | legacy_job_id (custom) + job posting link | Use ID mapping table |
| submittalId | legacy_submission_id (custom) | Required for replay and QA |
| submittalStatus | submission_status / pipeline_status | Map JobDiva lifecycle stages → Ceipal statuses; validate semantics with end users |
| companyName / companyId | client_name / legacy_client_id (custom) | Create Client first, reference by Ceipal ID |
| hotlistName | talent_bench / tags / custom fields | Reinterpret semantics; no direct API equivalent |
| userField_* | Custom field or Note | Case-by-case; expect data flattening |
| interviewRound | interview_round | Normalize numeric and text labels; keep original raw value |
| placementStartDate | Placement start date | Normalize timezone and date format |
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can I use CSV export to migrate data from JobDiva to Ceipal?
You can, but resumes imported via CSV bypass Ceipal's parsing engine, making candidate profiles unsearchable by keyword. CSV works for basic tabular data like companies and contacts, but breaks resume searchability and loses relational linkages between Candidates, Submittals, and Placements. Use the Ceipal API's Create Applicant endpoint with attached resume files instead.
What are the JobDiva API constraints for historical data extraction?
JobDiva's key extraction endpoints require mandatory fromDate and toDate parameters in MM/dd/yyyy HH:mm:ss format. You cannot pull all records in a single call. Your migration script must chunk historical data into date windows and paginate within each window using pageNumber and pageSize parameters. Exact rate limits aren't publicly documented, so build in exponential backoff.
How long does a JobDiva to Ceipal migration take?
It depends on data volume and complexity. A small agency with under 10K candidates and minimal custom fields can complete in 3–5 days. Enterprise migrations with 50K+ candidates, complex submittal histories, and resume file uploads typically take 1–3 weeks including validation. A managed migration service can compress timelines significantly.
Does Ceipal support custom objects like JobDiva's user-defined fields?
Ceipal has limited custom field support — including layered conditional custom fields and a Custom API surface — but does not support true custom objects. JobDiva's flexible user-defined fields and custom screening templates will need to be flattened into existing Ceipal fields or stored as structured notes. Plan for some data consolidation or loss during mapping.
How do I handle Ceipal API token expiration during a long migration?
Ceipal's access token expires after approximately 1 hour, and the refresh token is valid for 7 days. Your migration script must implement proactive token refresh logic — check token age before each API call and refresh before expiry, not after the first 401. A failed refresh mid-migration can corrupt partially imported data if not handled with idempotent writes.