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

Greenhouse's public pricing page asks buyers to request a quote. That means a migration decision should be based on the actual renewal proposal, the planned destination cost and the work needed to move safely, not on third-party price estimates.

Compare the commercial scope line by line: subscription, implementation, integrations, optional services, data-export support, renewal terms and cancellation or notice requirements. Ask each vendor to state what changes when your hiring volume, employee count or product requirements change.

Also protect the hiring practice that matters to your team. Candidate data can be exported or mapped, but interview criteria, scorecard guidance, workflow rules, permissions and reporting definitions need deliberate reconstruction and validation in the destination system.

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 a substantial interview-kit library, assign the rebuild explicitly to an experienced recruiter as a dedicated workstream with its own estimate and acceptance checks. Do not treat it as a background task.

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.

Implementation compatibility. Before building or buying migration tooling, confirm the currently supported Harvest API authentication, endpoint behavior and rate limits in Greenhouse documentation. Ask a third-party migration provider or internal engineering owner to demonstrate the exact export path before it is used with production candidate data.

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. Start with a representative pilot covering different job types, stages, time periods and records with and without attachments. Verify the mapped fields, stage history, documents and rejection data against the source before importing the full dataset. Correct systematic mapping issues while the scope is small.

Second pass: import the agreed full dataset. After completion, repeat the verification checks on a representative sample from different periods and job types before telling the team that the data is ready.

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

Decide the cutover approach from the active-role risk, data scope and contractual access window. A parallel or read-only period can reduce disruption, but its duration and the treatment of late-stage candidates should be agreed by the recruiting, legal, IT and vendor owners rather than copied from a generic timetable.

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.

Build a migration timeline from the actual scope

Estimate the duration only after these owners agree on the scope and acceptance criteria. A vendor's proposed date is not a substitute for a documented migration plan.

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. The kit rebuild is configuration work, not a data task. Give an experienced recruiter ownership of the competency framework, questions and rating guidance, and make it a named deliverable with an agreed acceptance check.

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 can be evaluated as a destination alongside other ATS options. Ask us to demonstrate an example job, candidate workflow, interview scorecard, role and permission setup, data-import approach and pricing model against your migration requirements.

Treegarden's published ATS pricing uses active-job capacity, with unlimited user accounts; the HR module is optional and employee-based. Its published plans use annual commitments with monthly instalments available. Confirm the current scope, implementation responsibilities and commercial terms in a written proposal.

Use the Treegarden versus Greenhouse comparison and the Treegarden ATS overview as starting points, then hold Treegarden to the same live migration and workflow test you apply to every other destination.

Frequently asked questions