Migrate from Greenhouse ATS: The Complete Playbook, Data Export, Stage Mapping, Pitfalls, and a Realistic Timeline

Why teams leave Greenhouse, and what to be honest about

The decision to migrate away from Greenhouse is almost always financial, not functional. Greenhouse does not publish list prices, and it scales pricing on total employee headcount as a proxy for hiring volume, not on recruiter seat count. The most useful public reference point is aggregated buyer data: Vendr’s marketplace reports a median Greenhouse contract of about $26,700 per year across hundreds of transactions, with a range of roughly $10,000 to $75,000 depending on tier, headcount, and negotiation. Greenhouse renamed its tiers in 2025 from Essential, Advanced, and Expert to Core, Plus, and Pro; third-party tier analysis places Core around $5,000-$15,000, Plus around $15,000-$40,000, and Pro at $40,000-$70,000 and up, before one-time implementation fees of $1,000-$15,000 and optional modules.

The structural cost problem is the renewal escalator. Standard contracts commonly carry annual increases reported in the 8-15% range, and the renewal price is not locked. A team that signed near $20,000 in year one can be looking at $24,000-$26,000 by year three on escalators alone, before any tier or headcount change. That is the trigger for most migration evaluations: not dissatisfaction with the product, but a renewal quote that no longer pencils out against hiring volume or budget. Treat the exact figures above as directional, your own contract and quote are the only authoritative numbers, but the direction of travel at renewal is consistent enough to drive the decision.

Before you start a migration evaluation, be equally honest about the other side of the ledger. Greenhouse’s structured hiring methodology, interview kits, scorecard aggregation, calibration workflows, multi-stage approval, is genuinely valuable if your team uses it. A migration that saves $20,000 per year but degrades your interview quality will cost more in bad hires within 18 months than it saves in software fees. This guide is written to help you preserve both the data and the methodology, and to be clear about which parts of each require active effort versus which happen automatically.

Phase 1: Pre-migration audit, what to document before you touch anything

The most common reason ATS migrations run over time and budget is that they begin with the export and discover the complications afterwards. A 3-5 day pre-migration audit prevents the majority of surprises. Do not skip it because you feel ready to start moving data.

Step 1.1, Check your data retention configuration first

Greenhouse lets you configure data retention rules that govern when candidate personal data should be removed. Per Greenhouse’s own support documentation, the retention timer starts once a candidate is hired or rejected on all of their applications, and it applies retroactively to existing hired and rejected candidates. Rejected-candidate rules are configurable per office; hired-candidate rules apply organization-wide and cannot be set per office. When the timer lapses, a designated user is notified by email that the candidate’s personal data should be deleted, and the specific fields removed are whatever you selected in the rule. One nuance that matters for talent pooling: if a rejected candidate is later added to a new pipeline, Greenhouse deactivates and resets that candidate’s timer.

If your account has these rules configured, and most GDPR-conscious Greenhouse accounts do, some historical candidate records you expect to export may already have had personal data removed, or be flagged for deletion. Greenhouse also notes that any personal data already deleted will not appear in reports, so a record count alone can hide the gap. Review your retention configuration before initiating any export and document three things: which offices have rejected-candidate rules active, what the retention period is set to, and which fields each rule deletes. That defines the realistic scope of what you can actually export. A migration scoped against your assumption of complete history will miss this and produce an unexplained shortfall in the candidate database after import.

Step 1.2, Integration inventory

Document every integration connected to your Greenhouse account. The categories to cover: job board syndications (LinkedIn, Indeed, Glassdoor, etc.); HRIS connections (Workday, BambooHR, Personio, etc.); background check providers; video interview platforms; calendar integrations; assessment tools; and any custom webhook or API integrations your engineering team built directly. For each integration, record three things: how frequently it is used by the team in active workflows; whether your target ATS has a native equivalent; and what breaks immediately at cutover if this integration stops working.

Greenhouse’s marketplace lists several hundred integrations. Your target ATS will have fewer, and that is fine if you have mapped what you actually use. The integrations most likely to be unavailable in a lower-cost ATS are the deep bi-directional HRIS syncs and partner-built integrations designed specifically around Greenhouse’s data model. The integrations most likely to transfer cleanly are commodity job board connections and calendar tools that every modern ATS supports. The decisive column in your inventory is the third one, what breaks at cutover, not the total count.

