Product | Gem ATS |
Expert(s) | Gem ATS team |
Slack channel | #gem-ats-general |
This article was last verified on | 05/09/2024 |
🔍 Articles in This Section
Please use the following list to see additional internal articles regarding Gem ATS migration:
- (Internal) Gem ATS: Migration Guidance
- (Internal) Gem ATS: Migration from Greenhouse/Lever (CSM version) (📍you are here)
- (Internal) Gem ATS: Migration from Greenhouse/Lever (TSE version)
đź“– Customer-facing Resources
- none
Context/ Talk track
- instead of “1 click migration” → “turn key migration”
- our ATS migration for Greenhouse and Lever is less than 24 hours & is extremely thorough & deep in terms of migrating data fields
- since we already have deep sync integrations built for Greenhouse and Lever, we are already mapping & syncing all of your ATS data so there will be virtually no loss of data - esp when it comes to reporting. We’ll be able to marry your GH/Lever’s data with Gem’s ATS data seamlessly in Talent Compass & Talent Pipeline.
Timeline
Ideally, we’d know a customer wants to migrate 1-2 weeks before the migration happens:
Date | Action | Team/Owner | Files |
|---|---|---|---|
Customer tells CSM they want to migrate to Gem ATS. Already have Deep sync & stage mappings? Skip to Part 2 | |||
Pull customer ATS data into Gem | |||
1. Make sure they have “Greenhouse” or “Lever” set as their ATS in the support dash. | Gem Customer Success | ||
1. Enable deep sync: • create & plugin in the Harvest API key with the right permission set • configure webhooks in Greenhouse for Gem | Gem Customer Success | ||
1. Go to support dash: • click on Greenhouse tab • click “Start Resync for OATS Migration” | Gem Customer Success | ||
1. Set up pipeline stage mapping • Map as many stages as possible, since unmapped stages will need to be reviewed by ENG later on and prolong time to completion since they’ll need to go back-and-forth with the customer to determine where unmapped stage data should go | Gem Customer Success + Customer | ||
Move ATS data into Gem ATS | |||
1. Create a stage mapping configuration using the customer’s pipeline stage mapping data | Gem Eng | ||
1. We provide the mapping configuration to the customer and verify that things look correct. • Here is a list of objects/fields that we can migrate - + GH → Gem ATS Migrated Objects | Gem Eng + Gem Customer Success | https://paper.dropboxstatic.com/static/img/ace/emoji/1f6a7.png?version=8.0.0 | |
1. If the customer wishes, ENG can upload their data to a Sandbox instance to give them an opportunity to preview what things will look like. 2. The Sandbox instance will be a throwaway instance (changes they make there will not get pushed into their production Gem instance) later on 3. The Sandbox instance is “live”, as in scheduling interviews and emailing candidates will result in actual outreach being sent. 4. It’s best to use the Sandbox for data validation, not for interactions with candidates or to save any other data on it | Gem Eng + Gem Customer Success | ||
1. Arrange a cutover date with the customer where they will stop using GH completely. On this date, we’ll move their GH data into their Gem production instance. 2. ENG estimates that for most SMB and lower MM customers, this can be done overnight. For larger MM customers, we should aim for the weekend to give ample time to tackle any technical issues that arise. 3. ENG will update the production instance’s ATS setting from “Greenhouse” to “oats” | Gem Eng + Gem Customer Success | ||
1. Post-migration tasks: 2. Publish job posts (these will be unpublished by default) 3. Invite new users to Gem 4. Update their career site to point to the Gem ATS job board A daily incremental migration will move any new GH apps into Gem ATS until all GH job posts are taken down. • The customer should close GH jobs and job posts once Gem ATS job posts have been set up. • We’ll work with customer to determine when this stops. | Gem Eng + Gem Customer Success | ||
SMB or not that much ATS data? we can do the migration overnight MM or has a lot of ATS data, we may recommend doing the migration over the weekend |
What data do we migrate over?
+ GH → Gem ATS Migrated Objects

tl;dr — we migrate over all of the major items like:
- users
- departments
- offices
- sources
- rejection reasons
- jobs/job stages/job posts, interview plans
- scorecard questions
- candidates (including Prospects)
- candidate notes
What don’t we migrate over? Any gotcha’s?
There may be fields we do not support today, but will still pull into Gem as part of the migration. That way, we have the data and can build support as a fast-follow afterwards.
For example,
- EEOC / Demographic data
- Referrals
- CS can hit the “Start Resync for OATS Migration” button as many times as they want, and it is suggested to perform it (usually takes ~1hr for most teams) right before passing the task on to ENG so we can be certain everything is as up to date as possible.
What do I do if the customer notices any data discrepancies post-migration(andit was previously Greenhouse data)?
- file a bug
- Context/ Talk track
- Timeline
- What data do we migrate over?
- What don’t we migrate over? Any gotcha’s?
- What do I do if the customer notices any data discrepancies post-migration(andit was previously Greenhouse data)?