ATS & Technology
How to Survive an ATS Migration Without Losing Your Team
Lauren B. Jones
CEO & Founder, Leap Advisory Partners
Lauren B. Jones
The worst ATS migration I ever witnessed took 14 months. The original plan was four. The agency lost three recruiters who refused to learn the new system, discovered 40,000 duplicate candidate records during data mapping, and spent the last four months of the project running both the old and new systems simultaneously because nobody trusted the new one.
The best ATS migration I have managed took 10 weeks. Same size agency. Similar complexity. The difference was not the technology. It was the approach.
ATS migrations do not fail because the new system is bad. They fail because the process of getting there was bad. And "the process" includes a whole lot of things that have nothing to do with software configuration.
ATS migrations fail because of people and process problems, not platform problems. I have managed or consulted on over 60 ATS migrations in my career. The technology works. Bullhorn works. Avionte works. JobAdder works. The platforms are mature. The APIs are documented. The implementations teams have done this before.
The failures come from three places:
Change resistance. Your recruiters have built their careers around the current system. Their shortcuts, their workarounds, their personal efficiency hacks. Telling them to start over on a new platform feels like telling them their experience does not matter. The resistance is emotional, and no amount of training addresses an emotional problem.
Poor data hygiene. Nobody thinks about their ATS data until they need to move it. Then they discover that 15 years of candidate records, job orders, notes, and attachments are messier than anyone imagined. Field formats are inconsistent. Critical data is in notes fields instead of structured fields. Half the email addresses bounce. The data migration becomes the long pole of the project, and it should have been addressed six months before the migration even started.
Rushed timelines. Someone at the leadership level decides the migration needs to happen in 60 days because the old contract is expiring or because Q1 feels like the right time. Sixty days is not enough time for a staffing agency with real data, real integrations, and real people. Compressed timelines lead to shortcuts, and shortcuts in data migration lead to problems that take months to unwind.
Before you start configuring the new system, complete these four workstreams. They represent the work that separates clean migrations from ugly ones.
Data audit. Pull a complete inventory of your current ATS data. How many candidate records? How many are active (contacted in the last 12 months) vs. dormant? How many job orders? What is the duplicate rate? Which fields are populated, and which are mostly empty? What file types are attached to records?
Do not skip the quality assessment. Pull a random sample of 200 candidate records and score them for completeness and accuracy. That sample will tell you what you are working with. I have had agencies discover that 60% of their candidate records had no phone number, no email, or both. Migrating that data in its current state is a waste of time and money.
Field mapping. Every field in your old system needs a destination in your new system. This sounds simple. It is not. Your old system has 147 fields. Your new system has 163 fields. They use different naming conventions, different data types, and different picklist values. Mapping those fields is a detailed, tedious exercise that requires someone who understands both systems and your business processes.
The mapping document should be a living spreadsheet that includes: old field name, new field name, data type, whether the field is required, the transformation logic (if any), and who is responsible for validating the mapping. This document will be referenced hundreds of times during the migration.
Workflow documentation. Before you configure the new system, document how your agency actually works. Not how the old ATS forces you to work. How your people work. Which candidate stages do you use? What triggers a status change? What emails get sent automatically vs. manually? What reports does leadership rely on?
This documentation serves two purposes: it tells the implementation team how to configure the new system, and it reveals opportunities to improve your workflows during the transition. Migration is the best time to fix broken processes because everyone expects things to change anyway.
Stakeholder alignment. Identify every person who will be affected by the migration and understand their concerns. Recruiters worry about losing their notes and relationships. Managers worry about reporting gaps. Finance worries about billing disruptions. IT worries about integrations. Leadership worries about timeline and cost.
Map these stakeholders, understand their specific concerns, and address them directly. The agencies that skip this step are the ones that face rebellion at go-live.
Trying to migrate everything at once is a recipe for chaos. Break the project into four phases with clear deliverables and decision gates.
Phase 1: Clean and Map (Weeks 1-3)
Deduplicate your candidate database. Standardize field formats. Archive records that have not been active in 24+ months (you can migrate them later if needed, but they should not be in the primary migration). Complete your field mapping. Validate the mapping with a sample data migration of 500 records.
Decision gate: Can you migrate 500 records accurately? If not, refine your mapping and try again.
Phase 2: Configure and Test (Weeks 4-6)
Configure the new ATS to match your documented workflows. Set up automation rules, email templates, pipeline stages, user permissions, and reporting. Build your integrations: job boards, VMS platforms, payroll, background check providers.
Run a parallel test with a small team. Have 3-5 recruiters work in the new system for one week using real data. Track every issue, every question, every "this does not work like I expected." These findings are gold. They tell you exactly what needs to be fixed before the full team sees the system.
Decision gate: Can your test team complete core workflows (source, screen, submit, place) without workarounds? If not, fix the configuration gaps before moving to Phase 3.
Phase 3: Train and Launch (Weeks 7-9)
Training is not a one-day event. It is a multi-touch process.
Session 1: Overview. What is changing, why, and what it means for each role. Address concerns directly. This session is more about change management than system training.
Session 2: Hands-on. Walk through the core workflows in the new system. Let people click. Let them make mistakes. Let them ask questions. Record the session for people who could not attend.
Session 3: Role-specific. Recruiters, account managers, and operations staff use the system differently. Train each group on their specific workflows. Bring your champion users (the ones who tested in Phase 2) into these sessions as peer trainers.
Go-live should be a specific date that everyone knows about well in advance. Cut over on a Monday morning so you have the full week to support the transition. Do not go live on a Friday.
Phase 4: Optimize (Weeks 10-12)
The first 30 days after go-live are critical. Stand up a dedicated support channel (Slack, Teams, whatever your team uses) where people can ask questions and get fast answers. Track the most common issues and address them systematically. Hold a weekly "office hours" session where the implementation team walks through solutions to common problems.
After 30 days, assess adoption. Are people using the new system as intended? Are there workarounds forming? What is the sentiment? Use this data to make targeted improvements and identify anyone who needs additional support.
I am not being dramatic with that heading. I have seen ATS migrations nearly destroy team morale. The key to avoiding that outcome is relentless communication and genuine empathy.
Communicate early and often. Start talking about the migration 60 days before go-live. Explain the "why" before the "what." People will tolerate significant change if they understand the reason. "Our current system cannot scale to our growth targets" is a reason. "The new system is better" is not.
Build a champion network. Identify 1-2 people in each office or team who are tech-savvy, respected by peers, and willing to learn the new system early. Train them first. Let them be the go-to resource for their colleagues. Peer support is more effective than formal training because people are more likely to ask a colleague a "dumb" question than to ask the IT team.
Acknowledge the productivity dip. Recruiters will be slower in the new system for the first 2-4 weeks. That is normal. Acknowledge it upfront. Adjust KPI expectations for the transition period. Nothing kills morale faster than being told "learn this new system" and simultaneously being held to the same activity targets.
Celebrate quick wins. When someone makes their first placement in the new system, celebrate it. When a team discovers a feature that saves them 30 minutes a day, share it widely. Early wins build momentum and counter the natural negativity that accompanies any change.
Duplicate records. If you do not deduplicate before migration, you will have duplicates in the new system on day one. Run deduplication algorithms on your candidate database, matching on email, phone, and name combinations. Merge duplicates, keeping the most complete record as the master.
Lost attachments. Resumes, contracts, certifications, and other file attachments are the most fragile data in a migration. Some file formats do not transfer cleanly between systems. Some files exceed size limits in the new system. Test attachment migration early and test it thoroughly. A candidate record without a resume is significantly less valuable.
Broken integrations. Your integrations with VMS platforms, job boards, and payroll systems need to be rebuilt or reconfigured for the new ATS. Do not assume that an integration that "works with Bullhorn" will work identically with your new system. Test each integration independently before go-live, with real data flowing in both directions.
Historical data decisions. You do not need to migrate everything. Records that have not been touched in five years probably do not need to come along. But placement history, client relationships, and compliance records should be migrated fully. Define your data migration scope early: what comes, what stays in an archive, and what gets left behind.
Go-live is not the finish line. It is the starting line.
Days 1-30: High-touch support. Daily check-ins with team leads. Rapid response to issues. Weekly system usage reports to identify adoption gaps.
Days 31-60: Optimization. Refine automations based on real usage patterns. Build the reports your team actually needs (not the ones you thought they would need). Address the workarounds that are forming by fixing the underlying configuration issues.
Days 61-90: Measurement. Compare key metrics against your pre-migration baselines. Time-to-fill, recruiter activity levels, data quality scores, user satisfaction. If any metric has not recovered to pre-migration levels, investigate why and address it.
The agencies that treat the first 90 days as an active project, not a passive "let's see how it goes," are the ones that achieve full adoption and start seeing the ROI they projected.
A well-managed ATS migration takes 10-16 weeks from kick-off to stabilized go-live. This breaks into 3 weeks for data cleanup and field mapping, 3 weeks for configuration and testing, 3 weeks for training and launch, and 3-4 weeks for post-go-live optimization. The worst migrations take 12-14 months when agencies skip pre-migration data work or compress timelines.
The three primary causes are change resistance (recruiters refuse to adopt the new system because the transition feels threatening), poor data hygiene (discovering messy data during migration instead of before), and rushed timelines (compressing a 12-week project into 60 days). The technology itself rarely causes failures; mature ATS platforms work. The process of getting there is where migrations break down.
Prevent data loss by running a complete data audit before migration starts, validating field mapping with a 500-record sample migration, testing attachment transfers early (resumes and contracts are the most fragile data), deduplicating records before migration (not after), and testing each integration independently with real data flowing in both directions before go-live.
Start communicating 60 days before go-live and explain the business reason clearly. Build a champion network of respected peers who learn the system first and support colleagues. Acknowledge the productivity dip upfront and adjust KPI expectations for 2-4 weeks. Celebrate quick wins publicly. Address the emotional dimension of the change, not just the technical training.
Days 1-30: high-touch support with daily team lead check-ins, rapid issue response, and weekly usage reports. Days 31-60: optimize automations based on actual usage, build reports the team actually needs, and fix workarounds. Days 61-90: measure key metrics (time-to-fill, activity levels, data quality, satisfaction) against pre-migration baselines and investigate any metric that has not recovered.
Planning an ATS migration? Download the Change Management Playbook Template. It includes a communication plan, stakeholder analysis framework, champion network guide, and a 12-week timeline you can customize for your agency.
Download the Change Management Playbook Template
Lauren B. Jones is the CEO and founder of Leap Advisory Partners, with 28 years of experience in staffing technology. She helps staffing agencies, PE firms, and software companies build technology that actually works.