Explicitly ask your engineering team whether any custom integrations exist that are not in the official Greenhouse integration panel. Custom webhooks that post candidate events to Slack, Zapier automations built on Greenhouse triggers, or internal tools that read from the Harvest API are often completely unknown to the HR team. They all stop working when Greenhouse access ends.

Step 1.3, Attachment inventory and export strategy

Run a count of candidate attachments in your Greenhouse account: resumes, cover letters, portfolio files, and signed offer documents. This number drives the resource and time estimate for the attachment portion of the export.

Per the Greenhouse Harvest API documentation, resumes, cover letters, and other attachments are hosted on AWS and returned as signed temporary URLs, not permanent links. Greenhouse documents these URLs as valid for 7 days and explicitly advises downloading the documents immediately rather than relying on the URL for future requests. In practice that means your export must fetch and persist the binary file as part of the same run that reads the candidate record, not park the URL in a spreadsheet to batch-download a fortnight later. Save each attachment to local storage with a filename that encodes the candidate and application IDs, so the import step can re-attach every file to the right record. Build this into the export design from the start; it is the single most common cause of a re-run.

Step 1.4, Interview kit documentation export

Before initiating any data export, export complete documentation of every interview kit in your Greenhouse configuration. This means: job name or role type, interview stage the kit belongs to, all competency sections, every question listed under each competency, the rating scale with label definitions for each score point, and any interviewer guidance notes. This documentation is your rebuild specification for the new ATS. Interview kit templates cannot be imported into another platform, they are Greenhouse-specific configuration objects, but they can be rebuilt accurately from documentation.

If your team has 10-20 active interview kit configurations, assign the rebuild explicitly to one experienced recruiter as a dedicated project workstream with its own timeline. Do not treat it as a background task. Based on typical Greenhouse configurations, 1-2 weeks of focused effort is required to rebuild a full interview kit library carefully. That is the rebuild time, not the export time, the export of the documentation itself takes a day.

Pre-migration audit checklist

Before any data leaves Greenhouse, you should be able to tick every item below. If you cannot, you are not ready to export, you are ready to discover a problem mid-migration.

Phase 2: Data export, what the Harvest API actually gives you

Greenhouse’s Harvest API is one of the most capable export interfaces in the ATS category. It provides structured JSON access to virtually all data in your account. Here is a precise account of what you can and cannot retrieve, so you can plan your export scope accurately.

What exports cleanly via the Harvest API

• Candidate profiles. Full person records: legal name, all contact details (email addresses, phone numbers, address), social profile links, source attribution, custom tags, and all custom profile fields your Greenhouse configuration uses. Custom field data is included in the API response for each candidate object.
• Applications. Each application is a distinct object in Greenhouse, linked to a specific candidate and a specific job. Application records include: current stage at the time of export, the full stage history with transition timestamps, rejection reason (structured data important for EEOC disposition code tracking), referral source, and the assigned hiring team members.
• Scorecard responses. The actual interview feedback your interviewers submitted, structured as a list of attributes (competency names), ratings per attribute, and free-text notes, tied to the interviewer’s user record and the application. These export as structured data. They will not arrive in the target system as native scorecard objects you can filter and aggregate; they will arrive as historical reference records. They are preserved, but their functional utility in the new system requires the target ATS to support a similar scorecard data model, and the actual template that generated them must be rebuilt separately.
• Interview schedules. Past interview events with participants, scheduled time, interview type, and location or video link.
• Offer records. Offer data for accepted, declined, and rescinded offers across your account history, including offer details and the approver chain.
• Jobs. Job postings, descriptions, department assignments, hiring team assignments, status history, and job board syndication records.
• Users. All team member records with their roles, office assignments, and permission levels.
• Activity notes. Recruiter and hiring manager notes on candidate records, with author identity and timestamp.
• Attachments. Available as signed temporary URLs in each candidate record response. Must be downloaded as binary files during the export run. Do not archive the URL.

What does not export as functional data

The fundamental distinction in any Greenhouse migration is between data (candidate records, application history, scorecard responses) and configuration (interview kit templates, pipeline stage definitions, approval workflow rules, automation sequences). Data exports. Configuration must be rebuilt.

