(Internal) Gem ATS: Migration from Greenhouse/Lever (TSE version)

🔍 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)
• (Internal) Gem ATS: Migration from Greenhouse/Lever (TSE version) (📍you are here)

📖 Customer-facing Resources

• none

The majority of the migration process will be handled by Eng. CS will act as a bridge between the customer and ENG.

TSEs have little to no involvement with the migration process, other than forwarding migration requests and questions to CS for handling. TSEs will continue to take point on bugs and report them to ENG (see additional notes at bottom of doc).

For Greenhouse, ATS data migration takes place in two parts. Lever will share a similar flow (instructions to come).

Greenhouse

Part 1 - Pull their GH data into Gem

This is accomplished by setting up deep sync, if not done already as an existing customer.

1. CS - Keep the team’s ATS on “Greenhouse”. If they’re a new customer with no ATS set, make it “Greenhouse”.
2. CS - Go through the process of setting up deep sync, which entails:
1. Creating and plugging in the Harvest API key with the right permissions set
2. Configuring webhooks in Greenhouse for Gem
3. CS - Go to the Support dashboard, look under the Greenhouse Info tab, then click “Start Resync for OATS Migration”.
4. CS + Customer - Set up pipeline stage mapping.
1. Note: 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.

Part 2 - Moving the data into Gem ATS.

1. ENG - Create a stage mapping configuration using the customer’s pipeline stage mapping data.
2. ENG + CS - We provide the mapping configuration to the customer and verify that things look correct.
1. Here is a list of objects/fields that we can migrate - https://paper.dropbox.com/doc/GH-Gem-ATS-Migrated-Objects--CIg674Zd8DxKg5F6~Qi_B8D2Ag-Y20FFtdPG46UAm6dmvAVf
3. Optional - 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.
1. The Sandbox instance will be a throwaway instance (changes they make there will not get pushed into their production Gem instance) later on
2. The Sandbox instance is “live”, as in scheduling interviews and emailing candidates will result in actual outreach being sent.
3. It’s best to use the Sandbox for data validation, not for interactions with candidates or to save any other data on it
4. CS + ENG - 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.
1. 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.
2. ENG will update the production instance’s ATS setting from “Greenhouse” to “oats”
5. CS + Customer - Post-migration tasks:
1. Publish job posts (these will be unpublished by default)
2. Invite new users to Gem
3. Update their career site to point to the Gem ATS job board

Additional notes:

• 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.
• 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.
• If the customer notices any data discrepancies post-migration (and it was previously Greenhouse data), file a bug.

• Greenhouse
• Part 1 - Pull their GH data into Gem
• Additional notes: