Greenhouse to Ashby is one of the better documented ATS migrations, but it is still not a switch you flip and forget. Ashby has a supported API path that reads Greenhouse through Harvest V3, performs an initial sync and then keeps checking for updates. The hard work is understanding what moves, what does not and how to prove the destination is complete before recruiters start using it.
Use the supported API migration
Ashby's migration guide requires an Ashby Organization Admin and a Greenhouse user who can manage all API credentials. The setup uses Greenhouse Harvest V3 with read and list access to the objects being migrated. Ashby also documents a set of webhooks used to keep changes synchronized.
The migration is read-only against Greenhouse. Ashby runs the initial import, then syncs updates hourly and shows the last successful sync time. This gives the team time to configure and test Ashby while recruiters continue working in Greenhouse.
What Ashby says it migrates
Ashby's official list covers much of the recruiting model. It includes departments, offices, jobs, openings, job stages, custom fields, candidates, candidate notes, users, scorecards, sources, candidate tags, job posts, offers, offer letters, resumes, rejection reasons, rejection questions, scheduled interviews, degrees, disciplines, EEOC data, email templates, close reasons, demographic questions and application-form submissions.
| Greenhouse area | Ashby destination | Check during validation |
|---|---|---|
| Candidate | Candidate | Contact details, tags, custom fields and resume |
| Application | Job consideration | Job, stage, status and source history |
| Job and opening | Job and opening | Department, office, stage plan and open state |
| Interview and scorecard | Scheduled interview and scorecard | Interviewer, timing and structured feedback |
| Offer | Offer and offer letter | Private data permission and document presence |
| Candidate note | Candidate note | Author, date, body and privacy |
| Rejection reason | Archive reason | Reason mapping and custom fields |
| Email template | Archived template | Placeholder tokens and restored status |
Use the list as the start of a test plan, not as proof that every field and relationship matches your configuration. Greenhouse accounts accumulate custom fields, inactive stages, private notes and integrations that use source IDs. Each one needs a destination decision.
Know the documented exclusions
Ashby does not map Greenhouse user permissions. Recreate roles and access controls in Ashby before users sign in. Candidate consent dates and data-retention dates are excluded. Ashby says retention dates can be added later through CSV import, so include them in the migration plan if the team relies on them.
Existing offers, offer data and offer letters are included, but offer-letter templates are not. Email templates are imported in an archived state because Ashby does not replace Greenhouse placeholder tokens. Review the content, update the tokens and restore only the templates the team should keep using.
Prospect-related data also needs attention. Ashby says prospect data is not mapped. A person with only a Greenhouse prospect application becomes an Ashby Lead without a job consideration. Build a report of prospect-only records before migration so sourcing teams know how those people will appear.
Check Greenhouse API permissions before blaming the migration
Private data can look like missing data when the Greenhouse API user lacks permission. Greenhouse documents advanced permissions for private offers, salary data, private notes and private fields. Without the correct access, some list endpoints can return empty results even though recruiters can see the records in the Greenhouse interface.
Before the first sync, test the API credentials against a known private offer, a private note and a custom field. Record the result. This avoids discovering after cutover that the migration user never had access to a whole class of records.
Understand candidates, applications and prospects
Greenhouse separates the person from their applications. A candidate can have one or more applications. A candidate application belongs to one job, while a prospect application can have no job or several possible jobs. Ashby calls the application relationship a job consideration.
Validate people with several applications carefully. Check that each job consideration has the correct stage, status, source and history. For prospect-only people, confirm that the Ashby Lead state is useful for the sourcing team's workflow. If downstream reporting expects every Greenhouse application ID, preserve those IDs in an external crosswalk.
Interview history is more than an activity feed
Greenhouse notes and activity feeds can include user notes, logged emails, system activity, interview feedback, LinkedIn messages and touchpoints. Structured scorecards have their own API resources. Do not treat one activity-feed entry as a substitute for the complete scorecard.
Ashby lists scheduled interviews and scorecards as migrated data. Test both. Pick candidates with completed interview loops and compare the schedule, interviewers, scorecard sections, submitted feedback and dates. Also check interviews that were cancelled or rescheduled.
Offers, files and attachments
Ashby lists resumes and offer letters, but its public migration guide does not promise every attachment type. Greenhouse Harvest V3 associates attachments with applications rather than treating the candidate record as the only source. Build an attachment inventory that separates resumes, cover letters, take-home work, offer documents and other uploads.
For each attachment category, decide whether the API migration covers it, whether it needs a separate export or whether it should remain in the Greenhouse archive. Validate the physical document, not only a metadata row.
Keep an ID crosswalk
Greenhouse resources have IDs, but Ashby's public migration guide does not promise that those values become Ashby IDs or publish a complete crosswalk. Create your own table with Greenhouse object type, Greenhouse ID, Ashby object type, Ashby ID and migration status.
This table matters when the ATS connects to a warehouse, assessment tool, sourcing system, onboarding product or internal application. Any integration that stored Greenhouse candidate, job or application IDs needs a new reference after cutover.
Validate the migration in layers
- Counts. Compare active and archived jobs, openings, candidates, applications, interviews, scorecards, offers and notes.
- Exceptions. List prospect-only people, excluded consent and retention dates, templates and attachment categories.
- Representative records. Check candidates with several jobs, private notes, rejected applications, offers and long interview histories.
- Permissions. Confirm users see only the data their new Ashby role allows.
- Integrations. Update systems that store Greenhouse IDs and test write-backs or webhooks.
- Delta state. Check Ashby's last successful sync and reconcile records changed close to cutover.
- User review. Ask recruiters and coordinators to inspect records they know before Greenhouse becomes read-only.
Greenhouse Harvest V3 list endpoints use cursor pagination. The next-page URL in the response should be followed as supplied. Greenhouse also documents rate-limit responses with a retry instruction. If you run an independent audit export, handle pagination and retries so a partial extract does not look complete.
Mistakes we see
- Assuming Greenhouse permissions will appear automatically in Ashby.
- Missing private offers and notes because the API user lacks advanced access.
- Editing migrated records while the hourly sync can still overwrite them.
- Forgetting prospect-only candidates and sourcing workflows.
- Using an activity feed as proof that full scorecards moved.
- Checking resume counts but ignoring other attachment types.
- Leaving email templates archived without replacing placeholder tokens.
- Cutting over without an ID crosswalk for connected systems.
How Remqa runs Greenhouse to Ashby migrations
Remqa sets up the source audit, documents exclusions, checks API permissions and builds a Greenhouse-to-Ashby crosswalk before cutover. We validate candidates, job considerations, interviews, feedback, offers, notes, templates and files, then update connected systems and keep Greenhouse read-only until the recruiting team signs off. See our ATS migration process, the broader ATS migration checklist and our data migration work.