• Interview kit templates. The structured template with competency areas, specific questions per competency, rating scales with labelled anchors, and interviewer guidance notes. These exist as configuration objects in Greenhouse, not as exportable data records. They can be printed or screenshotted as documentation, but they do not transfer to any other ATS as functional templates. This is the single most impactful item on hiring quality post-migration.
• Pipeline stage definitions. Your Greenhouse pipeline stage names, ordering, and type classifications are configuration. Application records reference stage names, but the stage definitions themselves are not portable. They must be recreated in the target system before the candidate import.
• Approval workflow rules. Job requisition approval chains and offer approval workflows, who must approve, in what sequence, what happens when an approver is out of office, are Greenhouse-specific configuration. Document your current approval rules in detail; rebuilding them in the target system is a non-trivial configuration task.
• Email automation sequences. Automated email templates and sequences configured in Greenhouse do not transfer. Candidate acknowledgement emails, interview confirmation messages, and rejection notice templates must all be rebuilt.
• Structured approval chain history. The record of who approved a job requisition or offer, and when, does not export as useful structured data you can import.

Harvest API mechanics that shape your export tooling

Rate limiting. Per the Harvest API rate limiting documentation, the API applies a fixed-window limit over each 30-second interval, and the exact ceiling is conveyed dynamically in the X-RateLimit-Limit header rather than published as a fixed number. Exceeding it returns HTTP 429. The correct way to handle this is to read the response headers rather than guess: on a 429, Greenhouse returns a Retry-After header telling you how many seconds to wait, alongside X-RateLimit-Remaining (requests left in the window) and X-RateLimit-Reset (the UTC epoch when the window resets). Well-behaved tooling slows down proactively when X-RateLimit-Remaining gets low and backs off for the exact Retry-After duration on a 429, rather than retrying blindly. For accounts with tens of thousands of records, a single-threaded export that ignores these headers will silently drop a fraction of records unless it checks every response code.

Pagination and incremental pulls. The Harvest API paginates list endpoints, so your export loops through pages rather than pulling everything in one call; account for that page count in your runtime estimate. The API also supports filtering many objects by an updated-after timestamp, which is what makes a low-risk cutover possible: you can run a full export days before go-live, then run a fast delta export of only the records that changed since, so the active pipeline lands in the new system current rather than stale.

Pull objects in dependency order. Export the reference objects first, users, offices, departments, jobs, and job stages, then candidates and applications, then the child records (scorecards, scheduled interviews, activity feed, offers, attachments). Mapping at import is far simpler when the parent IDs already exist; a scorecard or interview that references a user or application you have not imported yet has nothing to attach to.

Version deprecation, time-critical in 2026. Harvest API v1 and v2 are deprecated and will be unavailable after August 31, 2026. Any migration integration must target Harvest v3, which authenticates with OAuth 2.0 client credentials (a client ID and client secret) rather than the Basic Auth used by v1/v2. If you are relying on a third-party migration service or an internal tool built earlier against v1 or v2, confirm it has been moved to v3 before you depend on it, a legacy export tool will stop working partway through 2026.

Handling candidate PII during the export, the part most playbooks skip

The moment you run a Harvest export you create a large, portable file of candidate personal data, names, emails, phone numbers, resumes, interview notes, sitting outside both ATS platforms. Under GDPR and similar regimes this is still processing, and you are still the controller, so the export archive needs the same care as the live system, not a folder on someone’s laptop. A few concrete practices that keep a migration defensible:

• Treat the export as a regulated data store from the first byte. Write it to an access-controlled, encrypted location, restrict it to the named people running the migration, and delete the working copies once the import is validated. Do not email candidate files around or drop them in a shared chat channel.
• Confirm a data processing agreement with the destination vendor before you load real data. If the new ATS or its migration service touches your candidate records, they are acting as a processor; the DPA, and where relevant their sub-processor list and hosting region, should be in place before the first production import, not after.
• Check data residency if it matters to you. If your candidates are in the EU or UK and your policy or customers require EU or UK data residency, verify where the destination platform stores data before committing, this is a question to answer in vendor selection, not at go-live.
• Do not silently widen retention. If Greenhouse rules were about to remove certain records, importing them into a new system with no equivalent rule quietly extends how long you hold that personal data. Carry your retention policy across with the data, and make sure the new ATS can enforce it.
• Keep your candidate privacy notice honest. If your notice told candidates which systems hold their data, a new processor and a new location may need to be reflected. Loop in whoever owns your privacy notices and your record of processing activities.
• Respect open data subject requests across the gap. A deletion or access request that arrives mid-migration must be honoured in both the source export and the destination, not lost in the handover. Track any open requests before you start and reconcile them after cutover.

