An ATS that fit at go-live often slips by year three, and teams assume the only fix is another painful replacement. It isn't. The right system, and the right partner, evolve with you.
Here's a pattern I've watched play out more times than I can count. An organization picks an ATS, runs a careful evaluation, configures it well, and goes live to genuine relief.
For a while, it fits. Then somewhere around year three, the same team that championed the system is quietly working around it, with feedback drifting back into email, a spreadsheet reappearing, and a new hiring team building its own process off to the side.
Nobody decided to abandon the system. It stopped fitting a little at a time, until one day someone finally said out loud what everyone had already felt: this isn't working for us anymore.
The conclusion they usually reach is that it's time to start the whole search over, picking a new system, running another implementation, and bracing for a painful switch, all while quietly accepting that in three more years they'll be doing it again.
The decay is treated as the natural life cycle of any ATS, on the assumption that you buy, outgrow, and replace. None of that is inevitable, though. That decay is a choice made at the point of purchase, and then quietly compounded over the years that follow.
It helps to start with why the fit slips in the first place.
When you buy an ATS, you're matching a system to two moving things at once: your organization and the market you hire in, and both keep moving for as long as you own it.
Your organization grows. It opens a new region or acquires a brand, and before long it's hiring a shape of worker it never took on at scale, a deskless frontline or a seasonal surge sitting alongside the corporate roles the system was built for.
I wrote about that multiplicity in the first piece in this series, where most organizations end up running several hiring processes at once, with the mix changing over time.
The candidate market shifts just as much, in what people expect from an application and how fast they expect to hear back, and the compliance bar and stakeholder expectations keep moving along with it.
So you're left with a system set up to fit a snapshot and a reality that refuses to hold still. Most systems get configured once, at go-live, and then left there while the organization carries on changing around them.
The gap between the two opens slowly, and by year three it is roughly wide enough to feel.
This connects to something I argued earlier in the series, in the piece on why clean, comprehensive data beats clever models. Adoption is a living thing rather than a one-time state you reach at launch and keep, and it rises and falls with how well the system fits the work in front of people right now.
While the system fits, people use it, and the moment it falls behind the organization, they start routing around it.
The new hiring team, it doesn't quite serve, builds its own workaround; the manager whose process changed slips back to email, and every one of those workarounds punches a hole in the record.
The clean, comprehensive picture you leaned on for reporting, and for the automation and AI you'd layered on top, starts to degrade, because half the story is happening outside the system again.
So the drift is more than cosmetic. A system that's slipped out of fit does more than annoy people, because it quietly stops being the place the truth lives, and everything you built on top of that truth gets shakier for it.
The slide back to workarounds and the erosion of your data are one and the same thing, just noticed at different moments.
The more useful question is what a system needs to keep moving with the organization and the market, rather than being left behind by them.
The answer is the same three things that decide whether a system gets adopted on day one, carried along the time axis.
A system with those properties evolves as you evolve. When a new shape of hiring arrives, you absorb it into what you already have instead of standing up a parallel tool or kicking off a fresh search, and the fit is restored from the inside while you keep running.
That's the alternative to the year-three replacement cycle, and it's there for the taking, though only if you bought for it.
One more part matters here, and it never shows up in a feature comparison.
A system that can evolve still has to be evolved by someone. That means keeping the configuration current as the organization changes, and reshaping the setup when your hiring itself shifts shape. It also means pointing out the new capability that solves a problem you've only just started to hit.
It's real, ongoing work, and it's the part of the relationship that tends to go quiet at most vendors the moment the implementation is signed off.
But it shouldn't go quiet at all. The vendor's job doesn't end at go-live: the product team has to keep shipping things worth adopting, and the customer success team has to keep helping you adopt them and evolve your setup as you change.
That, to me, is what the "service" in Software as a Service was always supposed to mean. Rather than a help desk you call when something breaks, it's a partner whose job is to keep the system fitting as your world moves.
It's why the culture and posture of the partner you choose matter at least as much as the features they can demo today. The features will change and so will the market, so what you're really betting on is whether the organization behind the software will keep working to keep it fitting you, year after year, long after the original buyer has moved on.
At Pinpoint, we think about this constantly, for the obvious reason that it's the job. We ship around a dozen product releases a year, so the product a customer adopted keeps growing underneath them, and our customers tend to describe the relationship in terms that have nothing to do with a feature list.
Aspire Allergy calls us a partner they're excited to build with for the long term, River Island talks about growing with the system rather than out of it, and LOCALiQ describes the experience as staying ahead of the curve.
None of that describes a product that was perfect on day one. It describes a system and the team behind it that kept fitting as those organizations changed.
The Josh Bersin Company makes a related point from the other direction, arguing that organizations should review their HR technology regularly, as an ongoing discipline that treats the stack as something you keep tending rather than set and forget.
That's the same instinct from the buyer's side of the table. Evolution is an ongoing practice rather than a one-off event, and the real difference is whether your system and your vendor are built to make that practice easy or to turn it into a fight.
So if you're two or three years into a system that's started to slip, I'd push back on the instinct to treat another full replacement as the only fix.
Before you start the search, ask the more useful questions: whether the system you have can bend to where the organization is now or is stuck at the snapshot you configured at go-live, whether your team can drive that change or is left waiting on someone else, and whether anyone on the vendor's side has keeping it current as their job.
If the honest answers come back no, the features were never the real problem.
The system, and the relationship behind it, weren't built to evolve, and that's what to fix in the next decision, something that runs deeper than the logo on the login screen.
A hiring system is a relationship more than a thing you install once and own, something that has to keep pace with you while everything around you moves.
Choose for the decade, not the demo.
Tom is the CEO at Pinpoint, he's passionate about building world-class teams and world-class products for organizations around the world.
