If you don’t have a data-driven HR process today, you will in the future. According to Josh Bersin, “your ability to harness and understand the data about your people is becoming core to HR’s mission” (check out his blog post here: The Bold New World of Talent: Predictions for 2016). With that in mind, it’s no wonder that most leaders I encounter tell me that they are looking to make a shift to a new ATS that will streamline recruiter process and improve data capture for the future. However, even the ATS that’s underperforming today contains invaluable data that must be carried over to any new system. In a typical data migration, vital parts of this historical data get left behind. This makes the data unusable or only partially available to future analytics programs, and often limits companies to using data gathered only after the new system was implemented for complex metrics.

Still unsure about the importance of a comprehensive data migration plan? These three examples are just a few of the many illustrative representations of important data points that are lost with many standard data migration plans.

Insight # 1:  The Value of Progressive Candidate Statuses

When you close a requisition, for compliance reasons, all candidates are moved to a final status, including those candidates who were in play at the final stage.

For example, for the final stages of a hypothetical Financial Analyst Req, 240 candidates get whittled down to 3. Bobby, Pat and Sam all make it to a final round and are in the ‘In Person Interview’ status. Pat gets the offer, so Pat’s final status is captured and retained as ‘Hired’. But, Bobby and Sam are then rejected and are left with a ‘Rejected – Not Most Qualified’ status.

In a standard data migration, Bobby’s and Sam’s statuses are recorded in the same status bucket as many of the 240 rejected candidates who never made it to a 1st round interview. In a data science-oriented migration, Bobby’s and Sam’s progressive status assignments (for example: ‘New / Sent to Hiring Manager / Phone Screen / First Round Interview / Rejected – Not Most Qualified’) would be migrated. In future data analyses, this provides a much more complete picture of candidate histories, allowing your recruiting team to differentiate between those candidates who were not top prospects and those who should be contenders for future requisitions. Additionally, not retaining this complete lifecycle of status data would prevent future comparative breakdowns of the time-to-fill process and data learnings from ‘silver’ and ‘bronze’ medalist candidates.

Insight # 2:  The Importance of All Req Statuses Throughout a Req Lifecycle

When a candidate is hired into an open requisition, the req is then marked as ‘Closed’ (or equivalent status). If anything happens to the req between ‘Open’ and ‘Closed’ status, this data is typically lost – much like progressive candidate statuses between New Candidate and Rejected, in the previous point.

For example, consider a company going through a restructuring. During this time (let’s say, on January 1), a Sr. Software Developer req opens and a great candidate is selected 60 days in. Due to the restructuring, your recruiter must put the req on hold and spend the next 45 days standing on their head trying to keep the candidate warm, checking in, letting them know your organization is still eager to hire them, and monitoring budget approvals. Finally, the req is reopened and your incredible recruiter has achieved the impossible and the first choice candidate accepts the offer 5 days later. The req receives a ‘Closed’ status on April 20.

In an ideal ATS migration, your ATS data would include all req statuses, with their respective dates of assignment: in this example ‘Open / On Hold / Open / Closed’.  In a standard migration, only the first and final req statuses would be carried over. Thus, your time-to-fill calculation for this req would be heavily distorted as 110 days, instead of 65 days. For the skilled high volume recruiter who manages client teams and weathers multiple restructurings or budget fluctuations each year, these are important data points to be able to maintain for future baseline calculations and accurate recruiter-specific metrics

Insight # 3:  The Resume in the Original Format Should Not Be Left Behind

With a typical data migration, only parsed versions or certain fields of a candidate’s resume are maintained.

Given known ATS parsing errors and only partial data transfer from this comprehensive candidate history data, your recruiting team will only have access to a limited amount of candidate data, meaning the ability to target or prospect past applicants (one of their richest data sources) will be greatly diminished. Additionally, parsing errors or incomplete data might lead to inaccurate analysis of what Hired candidates did or did not posses vis-a-vis the req requirements. As any recruiter on your team will tell you, they are able to read a resume and make sense of unusual formatting far better than any ATS parser. Furthermore, an ATS parser lacks the human ability to understand natural language and thus will only retain aspects it thinks to be relevant without any checks and balances.

From working with Fortune 500 companies across numerous industries, we’ve found most ATS transitions are completed by consultants and project managers that rarely include a Data Science or Machine Learning Expert who can advise on critical aspects of data handling for future data science endeavors. With this in mind, at HiredScore, we’ve created a Data Science Survival Guide to ATS Migrations Workshop for those considering or in the process of moving to a new ATS. The workshop covers these and numerous other relevant topics, including our Data Scientist Migration Checklist, which we’d be happy to share with you and your team. Please email me at lauren@hiredscore.com to learn more.