None of this is exotic, but it is the difference between a migration that would survive a data protection review and one that created an unmanaged copy of every candidate you have ever spoken to. This is general operational guidance rather than legal advice; if you are in a regulated sector or unsure of your basis for processing, run the plan past your DPO or counsel.

Phase 3: Data mapping, stages, fields, and the parent-child object problem

Pipeline stage mapping is where most ATS migrations silently fail. Greenhouse uses a specific object model: a Candidate object (the person, with contact details and profile data) is separate from an Application object (a specific candidacy for a specific job). Applications have a stage history as child records. Scorecards hang off Applications as further child records. When you export this to a flat CSV, which is what Greenhouse’s native data export produces, those parent-child relationships are silently destroyed. You get rows of candidate data with no coherent link to their application history, and application history with no link to the scorecards that were submitted for them.

If your target ATS’s import tooling only handles flat CSV files, you have a structural problem that requires a decision: either use a target ATS that supports Greenhouse API import (which can maintain the relational structure), or work with a developer to export via the Harvest API and produce a structured import file that the target system’s import tooling can process correctly. Do not assume that any CSV export and import will produce a coherent candidate history in the new system. Verify with a pilot import before committing to the approach.

Stage name mapping

Before import, create an explicit mapping from every Greenhouse pipeline stage name in your account to the equivalent stage in your target ATS. This is mechanical work but must be done deliberately. No two ATS platforms use the same stage taxonomy, and a systematic mismatch produces application records that land in incorrect stages with no indication that anything went wrong. The error is invisible until a recruiter opens a candidate record and finds their application history in the wrong stage.

Custom field mapping

Document every custom field in your Greenhouse configuration: field name, field type (text, select, multi-select, date, number, yes/no), which object it lives on (Candidate, Application, or Job), and whether it is actively used in reporting or filtering. Create an explicit mapping to the equivalent field in the target ATS, or flag it for recreation as a new custom field. Custom field data that does not map correctly on import is either silently dropped or stored in a generic text field, both outcomes break downstream reporting or candidate filtering that depends on that data. Discover this in the pilot import, not in production.

Phase 4: Rebuilding in the target ATS and running the import

With your data exported and your mapping documented, configure the destination before running the import. Importing candidate data into an unconfigured ATS produces records with no stage definitions, no hiring team assignments, and no interview kit context. Correcting that retroactively is significantly harder than setting up configuration first and importing into a ready system.

Re-creating your job pipelines in the new ATS

Start with pipeline configuration. Create the stages you documented in your mapping table, in the correct order, with the correct stage types. If your target ATS supports stage-level settings, interview type, required scorecard completion before a candidate can advance, automated notifications to hiring managers at specific stages, configure those now, before any candidates are in the system.

For each active role you are migrating, recreate the job configuration systematically: job title, department, hiring lead, employment type, location, status, and collaborator access. Set these up before the candidate import so that applications land inside properly configured job records from day one, not into a generic unconfigured inbox.

Rebuilding interview kits

Use the interview kit documentation you exported in Phase 1 as your rebuild specification. For each kit: create the competency sections in the target system, add the specific questions under each competency, configure the rating scale with labelled anchors, and add interviewer guidance notes. Confirm that an interviewer can access the kit during an interview and submit their scorecard without ambiguity about where to find the form or how ratings are defined.

Review each kit as you rebuild rather than copying it verbatim. Greenhouse kits accumulate cruft over years: questions for roles that no longer exist, competencies added for one hire and never removed, scoring guidance written by someone long gone. The rebuild takes roughly the same focused time whether you replicate or improve as you go, so the cleanup is essentially free now and a separate, expensive project later.

