6 mins, 16 secs read time
There are many reasons a company might be considering transitioning to a new applicant tracking system (ATS). Whether you’re a growing startup looking for a robust feature suite, an enterprise company trying to improve reporting and enforce a data-oriented process, or an organization that simply wants to move its recruiting process out of spreadsheets, it’s clear that there can be huge long-term benefits to implementing a new ATS.
But with these real improvements to your organization’s recruiting process and strategy also come challenges. There is a huge amount of work that has to be done upfront: the purchasing process, learning and configuring a new ATS, training your team on the new system, and getting buy-in from the recruiting team and management. Between all of these complex processes, questions on what to do with historic recruiting data can get lost in the mix. But this data can be a valuable asset to your organization, and overlooking the data migration component of an implementation could result in data being brought over poorly, which could render it useless and affect buy-in from your recruiting team.
At Greenhouse, we know that a data migration is an inherently challenging process. No two applicant tracking systems are the same, and getting data from one system to translate to another can be difficult. That’s why we have a dedicated team of Data Migration Specialists to help customers with this process. As a member of that team, my goal is to take responsibility for transforming the data to work with Greenhouse while consulting with the customer to ensure the migration is done in a way that best reflects how the customer wants to use the data. This allows the customer to focus on their implementation and being effective at recruiting.
Because each organization has its own process, each data migration has its own idiosyncrasies that make it unique, even when the data source is the same. However, having completed hundreds of migrations for customers, our team has recognized some basic things that anyone can do to make sure their data migration will be successful. Most of it revolves around thinking ahead and asking some specific questions of your recruiting team, your previous ATS (if you have one), and the ATS you are migrating to. I’ve outlined a few of them here, and encourage anyone transitioning applicant tracking systems—or planning to transition—to ask these questions.
I’ve broken out these questions, covering: things you should ask your team, things you should ask your previous ATS, and things you should ask the ATS you’re migrating to.
Things you should ask your team:
What do you want to use the historic data for? Some organizations are required to keep historic data, but only need some basic information like the job they applied for and at what time. Others aggressively use historic data for prospecting, and want as much context as possible. Where your team falls on this spectrum will set the stage for how extensive you’ll want the migration to be.
What information is most important when looking back on historic candidates, or candidates who re-apply? Two examples of this we hear most commonly are comments/notes and workflow stages, but it’s definitely a good idea to flag anything else upfront.
Is there anything you specifically want to exclude? The gut reaction here is often “no”, but it’s worth considering whether there is specific data that was poorly maintained that would be better to leave out.
Is there confidential information to flag for the system you’re migrating to? Sometimes you don’t want everyone on your team to see everything, and it’s good to raise any concerns around private data upfront to see what can be done to ensure it stays private.
Things you should ask your previous ATS:
Do you charge for a data export? Some companies charge a fee to export your data, so it’s definitely good to find that out ahead of time so that there aren’t any surprises. The terms of your service agreement may also address the provision of data.
What data do you export? If there are specific pieces of information your team has flagged as important, it’s good to identify them here and make sure they can be provided. If certain data is unavailable by default, you may be able to work with them to run additional reports to get the information you want.
What format do you provide data in? Your new ATS rep will want to know this. If multiple formats are available, let them know any options you’ve been provided.
How long does it take to provide data? This will allow you to coordinate with your new ATS and team so everyone knows what to expect.
Things you should ask the ATS you’re migrating to:
How will migrated data affect the system? External data can sometimes behave in funny ways within a new system, so it’s helpful to know beforehand if there are any risks to migrating data.
Will migrated data skew reporting? Since different applicant tracking systems use different data structures, there may be limitations around reporting on migrated data in general, but it’s definitely a good idea to ensure that it won’t negatively impact reporting on your new ATS data. As a side note, you may wish to run a final set of important reports from your old ATS, in case you need to refer back to them down the line (e.g. EEO reports).
What deliverables will I be responsible for? Any successful data migration will be a collaborative process between your team and the ATS. You should expect to have some responsibilities or deliverables, but it’s best to clarify what those are beforehand.
Can you migrate _______ field? If there are specific pieces of information your team has flagged, it’s best to ask about those specifically.
Can you import with the format my old ATS said they’ll give me? Sometimes the default exports are provided in formats specific to certain databases that your new ATS may not have licenses for due to their cost. If this is the case, your new ATS should work with you and your previous ATS to get an alternative format that can be migrated.
At what time during the implementation do you migrate data? Is there a blackout period? Some applicant tracking systems may require you to stop working in both your previous and new system while they extract and migrate your old data. This is called a “blackout period.” At Greenhouse, we avoid blackout periods during migrations by starting the project towards the end of implementation, so the customer is able to start using Greenhouse to complete its hiring activities and stop using its old ATS (ensuring the dataset is complete). Both have different implications for your team’s workflow, so it’s important to ask when your ATS does the migration and why.
This may seem like a lot of questions for old data, but the more you know upfront, the easier it will be to set realistic expectations with your team and the greater likelihood of your data migration being successful. By spending some extra time looking back at your historic data, and being thoughtful about the process of bringing it into your new ATS, you will be able to leverage that valuable resource and build your team’s confidence in the new system, which will set your organization up to be effective going forward.
Thinking about buying new applicant tracking system? Check out the Buyer’s Guide to Applicant Tracking Systems for tips, tricks, and interactive worksheets to walk you through the process.