ATS Implementation: What Actually Happens After You Sign

The contract is signed, the kickoff call is booked, and somewhere in the next six weeks your team will decide whether this platform is the one they use or the one they work around. That decision gets made during implementation, and most firms are barely present for it.

Vendors quote implementation as a timeline. It is better understood as a division of labour, because the parts nobody assigned are the parts that do not happen.

This post covers ATS implementation: what the project actually contains, who owns which piece, a realistic timeline, the failure patterns worth avoiding, and a checklist you can hold a vendor to.

What implementation actually covers

Most buyers hear implementation and picture data moving. That is one workstream out of three.

Data migration is one part, not the whole project

Getting records across is the visible half. The half that decides whether the system is useful is what comes with them: notes, call logs, attachments, the context that makes a ten-year-old record worth having. Treat switching without losing candidate history as its own scoped piece of work with its own acceptance test.

Configuration is where the time goes

Pipelines, stages, custom fields, permissions, email templates, automation rules. This is the work that makes the platform match how your firm actually operates, and it is almost always underestimated because it looks like settings rather than a project.

Training is not adoption

Training is an event. Adoption is a behaviour that either survives the fourth week or does not. Vendors deliver the first and measure the second only if you ask them to.

Who does what, and what quietly becomes your job

This is the single most useful conversation to have before kickoff, and it is rarely on the agenda.

What the vendor typically owns

Extraction and load, field mapping into their schema, platform configuration to an agreed specification, training sessions, and a support channel during go-live.

What tends to land on you

Deciding the specification in the first place. Cleaning data before it moves. Signing off field mappings. Defining your pipeline stages. Building or approving the automation rules. Chasing your own team to log in.

None of that is unreasonable. It becomes a problem when it is discovered in week three by a billing consultant who thought they had bought a done-for-you service.

The question that settles it

Ask for the implementation plan as a table with two columns: vendor responsibility and firm responsibility, line by line. A vendor with a mature process produces it immediately. A vendor without one produces a Gantt chart with no names on it.

A realistic timeline

Implementation length varies with data volume and configuration complexity rather than with the size of your team, which is why headcount is a poor predictor.

Weeks one and two

Kickoff, specification, data extract from the incumbent system, and a first mapping pass. The single highest-value activity here is data cleaning, because everything you migrate you will maintain.

Weeks three to six

Configuration, a test migration you actually inspect, automation build, integrations, and training. Insist on reviewing a sample of migrated records yourself rather than accepting a completion report.

The first ninety days

Go-live is the start of the project, not the end. Adoption is decided here, and a platform your team works around costs more than one that costs more per seat. Against a $168,000 annual revenue gap per recruiter between top-quartile firms and everyone else (Source: The Economics of Recruiting), the difference between a system that gets used and one that gets tolerated dwarfs any licence saving.

What makes implementations fail

No named owner on your side

Vendors cannot make decisions about your pipeline stages. If nobody internally owns the specification, the vendor will default to their standard template and your team will inherit a process nobody chose.

Rebuilding the old process in the new system

The most common and most expensive failure. Firms migrate their existing workflow faithfully, including the workarounds that existed because the old platform could not do something. Audit the process before you rebuild it.

Going live with no adoption measure

Decide in advance what you will look at in week four: logins, records updated, activities logged, whatever matches how your desk works. Without a number, adoption is a matter of opinion and nobody fixes it.

Guy Last Recruitment is a useful counter-example. After moving from Bullhorn to Recruiterflow, the firm built workflows around specific pain points rather than porting the old setup, and grew job orders by 142% while productivity per recruiter rose 41%. The team grew tenfold over the same period, which is the harder trick, because scaling headcount usually dilutes output per head.

An ATS implementation checklist

Work through these before kickoff rather than during it.

1. Who owns the specification internally, by name, with time allocated.
2. What data is in scope, and what is being deliberately left behind.
3. Who cleans the data, and to what standard, before extraction.
4. What the acceptance test is for the migration, and who runs it.
5. Which pipeline stages and custom fields you are committing to, before configuration starts.
6. Which integrations must work on day one versus which can follow.
7. What training covers, who attends, and what happens for people who join later.
8. What adoption metric you will review in week four.
9. Who your named contact is after go-live, and for how long.
10. What the escalation path is when something breaks in week two.

FAQs

How long does ATS implementation take?

It depends on data volume and configuration complexity rather than team size, and the ranges vendors quote assume you return specifications and sign-offs promptly. Ask what the timeline assumes about your side, because that is usually where it slips.

What does ATS implementation cost?

Most vendors quote it separately from the licence and few publish it. Ask what the fee covers, what it excludes, and whether further configuration after go-live is chargeable.

What is included in an ATS implementation checklist?

Ownership, data scope, cleaning standards, migration acceptance testing, configuration decisions, integrations, training, an adoption measure and an escalation path. The list above covers each in the order they become urgent.

Who should own ATS implementation inside a recruitment firm?

Someone with authority to decide process, not only someone with time. Delegating it purely to an operations coordinator without decision rights is a common cause of drift.

Can you implement an ATS without IT support?

Usually yes for the core platform, though single sign-on, email and calendar sync and back-office integrations often need someone technical for a short window. Identify that person before kickoff rather than during it.

What happens if implementation goes badly?

Establish before signing what remedy exists: extended support, additional configuration at no cost, or a defined escalation. A vendor unwilling to put anything in writing is telling you how the recovery would go.

Implementation is the product

The demo shows you what the platform can do. Implementation decides what your firm will actually do with it, and the gap between those two things is where most disappointed buyers end up.

Settle the division of labour before kickoff, name an owner, and decide your week-four number now. If you are still comparing platforms, our guide to evaluating an AI-native platform covers the wider decision, and it is worth reading why firms stay with Bullhorn too long before assuming a rebuild is riskier than staying put.

Bring your implementation plan to a demo and we will tell you which parts we own.