User accounts and permission structure

Create user accounts for every team member before go-live. Configure permissions carefully: recruiters need full candidate management access across the roles they manage; hiring managers need access to their assigned roles and scorecards but should not see roles they are not assigned to; external collaborators (agency recruiters, hiring advisors) may need restricted access to specific pipelines only. The permission granularity varies significantly between ATS platforms, verify that the target system’s permission model maps coherently to the role structure you had in Greenhouse, rather than assuming it will.

Importing candidates and CVs

Run the import in two passes. First pass: a pilot import of 200-500 candidate records, chosen to represent the range of your data, different job types, different pipeline stages, different time periods, candidates with and without attachments. Verify each record manually against the source Greenhouse data: stage history is intact, custom fields have populated correctly, resume files are accessible, rejection reason codes have mapped correctly. Fix any field mapping errors before running the full import. Systematic errors in mapping logic tend to affect entire data segments, all records from a specific time period, or all records for a specific department, and are easiest to diagnose and correct before the full dataset is in the system.

Second pass: full import of all candidate records. After completion, run the same verification checks on a random sample of 50-100 records from different periods and job types. If the pilot was clean, the full import will be clean, but spot-check anyway before signalling to the team that the data is ready.

Phase 5: Parallel run, go-live, and closing Greenhouse

Go-live should not be a hard cutover. Keep Greenhouse in read-only mode for the parallel run period, typically 2-3 weeks, while all new job postings go into the new system. Complete any late-stage candidates in Greenhouse rather than migrating them mid-process. A candidate who is at offer stage or in executive review at go-live does not need to be disrupted by a system transition. Finish that pipeline in Greenhouse; the person who gets hired will be onboarded through the new system anyway.

Go-live checklist

Communicating the transition to hiring managers

Hiring managers who use Greenhouse’s scorecard review regularly have built habits around it: where to find submitted scorecards, how to see all interviewers’ ratings together, how the calibration conversation is structured around the aggregated data. The most important communication is not the announcement, it is the answer to the question they will ask first: “Will I still see structured scorecards from all my interviewers before we decide?” If the answer is yes, lead with that and demonstrate it. If the workflow is different, say exactly what is different and why before go-live. Managers who discover a methodology change on day one become persistent critics regardless of the platform’s actual quality; managers who see the change in advance adapt within 30-60 days.

The sequence that works: announce 3-4 weeks out; run a 30-minute live demo focused specifically on scorecard submission and review; hand out a one-page reference covering what is the same, what is different, and where to get help. Written guidance someone can re-read on their first real day beats a training session they half-remember two weeks later.

Full migration timeline: 6-10 weeks

The pitfalls that catch experienced, well-prepared teams

These are not the mistakes made by teams that rushed in without a plan. These are the failures that appear in post-migration retrospectives from teams that did the research, allocated the time, and still got caught by things they did not know to look for.

Attachment URL expiry discovered too late. The most technically costly gotcha is the attachment URL lifetime. Greenhouse serves resume and document files as signed temporary URLs that it documents as valid for 7 days, with explicit advice to download immediately. An export that logs URLs for a later batch job risks fetching them after they have lapsed, and a tool that assumes the links are permanent will eventually return a wave of failures. The only safe approach is to download each binary during the API run that read the record. If your tooling was not built that way, you must re-run the export with a corrected tool. That is recoverable while you still have Greenhouse access, and unrecoverable once the contract ends, which is why the export design, not just the export, has to be right the first time.

GDPR retention timing narrowing your export window. Greenhouse’s retention rules remove personal data on a schedule you configured, and the timer starts once a candidate is hired or rejected on all of their applications. If you set a 12-month rule and your migration planning drifts past that horizon since a hiring push, part of the candidate pool you assumed you had may already be flagged for deletion or stripped of identifying fields, and Greenhouse notes that deleted personal data also stops appearing in reports, so a record count will not reveal the gap. This is the rules working correctly, not a Greenhouse error. If you need a specific historical window for reporting or talent pooling, review your retention settings before you scope the migration, and adjust the rule for the export period only with documented sign-off from whoever owns data protection. Do not quietly disable retention and forget to restore it.

