How to evaluate and switch your ATS in 90 days

1. Do you actually need to switch?

Replacing an ATS costs more than the licence difference. It costs recruiter hours, a migration, retraining, and a period where two systems are half-true. Before starting, check whether the problem is the platform or the configuration.

These usually mean the platform:

• A configuration change requires the vendor, or IT, or a paid services engagement.
• Data lives somewhere your compliance obligations do not allow.
• Candidates abandon the application form at a rate you can measure and cannot fix.
• Recruiting and onboarding are separate systems with a manual handoff between them.
• Reporting requires exporting to a spreadsheet before anyone can answer a question.

These usually mean the configuration, and switching will not fix them:

• Hiring managers do not respond in the system — that is a process and accountability problem.
• Job descriptions are poor — no platform fixes writing.
• Nobody trusts the data because nobody has agreed what a stage means.

2. Document what you have

This is the step teams skip, and skipping it is the single most common cause of a bad implementation. Before you talk to any vendor, write down:

• Every requisition type you post, and how its approval path differs.
• Every stage a candidate can be in, and who moves them.
• Every mandatory pre-start item — checks, credentials, documents — and who verifies each.
• Every integration that currently works, including the ones nobody thinks about: job boards, HRIS, payroll, background screening, assessments, calendars.
• Every report someone actually reads, and who reads it.
• Any obligation that constrains the process — collective agreements, internal-first posting rules, regulated professions, data residency.

If it takes more than a day, that is the finding: your process is more complex than a demo will reveal, and any vendor who does not ask about this material is not going to configure it.

3. The RFP question set

Most RFP templates ask what a platform does. The useful questions ask what happens when something changes or goes wrong. Ask these in writing.

Configuration and control

• Which changes can our administrators make without contacting you? Name the ones they cannot.
• Is a new requisition type, approval chain or stage a configuration change or a services engagement?
• What is the turnaround and cost for a change we cannot make ourselves?

Data

• Where is our data physically stored, and where is it backed up? Name the region.
• Which subprocessors touch it, and in which countries?
• If we leave, what exactly do we get back, in what format, and how long does it take?
• What happens to candidate records at the end of a retention period, and can we set it?

Implementation

• Who does the configuration — your team, ours, or a partner?
• What does migration include, and what is explicitly excluded?
• Can we run in parallel before cutover? For how long?
• What is the named escalation path during implementation, and after?

Commercials

• What is not included in the quoted price? List every module, integration and support tier priced separately.
• Are there per-hire, per-application or per-seat surcharges?
• What does renewal look like, and what is the cap on an increase?

Evidence

• Give us a reference customer of our size, in our sector, who switched from our current platform.
• Tell us about an implementation that went badly and what changed as a result.

4. A vendor scorecard

Score each vendor 1–5 against the criteria below, weight them for your own situation, and do it before the final presentations rather than after. Demos reward showmanship; a scorecard filled in early resists it.

• Fit to documented process — how much of section 2 does it handle without custom work?
• Self-service configuration — how much can your team change unaided?
• Compliance and data residency — does it satisfy your obligations, evidenced rather than asserted?
• Candidate experience — complete an application on a phone yourself, timed, before scoring this.
• Integration coverage — against your real list, not the vendor's logo wall.
• Reporting — can a non-technical person answer a new question without an export?
• Implementation credibility — named people, a real plan, a parallel run.
• Support model — who answers, how fast, and is it a queue or a person?
• Total cost over three years — including every separately priced item you uncovered.
• Exit — how hard is it to leave?

Weight fit to documented process and self-service configuration highest. Those two predict satisfaction two years out better than anything else on the list.

5. Working out what it is worth

Build the business case from numbers you already have, not vendor averages. The three that usually matter:

• Recruiter time. Hours per week lost to work the system should do — scheduling, chasing, re-keying — times loaded hourly cost, times 52.
• Cost of a vacancy. Days-to-fill multiplied by whatever a day open costs in your setting. In clinical and operational roles this is usually the largest number and the one nobody calculates.
• Early attrition. First-year turnover multiplied by replacement cost. Structured onboarding moves this; a better job board integration does not.

Then subtract the honest costs: licence difference, implementation, and the productivity dip during cutover. If it only works with the vendor's numbers, it does not work.

Our ROI calculator models the first and third of these if you want a starting point, but your own payroll data beats any estimate.

6. The 90-day sequence

Ninety days is realistic for a mid-size implementation if the sequence holds.

Days 1–30 — decide and prepare

• Finish the documentation from section 2 if it is not already done.
• Score, shortlist, check references properly, sign.
• Agree the migration scope in writing: what moves, what does not, what gets archived.

Days 31–60 — configure and migrate

• Configure against the documented process, not a template.
• Migrate a sample first, check it, then migrate the rest.
• Train administrators before end users, so questions have somewhere to go.

Days 61–90 — parallel, then cut over

• Run both systems on live requisitions briefly. Expect to find two or three things the documentation missed — that is what this phase is for.
• Cut over on a low-volume week, never during a seasonal peak.
• Keep read access to the old system well past go-live.

7. How this goes wrong

• Buying from a demo. Demos run on clean data and a happy path. Ask to see your own awkward requisition instead.
• No named owner. Implementations without one person accountable drift by weeks at a time.
• Migrating everything. Ten years of dead candidate records is not an asset. Agree what is worth moving.
• Cutting over at a peak. The pressure that makes a new system attractive is the worst moment to switch to it.
• Skipping the parallel run to save two weeks, then spending six fixing configuration in production.
• Treating it as an IT project. The people who know the process are in HR. If they are not driving, the configuration will be wrong.