Greenhouse-to-Lever migration requires translating an application-centric schema into an opportunity-centric CRM — scorecards, attachments, and rate limits are where DIY attempts break.
There is no native migration path from Greenhouse to Lever. Greenhouse is application-centric — Candidates link to Applications which link to Jobs with structured Scorecards. Lever is opportunity-centric — a single Contact spawns multiple Opportunities through fluid pipelines. The fundamental gap is data model architecture: Greenhouse's rigid Candidate → Application → Job → Scorecard chain must be translated into Lever's Contact → Opportunity → Posting model, with scorecards serialized into feedback forms or notes. Every migration requires handling expiring attachment URLs, Lever's strict 10 req/sec rate limit (2 req/sec for POSTs), and the structural loss of scorecard attribute-level ratings.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Greenhouse Harvest API v1 and v2 will be deprecated and unavailable after August 31, 2026
If you're planning a migration, build your extraction pipeline against Harvest v3 (OAuth 2.0) from day one — don't build on v1/v2 only to rewrite months later.
Lever's own documentation states that custom integrations typically take 8 to 12 weeks to develop
That's Lever's scoping estimate, not a vendor scare tactic. Factor it into your build-vs-buy decision realistically. (lever-old.zendesk.com)
Before importing anything, extract Lever's stage UUIDs (GET /stages), archive reasons
Before importing anything, extract Lever's stage UUIDs (GET /stages), archive reasons (GET /archive_reasons), and sources. Build a lookup map so your ETL can translate Greenhouse stage names into Lever stage IDs without manual intervention. Most failed historical migrations are not API failures — they are missing destination metadata.
Greenhouse attachment links are temporary signed S3 URLs
Download binaries during extraction and store them in your staging bucket. If your ETL doesn't download and re-upload attachments in the same pipeline run, you risk losing them permanently when the URLs expire. (developers.greenhouse.io)
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 Greenhouse
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 Lever 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 Lever against alternatives on weighted criteria -
Rebuild interview plans and pipelines
Greenhouse interview kits, stage-specific scorecard templates, and approval workflows don't export as transferable configuration. These must be manually recreated in Lever.
COI & ROI Calculator Build the 36-month business case you will need for sign-off
Greenhouse → Lever specifics
- Sourcing workflow
- Lever was built around a CRM-like sourcing model. Teams that rely heavily on passive candidate nurturing — agency recruiters, executive search firms, sourcing-heavy tech companies — often find Lever's Opportunity-per-candidacy model more natural than Greenhouse's rigid application gates.
- Cost consolidation
- Greenhouse's tiered pricing (Core, Plus, Pro) can escalate at scale, especially for teams that need structured interview kits on Plus/Pro tiers. Lever bundles analytics, nurture campaigns, and advanced pipeline management into fewer tiers.
- Operational simplicity
- Greenhouse's power is its configurability — custom scorecard attributes, multi-stage approval workflows, granular user permissions. For teams that don't need that depth, Lever's flatter workflow model reduces admin overhead.
- Small team, active-only data, low eng bandwidth
- Specialist service or tightly scoped CSV import.
- Enterprise, full historical archive
- API-led ETL or managed migration service.
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 Greenhouse 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
Greenhouse → Lever specifics
- Full data extraction
- Candidates, Applications, Scorecards (with structured attributes), Offers, Activity Feeds, Tags, Sources, Custom Fields, and Attachments — all via API, preserving the complete relationship graph.
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 Lever uses before mapping any field.
Schema Mapper Opens pre-loaded with the Greenhouse → Lever field pair -
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 Lever 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 Lever 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.
Greenhouse → Lever specifics
- Transformation and load
- Our ETL pipeline handles ID cross-referencing, email-based deduplication, scorecard serialization, attachment re-upload, and rate-limit management — including shared Redis-backed rate limiters for concurrent workers.
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 Lever 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 Greenhouse 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 Lever, 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 Greenhouse 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 Greenhouse 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 Greenhouse read-only — candidate records have retention obligations that outlast the migration.
Greenhouse → Lever specifics
- Ongoing sync after go-live
- Webhooks plus API loaders; iPaaS only for light deltas or adjacent automation.
- Greenhouse API key handoff
- You generate a Harvest v3 credential with all endpoint permissions enabled. We begin extraction within 48 hours.
- Mapping workshop
- We walk through stage mapping, archive reason mapping, custom field translation, and scorecard handling decisions with your recruiting ops team.
Don't move on until
- Historical load complete and reconciled before the freeze
- Careers site and job boards posting into Lever 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 Greenhouse and Lever 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 Lever, 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 Greenhouse read-only for the period your retention policy requires, take a final archive export, and diarise cancellation.
-
Monitor for data inconsistencies
Run validation queries weekly for the first month. Watch for orphaned Opportunities, missing tags, and custom field values that didn't translate correctly.
Greenhouse → Lever specifics
- Validation
- Record count reconciliation, field-level spot checks, relationship integrity verification (every Opportunity has the correct Contact, every historical note is attached to the right Opportunity).
- Reconfigure integrations
- Any tool connected to Greenhouse (HRIS, background check, scheduling) needs to be re-pointed to Lever's API. Budget 2–4 weeks depending on how many integrations you have.
- User training
- The Contact vs. Opportunity distinction is the biggest UX shift from Greenhouse. Schedule focused sessions targeting specific workflow changes — not generic platform overviews.
- Decommission Greenhouse
- Don't delete your Greenhouse account immediately. Keep it in read-only mode for 90 days minimum as a reference. Some ATS vendors charge for data exports after contract termination — confirm your terms before canceling.
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.
Object Equivalent
| Greenhouse field | Lever field | Notes |
|---|---|---|
| Candidate | Contact | 1:1 mapping. Greenhouse integer ID → Lever UUID. Store a cross-reference table. |
| Application | Opportunity | Each Application becomes an Opportunity linked to the Contact. Preserve applied_at as createdAt. |
| Job | Posting | Map Job title, department, location, status. Interview plans don't transfer — rebuild in Lever. |
| Scorecard | Feedback / Note | No direct equivalent. See the scorecard section below. |
| Offer | Offer (on Opportunity) | Map offer fields. Lever offers are simpler — custom offer fields may need to be flattened. |
| Prospect | Opportunity (without Posting) | Greenhouse prospects with 0 jobs become Lever Opportunities not linked to any Posting. |
| Source | Source (on Opportunity) | Map Greenhouse source names to Lever source values. Create missing sources in Lever first. |
| Rejection Reason | Archive Reason | Map Greenhouse rejection reasons to Lever's archive reasons. Create custom archive reasons as needed. |
| Tags | Tags | Direct mapping. Bulk-create in Lever before import. |
| Activity Feed (Notes, Emails) | Notes | Greenhouse notes map to Lever notes on the Opportunity. Preserve author and timestamp. |
| Attachments (Resumes, Cover Letters) | Files (on Contact/Opportunity) | Download from Greenhouse S3 URLs, re-upload via Lever's multipart/form-data endpoint. |
| Custom Fields | Custom Fields | Requires manual mapping. Greenhouse supports 12+ custom field types; verify Lever supports the equivalent data type. Greenhouse application custom fields may only be accessible via API on Enterprise accounts. (developers.greenhouse.io) |
| Prospect Pool / Stage | Lead-stage Opportunity, Tag, or Nurture segment | No exact 1:1 object in Lever. |
| Company / Agency metadata | Tags, contact headline, note, or external table | Usually not a first-class ATS object on either side. |
Greenhouse Lever
| Greenhouse field | Lever field | Notes |
|---|---|---|
| candidate.first_name + last_name | contact.name | Concatenate first and last name |
| candidate.emails [].value | contact.emails [] | Direct array mapping; lowercase and dedupe |
| candidate.phone_numbers [].value | contact.phones [] | Direct array mapping; normalize to E.164 if possible |
| candidate.addresses [].value | contact.location | Use primary address |
| application.applied_at | opportunity.createdAt | Convert ISO-8601 to epoch milliseconds |
| application.source.public_name | opportunity.sources [] | Map to Lever source string |
| application.current_stage.name | opportunity.stage | Map by semantics to Lever stage UUID (requires pre-lookup) |
| application.status | opportunity.archived / active | hired/rejected → archived with reason; active → active |
| scorecard.overall_recommendation | Feedback or Note | See scorecard section above |
| candidate.tags [].name | opportunity.tags [] | Direct mapping |
| candidate.custom_fields | contact/opportunity custom fields | Type-by-type transformation |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Scorecards/Feedback | high | Per-attribute ratings lost; must map to Lever feedback templates or serialize as notes |
| Attachments (Resumes) | high | Greenhouse S3 URLs expire — must download during extraction and re-upload to Lever |
| Interview Scheduling History | high | Calendar events and panel configurations have no import path in Lever's API |
| EEOC/Demographic Data | high | Stored at application level in Greenhouse; Lever's approach differs and requires legal review |
| Confidential Postings | medium | Lever API cannot create confidential postings — must be recreated manually |
| Custom Fields | medium | Greenhouse supports 12+ types; Lever equivalents require type-by-type transformation |
| Pipeline Stage History | medium | Lever stages are customer-defined and rarely match Greenhouse stage names 1:1 |
| Source Attribution | low | Direct mapping with pre-creation of missing sources in Lever |
| Tags | low | Direct mapping; bulk-create in Lever before import |
| Notes/Activity Feed | low | Greenhouse notes map cleanly to Lever notes on opportunities |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Scorecard Structure Loss
Greenhouse scorecards have typed attributes with categorical ratings. Lever feedback forms use a different template-driven schema that cannot replicate per-attribute ratings 1:1.
Relationship Chain Integrity
The Candidate → Application → Scorecard chain must become Contact → Opportunity → Feedback without orphaning records or breaking historical context.
Attachment URL Expiration
Greenhouse serves resume files via signed temporary S3 URLs. If your ETL doesn't download and re-upload in the same run, files are lost permanently.
Rate Limit Management
Lever enforces 10 req/sec steady-state and 2 req/sec for application POSTs. Enterprise imports of 50K+ candidates require hours of carefully throttled throughput.
Timestamp Conversion
Greenhouse uses ISO-8601 timestamps while Lever uses Unix epoch milliseconds. Every date field needs explicit conversion during the transform phase.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
How long does a Greenhouse to Lever migration take?
Lever's own documentation estimates 8–12 weeks for custom integrations. A managed migration service like ClonePartner typically completes the full data transfer in days, though total project time including mapping decisions and validation is usually 1–3 weeks.
Can Greenhouse scorecards be migrated to Lever?
Yes, but with compromises. Greenhouse scorecards are structured objects with typed attributes and ratings. Lever uses feedback forms with a different, template-driven schema. You can map scorecards to Lever feedback (requires pre-creating templates for each unique scorecard type) or serialize them as detailed notes. Either way, the exact attribute-level rating taxonomy won't transfer 1:1 without custom transformation work.
What are the Lever API rate limits for data migration?
Lever enforces a steady-state limit of 10 requests per second per API key, with bursts up to 20 req/sec. Application POST requests are capped at 2 req/sec. These limits are not guaranteed and may change. Use exponential backoff with jitter and a shared rate limiter (like Redis) for concurrent workers.
Will a CSV export from Greenhouse work for migrating to Lever?
Only for small, simple migrations under roughly 5,000 candidates. CSV exports flatten relational data — you lose the Candidate → Application → Scorecard relationship chain, structured interview attribute ratings, and attachments. For anything beyond basic active-only candidate records, API-based migration is the only viable path.
Is the Greenhouse Harvest API being deprecated?
Harvest API v1 and v2 will be deprecated and unavailable after August 31, 2026. All new integrations should use Harvest v3, which uses OAuth 2.0 instead of Basic Auth and cursor-based pagination instead of page/per_page parameters.