ATS migrations fail in predictable ways. The most common failure modes are inadequate testing before go-live, missed contract notice periods that trigger unwanted renewals, and insufficient hiring manager communication that creates adoption resistance. This checklist is organised to prevent all three.
Use it sequentially. Each phase builds on the previous one, and skipping phases — particularly discovery, testing, and communication — creates the exact problems that turn a planned 8-week migration into a 16-week project with problems in the middle.
The checklist is organised across six phases that reflect the actual structure of a migration project. The phases don't all run sequentially — Phase 3 (data migration) and Phase 4 (configuration) can run in parallel, as can Phase 2 (contract exit) and Phase 3. But each phase has dependencies on earlier phases, and trying to collapse them further creates the integration and testing gaps that cause go-live problems.
Phase 1: Before you decide (evaluation)
The evaluation phase is where most migrations either set themselves up for success or start accumulating problems. The decisions made here — which data to migrate, which vendor to select, what your minimum acceptable feature set is — determine everything that follows.
Phase 1 checklist: evaluation and decision
- Pull your current ATS usage data: total candidates in system, active pipeline counts, integration list, user count by role type.
- Document your current pipeline stages, automation rules, and approval workflows. This is your migration specification — every item needs to be replicated or intentionally changed in the new system.
- Pull your current ATS metrics: time-to-hire, source tracking, pipeline conversion rates. These become your post-migration baseline.
- Define your minimum viable feature set for the new ATS. Separate "must have" from "nice to have" — this discipline prevents scope creep that delays vendor selection.
- Request demos from 2–3 vendors. For each demo, ask them to demonstrate your specific workflows — not a generic capability overview.
- The one question to ask about renewal pricing: "What is the pricing structure for years 2 and 3 of this contract, not just year 1?" Get multi-year pricing in writing before signing.
- Request customer references from vendors. Specifically ask for references from companies of your size and industry who have migrated from your current ATS.
- Evaluate migration support: does the vendor offer a migration support service? What does it include? Is it included in the subscription or an additional cost?
- Review the vendor's DPA (Data Processing Agreement) if you have EU hiring obligations. Check EU data residency options.
- Make the decision and sign the contract. Confirm your current ATS's contract notice period before signing the new contract — you need both timelines to align.
Phase 2: Contract exit from your current ATS
Contract exit is where the timing-sensitive decisions live. Missing a notice period triggers an automatic renewal that can add a full year's cost to your migration.
Phase 2 checklist: contract exit
- Confirm the exact cancellation notice period in your current ATS Master Services Agreement (30, 60, or 90 days is typical).
- Calculate the notice submission deadline: if your contract renews on September 1 and requires 60 days notice, you must submit notice by July 1.
- Submit cancellation notice in writing per the method specified in your contract. Email is typically accepted — include all required identifying information (account ID, company name, contract number).
- Request written confirmation of notice receipt. File this confirmation.
- Confirm post-cancellation data access window. You typically have 30–90 days of read-only access after the contract end date — plan your final data export to complete before this window closes.
- Request your full data export immediately. Don't wait until near cancellation — bulk exports can take 5–10 business days to fulfil, and you want time to verify completeness.
- Check for any M&A or assignment clauses: if your vendor has been acquired or your own company is being acquired, verify whether contract assignment has occurred and who the contracting entity now is.
Phase 3: Data migration
Data migration is the most technically involved phase. The key principle is: verify before you import, not after.
Phase 3 checklist: data migration
- Review your current ATS data export for completeness. Check: are custom fields included? Are CV/resume files included? Are notes and activity logs included?
- Identify data you can archive rather than migrate: inactive candidates from 3+ years ago with no recent activity. Migrating inactive records adds volume without value and may conflict with GDPR retention obligations.
- Map the field structure from your current ATS export to the field structure of the new ATS. Custom fields need explicit mapping — they won't auto-map.
- Run a pilot import of 200–500 records before the full import. Verify that data appears correctly in the new system: check formatting, field mapping accuracy, and CV file attachment.
- Document what data does not migrate cleanly (workflow configurations, automation rules, report templates) and add these to Phase 4 as rebuild items.
- Run the full import only after the pilot is verified.
- Store a complete copy of your exported data securely outside both systems — you may need it for GDPR DSARs or litigation hold purposes for years after the migration.
Phase 4: New system configuration
Configuration is where the new ATS is built out to match (or intentionally improve on) your current workflows.
Phase 4 checklist: configuration
- Configure pipeline stages to match your current configuration or your intended new configuration.
- Build job templates for each role type you hire (technical, operational, leadership, high-volume, etc.).
- Configure application form templates including any required EEO/GDPR sections.
- Set up user accounts and permission groups: recruiter, hiring manager, interviewer, admin, external collaborator.
- Rebuild automation rules and workflow triggers using your Phase 1 documentation as specification.
- Rebuild interview kits/scorecard templates if your new ATS supports them.
- Configure offer letter templates with merge field mapping.
- Set up integrations: start with the integrations your team uses daily, then secondary integrations. Test each integration with real data, not just a connection confirmation.
- Configure your career page with company branding. Test on mobile — most candidates view career pages on mobile.
- Configure GDPR/compliance settings if applicable: data retention policies, consent capture on application forms, EU data residency settings.
- Configure reporting dashboards for the metrics your team tracks regularly.
Phase 5: Testing
Testing is the most skipped phase in rushed migrations. It is also the phase that prevents go-live failures.
Phase 5 checklist: testing
- Create a test job posting and run it through the complete end-to-end workflow: post, apply (as a test candidate), screen, advance stages, schedule interview (test calendar integration), complete scorecard/feedback, create offer, approve offer.
- Test the mobile application experience. Use your phone and time how long the application takes. Note any usability issues.
- Test the hiring manager experience: advance a test candidate to an interview stage and complete the feedback workflow as a hiring manager with a standard hiring manager account.
- Test each integration with real data flow: advance a candidate to the background check stage and confirm the integration triggers correctly. Schedule an interview and confirm calendar sync works bidirectionally.
- Test the GDPR/compliance features if applicable: submit a DSAR for the test candidate and verify all data is captured in the export.
- Brief 2–3 pilot users (experienced recruiters) to use the system for one active role. Collect structured feedback on specific pain points or gaps.
- Fix all configuration gaps identified in testing before proceeding to Phase 6.
Phase 6: Go-live and old system sunset
Go-live is the point at which the new system becomes the primary system. A 2-week parallel period reduces risk significantly.
Phase 6 checklist: go-live and sunset
- Train all recruiter users. Focus on the specific workflows they use most frequently — not a platform overview.
- Prepare hiring manager onboarding: 1-page role-specific guide explaining how to submit feedback, review candidates, and complete approvals in the new system. Keep it to the 3–4 actions they actually do.
- Communicate go-live to all stakeholders. Be specific about what changes and what stays the same. Acknowledge the adjustment period.
- Set up a go-live support channel: a dedicated Slack channel or email address for immediate questions during the first 2 weeks.
- Go live: all new job postings go into the new system from this point.
- Parallel running decision for active candidates: candidates at offer stage or final interview stage — complete in old system. Early-stage candidates — move to new system.
- Keep old system in read-only mode for 2 weeks as a reference and fallback.
- After 2 weeks: review active pipelines remaining in the old system. Once all are resolved, proceed to old system shutdown.
- Before closing old system account: verify data export completeness one final time. Confirm all data is stored securely externally.
- Submit old system cancellation notice if not already done (verify notice period — see Phase 2).
- Post-migration: set a 90-day review to assess whether the new system is meeting the baseline metrics you established in Phase 1.
We make the switch straightforward
Treegarden's team helps with data migration from any ATS. Transparent pricing from $299/mo. No surprise costs mid-migration.
See pricing and migration support →Common migration mistakes that extend timelines
Most ATS migration projects that go wrong do so in predictable ways. Understanding the failure modes before you start puts you in a much better position to avoid them.
Mistake 1: Skipping the workflow documentation step. Teams that start configuring the new system before fully documenting what they currently have end up rebuilding from memory. Memory is unreliable — you'll miss automation rules, approval routing nuances, and custom fields that don't surface until a recruiter asks "why doesn't this work like it used to?" six weeks after go-live. The documentation step in Phase 1 is boring and time-consuming. Do it anyway.
Mistake 2: Running integration testing at the end. Integration setup is consistently the most time-consuming part of a migration. If you leave it until Phase 5, you either rush it (producing unreliable integrations), delay go-live (because the HRIS integration isn't working), or go live with known integration gaps (hoping to fix them later, which usually means living with them indefinitely). Start integration re-mapping in Phase 4 alongside workflow configuration, not after it.
Mistake 3: Treating go-live as the end of the migration. Go-live is the beginning of the adoption period. The first two weeks after go-live typically surface configuration issues that testing missed, user behaviour that didn't appear in pilot testing, and integration edge cases that appear at production volume. Plan for a 2-week intensive support period post go-live, not a celebration and handover.
Mistake 4: Importing all historical data without reviewing it first. Migrating five years of inactive candidate records creates noise in the new system, potential GDPR compliance issues (if those records should have been deleted under your retention policy), and a larger import job with more failure opportunities. Review your data before migration and decide what to migrate, what to archive, and what to delete. This decision is much easier to make before the migration than after it when the new system is cluttered.
Mistake 5: Involving too many stakeholders in the vendor decision. ATS vendor decisions that require consensus from HR leadership, IT, legal, finance, and three hiring manager representatives take longer to make, produce weaker vendor commitments (because each stakeholder wants different things), and tend to select the least objectionable option rather than the best one. Keep the decision team small: typically the TA lead, one IT representative, and one executive sponsor with budget authority. Consult stakeholders broadly; decide narrowly.
Mistake 6: Underestimating the hiring manager communication effort. Hiring managers are the second most important users of your ATS — after recruiters — and the group with the least tolerance for workflow changes in the middle of active searches. The single most common source of post-go-live complaints is hiring managers who weren't adequately prepared. Budget more time for hiring manager communication than feels necessary. Over-communicate on changes to the 3–4 specific actions they take in the ATS; let everything else wait until they ask about it.
Frequently asked questions
How long should an ATS migration take?
6–12 weeks depending on configuration complexity. Simple setups: 4–6 weeks. Complex setups with multiple integrations and large user bases: 10–12 weeks. Budget the longer end if you have more than 4 integrations, more than 20 users, or highly customised workflows. Rushing below 4 weeks for anything but the simplest setup reliably produces go-live problems.
Do I need to run two systems simultaneously during migration?
Yes, for 2 weeks. The parallel running period lets you complete late-stage candidates in the old system while new hiring runs in the new system. It also gives you a fallback if a configuration issue surfaces under production conditions. If your current contract has already expired, negotiate a 30-day extension for the parallel period — it's worth the cost.
What's the biggest risk when switching ATS providers?
Going live before adequate testing is the most common single cause of migration failures. Second is inadequate hiring manager communication, which creates adoption resistance that can persist for months. Both are entirely preventable with proper planning.
How do I communicate an ATS switch to hiring managers?
Acknowledge the disruption directly. Be specific about exactly what changes in their workflow (how to submit feedback, how to review candidates, how to approve offers). Make getting help easy with a named contact and a fast response commitment. Generic system announcements with training video links don't work — hiring managers don't watch them and end up confused at critical moments.
Should I choose a new ATS before or after exporting data from the old one?
Start the data export request and the vendor evaluation in parallel. Data exports from complex ATS platforms (particularly iCIMS) can take 5–10 business days to fulfil — starting the request early means you have the data available for import testing once you've selected your new vendor. Selecting first and then waiting for data extends the total migration timeline unnecessarily.