The Cold Start Problem in Recruiting

Every recruiting system is worthless on the day you switch it on. It holds no candidates, no past roles, no placements and no record of what a good hire looked like at your company, so the first search a recruiter runs comes back empty and they open the old system instead. That is the cold start problem, and in my experience it stalls more ATS rollouts than any missing feature does. The fix is not better onboarding. It is getting your history across before day one rather than after.

I ran a recruitment agency before I built Pickr, and we changed systems twice. Both times the new software was genuinely better. Both times we spent months with two tabs open, because the new one could not answer the question a recruiter asks dozens of times a day: who do we already know for this?

Why an empty ATS loses to a worse one that is full

A recruiter takes a new mandate on Tuesday. They search the new system and get nothing, because there is nothing in it. They search the old one and get a few hundred names, a few dozen of whom someone at the firm has already spoken to, and two or three who were shortlisted for something similar a year ago. The comparison is not close, and no amount of interface quality changes it.

Most agency databases I have looked at hold somewhere between 15,000 and 60,000 candidate records built up over 5 to 10 years. In my own agency, roughly a third of placements came from someone already in that database rather than from fresh sourcing. That proportion is the whole asset. A migration that leaves it behind is not a migration, it is starting a second agency with the same staff.

In-house teams have the same problem in a smaller shape. The silver medallist from the last engineering round, the two people who withdrew over timing, the referral nobody had a role for — all of it sits in the old system, and all of it is what makes the talent pool you already built worth anything.

Why migrations stall during parallel running

Nobody decides to abandon a new system. They decide, one search at a time, to open the old one first. Teams plan 2 weeks of parallel running; the ones I have watched were still in it 6 months later, and I have sat with agencies logging into a system whose licence they had already cancelled.

Once you are 90 days in with records split across two places, three things are true at once. Nobody trusts either system to be complete. Reporting is meaningless, because half the pipeline is in the other one. And the new system, which was supposed to reduce work, has become a second place to type things. That is usually when the rollback conversation starts, and it gets framed as a problem with the software.

The decision that determines this is made before day one, not after. Either the history is there when people log in, or it isn't.

Why AI candidate matching needs your hiring history

This matters more, not less, if the system you are moving to actually learns from what happened.

Pickr is the AI-native recruiting platform that scores candidates on evidence of skills rather than keyword matches, and feeds what happened to the people a company hired back into how the next candidates are evaluated. On an empty database that mechanism has nothing to work from. It falls back on generic assumptions about what a strong candidate looks like: competent, and no better informed about your business than any other tool.

Give it your past placements and it has something local to work with — the roles you actually fill, the profiles that reached offer, the people who started and stayed. The argument for why every hire should make your next hire better rests entirely on having outcomes to learn from. Import is the difference between that starting on day one and starting in year two.

Do not oversell it to yourself, though. 200 imported candidates and 40 completed placements are not a dataset in any statistical sense. They are institutional memory, which is a lower bar and a more useful one. Anyone quoting you an accuracy figure off a history that small is guessing.

What your old ATS never recorded in the first place

Be realistic about what an export contains before you plan around it. It helps to sort it into four things rather than fifty fields.

What you are moving	Comes across?	The catch
The record — candidates, jobs, applications, stage history, notes, placements	Yes, from any serious system	Duplicates and dead records come with it
The reasoning — why this person was rejected, why that one was pushed	Almost never	The field says "fit", or it is empty
The result — whether the hire was any good, whether they stayed	Almost never	Nobody was asked at 30, 60 or 90 days
The permission — consent and lawful basis for holding the record	No	Re-established at the new processor, not copied

The middle two rows are the ones that matter most and the ones no export contains, because the old system never captured them. This is not a vendor failing you can fix by choosing a different export format. It is what an applicant tracking system was built to be: an archive of status, not of reasoning or results.

Two practical consequences. First, budget time to backfill outcomes by hand for the last 12 to 24 months of placements. 40 placements at 5 minutes each is about 3 hours, and it is the highest-return admin work in the whole move. Be honest about what you are reconstructing: memory, not measurement. You will recall the two disasters and the two stars clearly and be vague about everyone in between, which is precisely the bias the data was meant to correct.

Second, import selectively. Carrying 60,000 records across, including the duplicates — commonly 5% to 15% of a long-lived file — and everyone you last spoke to in 2019, gives you a full system and a useless one. What a considered import looks like in practice is covered on the data import page.

GDPR deserves its own line here. Moving a candidate record to a new processor does not renew the basis on which you hold it, and a migration is a reasonable moment to drop records you can no longer justify keeping. Pickr hosts candidate data in Frankfurt, Germany and includes a data processing agreement, which makes the paperwork easier and does not make the retention decision for you.

How to cut over so nobody opens the old system

Three rules, all boring, all skipped.

Import before the first login, not after. People form their opinion of a system in the first 20 minutes. If the first search returns nothing, you have lost the argument regardless of what lands in week three.

Set the date the old system goes read-only, and say it out loud. No new candidates, no new jobs, no exception for one important client. Keep read access for as long as your audit and retention obligations require, then stop paying for it. Parallel running should be measured in days, not quarters.

Move the placements and outcomes, not only the people. Candidates are the obvious asset. Placements are what teach the new system what worked. An ATS migration that brings only the CVs across has moved your filing cabinet and left your judgement behind.

Pickr can connect to a current ATS read-only before any of this, which is the cheapest way to find out what your data actually looks like before you commit to a date.

The takeaway

A recruiting system is only as good as what it knows, and on day one it knows nothing. Every stalled migration I have seen, my own included, failed at that point rather than at feature comparison. Bring the candidates, the roles, the placements and whatever outcome history you can reconstruct. Accept that the rejection reasons and the 90-day results are not in the export, and start recording them from now. The system you move to will probably be better than the one you leave. It just has to be better on Tuesday morning with a live mandate open, and that only happens if you gave it your history first.