The hidden integration that breaks at cutover. The integration that breaks on go-live day is almost never LinkedIn or your HRIS. It is a Zapier automation someone set up in 2023 to create a Google Calendar event from Greenhouse interview schedules, or a webhook a developer built to post a Slack message when a candidate reaches offer stage, or an internal talent analytics tool that reads from the Harvest API on a nightly schedule. None of these appear in the official Greenhouse integration panel. All of them stop working when Greenhouse access ends. The integration inventory must include an explicit conversation with your engineering team asking: “Did anyone build anything that connects to Greenhouse that is not listed in the integrations panel?” That question, asked once before migration, prevents a category of go-live surprises.

Interview kit rebuild treated as a background task. This is the one to internalise even though it is covered above: the kit rebuild is configuration work, not a data task, and it needs an experienced recruiter making real decisions about competency frameworks, questions, and rating anchors. Teams that hand it to a junior coordinator or plan to clean it up after go-live consistently land on a simplified, weaker interview structure, and that quality regression outlasts the project. Budget 1-2 weeks of focused time from the recruiting lead who actually runs interviews, and put it on the plan as a named deliverable rather than a background chore.

Import-side limits and tooling assumed, not checked. The export is only half the job; the destination has its own constraints that surprise teams who only planned the Greenhouse side. As a reference point, Greenhouse’s own bulk candidate importer recommends loading no more than 8,000 candidates at a time for performance, and its Bulk Import tool is available only on the higher (Plus and Pro) tiers, a useful illustration that import paths come with batch sizes and tier or plan gates. Ask your target ATS the same questions before you commit: what is the maximum batch size, does importing via spreadsheet preserve the relational structure or only flat fields, and is there an API import that keeps candidate-to-application links intact. Confirm the answers in the pilot import rather than discovering a 5,000-record ceiling at 02:00 on cutover night.

Reporting baseline loss not communicated to leadership. Your historical Greenhouse reporting benchmarks, time-to-fill by department, source performance, stage conversion rates, offer acceptance rates, will not carry forward in a form that produces directly comparable numbers in the new system. Even if the underlying data migrates correctly, different data structures and different metric calculation methodologies produce different numbers for nominally the same metric. Plan for a 3-6 month period during which new-system metrics cannot be directly compared to Greenhouse history. Set that expectation with leadership explicitly before go-live. Leaders who are surprised by apparently different performance metrics three months after cutover may attribute the change to the new system rather than to the reporting baseline shift.

Treegarden as a Greenhouse migration destination

This section describes Treegarden specifically. If you are evaluating multiple ATS platforms, apply the same evaluation questions to all candidates.

Treegarden supports structured interview kits with multi-section competency assessment, individual scorecard submission by each interviewer, and consolidated scorecard review for the hiring manager showing all interviewers’ ratings in a single view. Approval workflows are available for both job requisition sign-off and offer letter approval, with configurable routing and fallback handling. The Kanban pipeline view, visible in the screenshot above, gives hiring managers a visual overview of every candidate across stages, with AI match scores from the Edera engine on each card, so a manager can see the full pipeline state without opening individual records.

On pricing, to be concrete: Treegarden’s published plans are $299, $499, and $899 per month (roughly £235, £395, and £710), with custom Enterprise pricing above that.Contracts do not carry uncapped renewal escalators. For a team paying mid-tier Greenhouse pricing, the annual difference will usually cover 6-10 weeks of migration project time inside the first contract year, but run that maths against your actual renewal quote rather than the directional figures earlier in this guide.

Treegarden is built for UK and US SMBs in roughly the 10 to 500 employee range, and on the capabilities that decide a Greenhouse migration it offers structured interview kits, scorecard aggregation, a Kanban pipeline, approval workflows, custom career pages, GDPR-conscious handling with EU data residency, bulk CV upload, and Edera AI candidate matching. The onboarding team supports the move directly: structured CSV import from Greenhouse’s native export, a Harvest v3 pull for teams with developer resource, interview kit rebuild using your documentation export as the specification, and integration re-mapping. If your hiring depth genuinely exceeds what a mid-market ATS covers, an enterprise platform may be the better fit, hold every destination, including this one, to the live demonstration test below before you commit.

Frequently asked questions