Migrate from ZippyApp to BambooHR

Job Seeker records in ZippyApp include name, contact details, application history, and resume attachment. We map these to BambooHR Candidate records, preserving the job seeker's name, email, phone, and address in BambooHR's standard candidate fields. The application timeline is preserved by linking each Job Seeker to the corresponding Application record. Resume files are attached to the Candidate record separately as documents. If a single Job Seeker applied to multiple employers, we create one Candidate record per employer and cross-reference via a custom source_id__c field.

Employer accounts store the company profile, hiring team members, and job postings tied to a single employer. We map these to BambooHR Company records, preserving the employer name, industry, and contact information. Hiring team members in ZippyApp who are not themselves job seekers become BambooHR employee records with a hiring_manager or recruiter role designation in the Employee record. Employer branding assets such as logos and QR-code graphics are excluded because they do not map to any standard BambooHR object.

Each ZippyApp Position has a title, description, location, and employer assignment. We map these to BambooHR Job records, preserving the job title, description, and location fields. The Position's employer assignment links to the corresponding BambooHR Company record via a lookup relationship. The original QR-code identifier from ZippyApp is stored in a custom field job_qr_code__c on the BambooHR Job record so that the customer's admin can reference it if physical QR-code job discovery continues post-migration.

Applications link a Job Seeker to a Position with a status field (submitted, reviewed, interviewed, offer extended, hired, rejected). BambooHR does not have a native Application object separate from the Candidate record. We map each Application to the corresponding BambooHR Candidate, preserving application status as a custom picklist field application_status__c and the application submission date as application_submitted_date__c. If a single Job Seeker applied to multiple Positions, we create one Candidate record per application and cross-reference them via a custom source_application_id__c field. The full application lifecycle is documented in a Candidate note at migration time.

Resume files attached to Job Seeker records in ZippyApp are extracted as binary blobs and attached to the corresponding BambooHR Candidate record as documents in the Files section. We note that PDF versus DOCX parsing is not guaranteed because BambooHR stores files rather than parsing resume content. We flag any resume that cannot be successfully attached so that the destination recruiter knows to request it directly from the candidate post-migration.

Cover letters are optional attachments per application in ZippyApp. We attach them to the same BambooHR Candidate record as the corresponding resume, tagging each cover letter file with a custom label cover_letter indicating it was included in the original application. We flag any application that included a cover letter so that the destination recruiter knows it was part of the original submission even if the file format is incompatible with direct attachment.

The application status field in ZippyApp tracks the progression from submitted through reviewed, interviewed, offer extended, hired, or rejected. We map each status value to a corresponding custom picklist value in BambooHR's application_status__c field on the Candidate record. Status values that do not have a direct BambooHR equivalent (such as archived, which a reviewer reported can be set accidentally in ZippyApp) are mapped to the nearest applicable value and flagged in the migration reconciliation report.

ZippyApp stores the full application lifecycle including submission timestamps, status changes, employer notes, and recruiter interactions. We preserve this history as a formatted note on the BambooHR Candidate record, with each timeline entry dated and labeled by event type. The note is appended at migration time and carries the original timestamps so that the destination recruiter has the full context of the candidate's journey from first application through final disposition.

Push notifications and email alerts generated by ZippyApp during the hiring workflow are transient communication events. They are not stored as persistent records in ZippyApp and have no equivalent in BambooHR's data model. We exclude Hiring Notifications from migration scope. Post-migration, we recommend that the customer's admin configure BambooHR's built-in email notification settings to replicate the hiring alert behavior.

Logos, brand colors, QR-code graphics, and other media assets tied to ZippyApp employer accounts do not map to any standard BambooHR object. We exclude Custom Employer Branding Assets from migration scope and deliver a written checklist of all identified branding assets with their source locations so that the customer's admin can upload them manually to the BambooHR employer profile or job postings post-migration.

ZippyApp Employer accounts include hiring team members who review applications and make disposition decisions. These team members are mapped to BambooHR Employee records associated with the corresponding Company record, with their role designated as hiring_manager, recruiter, or interviewer based on the team role captured in ZippyApp. Employee records are created before Candidate records so that the recruiter assignment lookup is satisfied at the time of Candidate import.