ATS Migration Guide: How to Switch Systems Without Losing Data

You know the system is holding you back. Recruiters work around it instead of through it. Hiring managers stopped using it months ago and went back to email. Your time-to-hire is climbing because half the team's day is spent on manual data entry that the ATS was supposed to handle. The real cost of a bad ATS shows up everywhere except the invoice.

But switching feels dangerous. What if you lose five years of candidate data? What if the new system is worse? What if the transition disrupts active hiring and you lose candidates mid-process? These fears keep HR teams locked into systems that are actively damaging their recruiting performance.

Here is the reality: ATS migrations fail when they are rushed, unplanned, or treated as a simple data transfer. They succeed when they follow a structured process. According to a SHRM guide on HR technology selection, organizations that follow a formal implementation methodology are significantly more likely to report satisfaction with their new system after 12 months.

This guide is the methodology. It covers every phase of an ATS migration -- from the first conversation about switching through the 90-day post-migration review -- with specific action items, timelines, and the mistakes that derail each phase.

When to Switch: Signs Your Current ATS Has Become a Liability

Not every frustration justifies a migration. Switching ATS platforms costs time, money, and organizational attention. The decision should be based on a pattern of failures that affect recruiting outcomes, not on a single bad experience or a feature comparison spreadsheet.

These are the conditions that reliably indicate it's time to migrate:

Recruiter workarounds have become standard practice. When your team routinely uses spreadsheets, email threads, or Slack channels to manage candidates instead of the ATS, the system has failed at its primary function. Workarounds mean the ATS is creating work rather than reducing it. Track how many hours per week your recruiters spend on activities that should be handled by the system -- if it's more than 3 hours per recruiter per week, the system is a net negative.

Hiring manager adoption is below 40%. If fewer than half your hiring managers regularly log into the ATS to review candidates, provide feedback, and advance pipeline stages, you have an adoption problem that training won't fix. Low adoption usually means the hiring manager experience is too complex, too slow, or too many clicks from their actual decision. This is a system design problem, not a training problem.

Your integration requirements have outgrown the platform. If your ATS can't connect to your HRIS, background check provider, assessment tools, or job boards without manual data transfer, you're spending recruiter time on data entry that should be automated. Modern ATS platforms offer 20-50+ native integrations. If yours offers fewer than 10, it's architecturally behind.

Reporting requires manual data pulls. If generating a time-to-hire report, source effectiveness analysis, or pipeline conversion report requires exporting data to a spreadsheet and building formulas manually, your ATS is not functioning as a reporting tool. You're paying for analytics capability you don't actually have.

The vendor's product roadmap doesn't match your trajectory. If your organization is growing, expanding to new geographies, or increasing hiring volume, and the ATS vendor's recent releases have been minor UI changes rather than substantive capability additions, you'll be in the same position 18 months from now -- but with an even larger data migration ahead.

If three or more of these conditions apply, the cost of staying exceeds the cost of switching. The rest of this guide shows you how to switch properly.

Phase 1: Pre-Migration Audit (Weeks 1-2)

The pre-migration audit determines what you have, what you need to keep, and what you can leave behind. Skipping this phase is the single most common cause of migration problems. Teams that jump straight to vendor evaluation end up choosing a system without understanding their own requirements, then discovering gaps during implementation that could have been identified in the first week.

Data Inventory

Your first task is to catalog everything stored in your current ATS. This inventory becomes the specification for your migration -- every item on it must be explicitly accounted for: migrated, archived, or deleted.

• Candidate records: Total count, broken down by status (active, hired, rejected, withdrawn). How many have attached CVs/resumes? How many have notes or evaluation history?
• Job postings: Total count of active, closed, and draft postings. Include templates if your ATS supports them.
• Pipeline configurations: Document every pipeline stage, its name, position in the sequence, and any automation triggers attached to it (auto-emails, status changes, task assignments).
• Custom fields: List every custom field you've created, its data type, and whether it contains data you need to preserve. Custom fields are the most commonly lost data element in migrations because they don't map automatically between systems.
• Users and permissions: Full user list with role types (admin, recruiter, hiring manager, interviewer, external collaborator). Note which users are active vs. deactivated.
• Integrations: Every connected tool -- HRIS, background check, assessment, job boards, calendar, email, Slack. For each, note whether the integration is API-based, native, or manual.
• Email templates: All automated and manual email templates, including rejection emails, interview invitations, offer letters, and onboarding communications.
• Reports and dashboards: Screenshot or export every report your team uses regularly. These become your configuration targets in the new system.

Data Classification: Keep, Archive, Delete

Not everything in your current ATS should move to the new one. According to Gartner's research on HR technology, organizations that migrate selectively -- importing only active and recent candidate data while archiving historical records -- complete migrations 35% faster and report higher user satisfaction with the new system.

Classify your data into three categories:

This classification reduces the volume of data you need to map and import, which directly reduces the time and complexity of the migration. A database of 50,000 total candidates might produce only 8,000 records that actually need to be migrated -- and that's a very different project in terms of effort and risk.

Phase 2: Choosing the New System (Weeks 2-3)

Vendor selection should take 1-2 weeks, not 2-3 months. Extended vendor evaluations create decision fatigue and delay the migration without improving the outcome. If you've done the pre-migration audit properly, you know exactly what you need -- the evaluation is about confirming which vendor delivers it, not discovering what you want.

Evaluation Criteria That Actually Matter

Focus your evaluation on five categories:

1. Workflow match: Can the system replicate (or improve on) your current pipeline stages, automation rules, and approval workflows? Don't evaluate based on a generic demo -- ask each vendor to demonstrate your specific workflows using your pipeline stages and automation requirements.
2. Integration coverage: Does the platform natively integrate with the tools your team uses daily? Check your integration inventory from Phase 1 against each vendor's integration directory. Native integrations are more reliable than third-party connectors.
3. Migration support: What does the vendor offer for data migration? A dedicated migration specialist who owns the process produces significantly better outcomes than a support ticket queue. Ask whether migration is included in the subscription or billed separately.
4. Hiring manager experience: If hiring managers don't adopt the new system, the migration fails regardless of how good the recruiter experience is. During your evaluation, have a hiring manager -- not a recruiter -- test the candidate review and feedback workflow. If it takes more than 3 clicks to submit interview feedback, hiring manager adoption will be a problem.
5. Total cost of ownership: Year 1 pricing is marketing. Ask for years 2 and 3 pricing in writing. Factor in migration costs, integration setup fees, and per-user pricing that scales with your growth. Read about the hidden costs of cheap ATS software before committing to the lowest-price option.

Treegarden includes dedicated migration support at no additional cost -- a named specialist guides you through every step from data export to go-live. But regardless of which system you choose, the migration support question should be a top-three evaluation criterion.

Phase 3: Data Mapping and Field Alignment (Weeks 3-4)

Data mapping is the technical core of the migration. This is where you define exactly how each piece of data in your current system translates to the corresponding field in the new system. Poor data mapping is the root cause of most "data loss" complaints after migration -- the data was imported, but it ended up in the wrong field, with the wrong format, or with values that don't match the new system's field options.

Field-by-Field Mapping

Create a mapping document that covers every field in your export. For each field, document:

• Source field name (as it appears in your current ATS export)
• Target field name (as it appears in the new ATS)
• Data type (text, dropdown, date, number, boolean, file attachment)
• Transformation required (date format conversion, value mapping for dropdowns, text truncation for character limits)
• Notes (any special handling: "this field contains free text in the old system but is a dropdown in the new system -- values need manual classification")

Common Mapping Challenges

Pipeline stage mapping. Your old system might have 8 stages; the new system might default to 6 or allow 15. Map each old stage to a new stage explicitly. Candidates whose current status maps to a stage that doesn't exist in the new system need a decision: which adjacent stage do they land in?

Custom field mapping. Custom fields are the highest-risk element in any migration. They are vendor-specific by definition, and there's rarely a 1:1 match between systems. For each custom field, decide: (a) does this field exist natively in the new system under a different name? (b) do you need to create a matching custom field in the new system? (c) can you merge this field's data into an existing field or a notes field?

Dropdown value mapping. If your old system has a "Source" dropdown with values like "LinkedIn," "Indeed," "Referral," "Career Page," and "Other," and the new system's source field uses different labels (e.g., "Employee Referral" instead of "Referral"), you need a value mapping table. Every dropdown field with different value sets between systems needs this treatment.

Date format differences. US format (MM/DD/YYYY) vs. international format (DD/MM/YYYY) vs. ISO format (YYYY-MM-DD). A date of 03/04/2025 means March 4 in one system and April 3 in another. Confirm the date format in your export file and the expected import format in the new system before running any import.

File attachments. CVs, cover letters, and other documents attached to candidate records are often the most difficult element to migrate. CSV exports typically don't include file attachments -- you need either an API-based export or a bulk file download from your current vendor. Confirm with both vendors (old and new) how file attachments will be handled before you finalize the migration plan.

Phase 4: Data Export (Weeks 4-5)

There are three primary methods for exporting data from an ATS, and each has trade-offs. The right choice depends on your technical resources, the volume of data, and what your current vendor supports.

Method 1: CSV/Spreadsheet Export

Best for: Teams without development resources, databases under 10,000 records.

Most ATS platforms allow bulk CSV export from their admin settings. This gives you a set of spreadsheet files -- typically one per data type (candidates, jobs, applications, notes). The advantages: it's simple, it's human-readable, and anyone on the team can verify the data by opening the file. The disadvantages: CSV exports often miss file attachments, rich text formatting, and relationship data (which candidate applied to which job).

After exporting, open each CSV file and verify: row count matches expected record count, all expected columns are present, date formats are consistent, special characters (accented names, non-Latin characters) display correctly, and no data truncation in long text fields like notes.

Method 2: API Export

Best for: Teams with development resources, databases over 10,000 records, migrations that need file attachments.

API-based export pulls data directly from your ATS through its programming interface. This gives you the most complete data set, including file attachments, activity logs, and relationship data that CSV exports miss. The trade-off is that it requires someone who can write API integration code -- typically a developer or a technical recruiter who's comfortable with scripting.

If your current ATS provides an API and you have technical resources, this is the preferred export method for complex migrations. It gives you full control over what data is pulled and how it's structured.

Method 3: Vendor-Assisted Export

Best for: Teams migrating from enterprise ATS platforms (especially those with limited self-service export options).

Some ATS vendors offer a data export service as part of their offboarding process. Request this early in your migration timeline -- vendor-assisted exports can take 5-10 business days to deliver, and you need time to verify the data before your access window closes.

Request the export in a standard format (CSV or JSON) rather than a proprietary format. Ask specifically whether the export includes: all candidate records (active and inactive), file attachments (CVs, documents), notes and activity logs, custom field data, and user/permission data.

Backup Protocol

Regardless of which export method you use, store the complete exported data set in at least two locations outside both ATS platforms. This backup serves multiple purposes: it's your recovery source if something goes wrong during import, it satisfies GDPR data subject access requests (DSARs) for candidates who apply after you close the old system, and it provides the historical record if you need to reference old candidate data that you chose not to import.

Phase 5: Import and Validation (Weeks 5-7)

Data import is where preparation meets execution. The single most important rule: never run a full import as your first import. Always start with a pilot.

Pilot Import

Import 200-500 records as a test batch. Choose records that represent the full range of your data: candidates at different pipeline stages, records with and without file attachments, records with custom field data, records with notes and activity history, and records from different time periods.

After the pilot import, verify every aspect of every record in the test batch:

• Do candidate names display correctly? (Check for special characters, accents, apostrophes)
• Are contact details (email, phone) in the correct fields?
• Do pipeline stages match your mapping document?
• Are custom fields populated with the correct values?
• Are file attachments (CVs) accessible and openable?
• Do notes appear in the correct candidate records with the correct timestamps?
• Are source/origin values mapped correctly?

Document every discrepancy. Fix the mapping, clean the source data, or adjust the import configuration. Then run the pilot again with a fresh batch. Do not proceed to the full import until a pilot batch passes all verification checks.

Full Import

Once the pilot is verified, run the full import during a low-activity period -- ideally a Friday evening or weekend when no one is actively using either system. This prevents conflicts between live data entry and the import process.

After the full import completes, run a systematic validation:

• Record count check: Does the total number of imported records match the expected count from your classification (migrate + archive categories)?
• Spot check 50 records: Randomly select 50 candidate records across different pipeline stages and verify each one against the source data.
• Search test: Search for 10 candidates by name, email, and phone number. Confirm all are findable.
• File attachment test: Open 20 CVs/resumes from imported records. Confirm they're the correct files attached to the correct candidates.
• Custom field validation: Filter by each custom field to confirm values imported correctly and are searchable/filterable.

Phase 6: Testing and Parallel Running (Weeks 7-9)

Testing is the phase that gets compressed when timelines slip. Resist this. Every hour of testing you skip adds roughly four hours of problem-solving after go-live, because issues found in production are harder to diagnose, harder to fix, and affect real candidates and hiring managers instead of test data.

End-to-End Workflow Testing

Create a test job posting and run the complete hiring workflow from beginning to end:

1. Post the job to your career page and at least one job board integration
2. Apply as a test candidate (use a personal email, not your work email -- you need to verify the external candidate experience)
3. Verify the application appears in the system with all required fields
4. Advance the candidate through every pipeline stage
5. At the interview stage, test calendar integration -- schedule an interview and confirm it appears on the interviewer's calendar
6. Complete an interview scorecard/feedback form as a test interviewer
7. Create and send a test offer letter using your offer template
8. Test the rejection workflow -- reject a test candidate and verify the rejection email sends correctly
9. Test the AI-powered features if the new system includes them: candidate scoring, resume parsing, automated screening

Integration Testing

Test every integration with real data flow, not just a connection confirmation. "Connected" and "working correctly" are different things. For each integration:

• Calendar: Schedule an interview and confirm bidirectional sync (appears on interviewer's calendar; calendar updates reflect in the ATS)
• Email: Send automated emails from three different triggers and confirm delivery, formatting, and merge field accuracy
• Job boards: Post a test job and confirm it appears correctly on each connected board
• Background check: Initiate a test check and confirm the data passes correctly to the provider
• HRIS: If connected, confirm that a test "hire" record syncs to your HRIS with the correct employee data

Parallel Running Period

Run both systems simultaneously for 2 weeks. During this period:

• All new job postings go into the new system only
• Candidates at offer stage or final interview in the old system -- complete their process there
• Candidates at early stages (applied, phone screen, first interview) -- move them to the new system with a brief notification
• Check both systems daily for new applications -- some job board integrations take 48-72 hours to fully redirect
• The old system stays in read-only mode as a reference and fallback

The parallel period is your safety net. If the new system has a configuration issue that wasn't caught in testing, you still have the old system available while you fix it. The cost of running both systems for 2 weeks is minimal compared to the risk of a go-live with no fallback.

Phase 7: Team Training (Weeks 8-9)

Training fails when it's treated as a platform overview. Nobody retains a 60-minute walkthrough of features they won't use for weeks. Training succeeds when it's role-specific, task-focused, and delivered as close to go-live as possible.

Role-Based Training Plan

Recruiters (60-90 minutes): Focus on the daily workflows they'll perform most: posting a job, reviewing applications, advancing candidates through the pipeline, scheduling interviews, sending templated emails, generating reports. Walk through each workflow step by step in the actual system with real (or realistic test) data. Record the session for reference.

Hiring managers (15-20 minutes): Hiring managers do 3-4 things in an ATS: review candidate profiles, submit interview feedback, approve offers, and occasionally post a job. Train only on those actions. Provide a one-page quick reference guide that covers the exact steps for each action with screenshots. The moment training exceeds 20 minutes for a hiring manager, attention drops and retention drops with it.

Interviewers (10 minutes): Interviewers need to know one thing: how to submit feedback after an interview. Show them where to find the scorecard, how to fill it out, and where to click to submit. A 10-minute video or a 5-step guide with screenshots is sufficient.

Administrators (2-3 hours): Admins need deeper training on system configuration: user management, pipeline customization, integration settings, report building, and compliance features. This training should happen 1-2 weeks before go-live so admins can handle configuration requests from day one.

Creating a Support Channel

Set up a dedicated support channel before go-live -- a Slack channel, Teams channel, or shared email inbox specifically for migration questions. Assign two people to monitor it full-time for the first week after go-live. Response time target: under 1 hour during business hours. Fast responses during the first two weeks prevent frustration from hardening into resistance. A recruiter who hits a problem, asks for help, and gets an answer in 15 minutes will adapt. A recruiter who hits a problem, sends an email, and doesn't hear back for 3 days will go back to their old workaround -- and may never come back to the new system.

Phase 8: Go-Live Checklist (Week 10)

Go-live is not the end of the migration. It's the beginning of the adoption phase. The checklist below covers every action that needs to happen on go-live day and the week surrounding it.

Your ATS implementation checklist should include these go-live items at a minimum:

• All active job postings are live in the new system and verified on career page and job boards
• Career page URL redirects from old system to new system are confirmed working
• Email templates are configured and tested (rejection, interview invite, offer, onboarding)
• All users have accounts, correct permissions, and have logged in at least once
• Integrations are tested and confirmed working in production (not just staging/sandbox)
• Support channel is live and monitored
• Hiring manager communication has been sent (what changed, how to do their 3-4 tasks, who to contact for help)
• Old system is set to read-only mode
• Calendar is cleared of non-essential meetings for the migration lead during the first 3 days post go-live
• Rollback plan is documented (what to do if a critical issue is discovered in the first 48 hours)

The 12-Week ATS Migration Timeline

The table below shows a realistic migration timeline for a mid-size organization (10-50 users, 5-15 integrations, 5,000-50,000 candidate records). Smaller organizations can compress this by 2-3 weeks. Larger or more complex environments should add 2-4 weeks, primarily in testing and training. For a deeper look at full system deployment, see the ATS implementation guide.

Phase 9: Post-Migration Monitoring (Weeks 11-12 and Beyond)

The two weeks after go-live are when most problems surface. Issues that testing missed appear under production load, user behaviors that didn't emerge during training create unexpected workflows, and edge cases in integrations show up when real data volumes hit.

Daily Monitoring Checklist (First 2 Weeks)

• Application flow: Are new applications arriving correctly in the system? Check volume against historical averages -- a sudden drop means something is broken in the application flow (career page redirect, job board integration, apply button).
• Email delivery: Are automated emails (confirmation, rejection, interview invite) being sent and received? Check delivery logs daily for the first week.
• Integration status: Are all integrations processing data correctly? Check each integration's sync status or error log.
• Support channel volume: Track the number and type of support requests. Recurring themes indicate configuration gaps that need fixing, not just individual user issues.
• Adoption metrics: Track daily active users, login frequency, and key action completion rates (candidates reviewed, feedback submitted, interviews scheduled). If a user group's adoption drops after the first 3 days, reach out directly -- don't wait for them to ask for help.

90-Day Review

At the 90-day mark, compare post-migration performance against the baseline metrics you captured in Phase 1:

• Time-to-hire: Has it improved, stayed flat, or gotten worse? A temporary increase (10-15%) in the first 30 days is normal as the team adjusts. If it hasn't returned to baseline by day 60, investigate.
• Pipeline conversion rates: Are candidates progressing through stages at the same rate? A drop at a specific stage often indicates a configuration issue at that stage.
• Source tracking accuracy: Are source attributions working correctly? Compare source distribution to pre-migration data -- major shifts likely indicate a tracking configuration issue rather than an actual change in candidate behavior.
• User satisfaction: Survey recruiters and hiring managers separately. Ask three questions: (1) What's better than the old system? (2) What's worse? (3) What's broken and needs fixing? The answers to question 3 are your immediate action items.

According to a Select Software Reviews analysis of HR software implementations, organizations that conduct a formal 90-day review after go-live are 2.4x more likely to rate their migration as successful compared to organizations that treat go-live as the project endpoint.

Addressing the Four Most Common Migration Fears

These fears keep HR teams stuck with underperforming systems. Each is valid. Each is manageable.

Fear 1: "We'll lose candidate data"

Reality: Data loss in ATS migrations is almost always a mapping or import error, not a catastrophic loss event. The data exists in your export files -- it just didn't land in the right place in the new system. The mitigation: pilot imports, systematic validation, and keeping a complete backup of your export data. If something goes wrong during import, you reload from backup and fix the mapping. No data is permanently lost unless you delete your export files, which you should never do.

Fear 2: "There will be downtime during the transition"

Reality: There is no downtime in a properly planned ATS migration. Both systems run simultaneously during the parallel period. The old system stays available in read-only mode while the new system handles all new activity. Candidates never see a gap -- they apply through your career page, which redirects to whichever system is active. The transition is invisible to external applicants.

Fear 3: "The team will resist the change"

Reality: Resistance is proportional to how poorly the change is communicated and how badly the new system's user experience compares to the old one. If you chose the new system based on the evaluation criteria in Phase 2 (including hiring manager experience testing), the user experience should be better, not worse. Resistance shrinks when people can see that the new system saves them time on tasks they do every day. The key is demonstrating that value in the first week -- not promising it in a training deck.

Fear 4: "Active candidates will fall through the cracks"

Reality: The parallel running period in Phase 6 exists specifically to prevent this. Late-stage candidates (final interview, offer) complete their process in the old system. Early-stage candidates move to the new system with a brief communication. No candidate is left in limbo if the cutover is planned. Create a candidate tracker spreadsheet during the parallel period that lists every active candidate, their current stage, which system they're in, and their expected completion date. Review it daily during the parallel period.

What Data to Export: The Complete List

When requesting your ATS data export, make sure you account for every data category below. Missing even one category creates gaps that surface weeks after migration when someone asks "where is X?"

• Candidate profiles: Name, email, phone, address, source, tags/labels, status, creation date
• Application data: Which job each candidate applied to, application date, current pipeline stage, rejection reason (if applicable)
• CVs and documents: All file attachments associated with candidate records
• Notes and comments: Recruiter notes, hiring manager feedback, internal comments -- with timestamps and author attribution
• Interview data: Scheduled interviews, scorecards/feedback forms, interview ratings, interviewer names
• Email history: Automated and manual emails sent to/from candidates through the ATS
• Custom field data: All values stored in custom fields, including the field definitions themselves
• Job posting data: All job postings (active, closed, draft) including descriptions, requirements, salary ranges, locations
• Pipeline configurations: Stage names, stage order, automation rules, approval workflows
• User data: User accounts, roles, permissions, team assignments
• Report data: Any saved reports or dashboards (screenshot or export)
• Integration configurations: Settings for each connected tool (document for rebuild, not always exportable)
• Career page content: Company description, team pages, employer branding content hosted in the ATS
• Compliance records: EEO data, GDPR consent records, data processing logs

Choosing the Right Time to Migrate

Timing affects migration difficulty more than most teams realize. The best migration window has three characteristics:

Low hiring volume. If your organization has seasonal hiring patterns, start the migration during your lowest-volume quarter. Fewer active candidates means fewer records to manage during the parallel period, less risk of candidate disruption, and more recruiter bandwidth for training and adoption.

Contract alignment. Start the migration 90 days before your current ATS contract renewal date. This gives you time to submit cancellation notice (typically 30-60 days required), complete the migration, and avoid paying for a renewal period you won't use. Check your contract for the exact notice period -- missing it can trigger an automatic 12-month renewal.

No major organizational changes. Avoid migrating during a merger, acquisition, major restructuring, or rapid headcount expansion. These events create enough operational disruption on their own. Adding an ATS migration on top compounds the disruption and reduces the team's capacity to manage the transition properly.

If you can't find a window that meets all three criteria, prioritize contract alignment (to avoid paying for a system you're leaving) and plan for a longer parallel running period to handle the higher risk during busy hiring seasons.

Frequently Asked Questions

How long does an ATS migration typically take?

Most ATS migrations take 8-12 weeks from the decision to switch through full go-live. Simple setups with fewer than 5 users and minimal integrations can complete in 6 weeks. Complex environments with multiple integrations, custom workflows, and large candidate databases should plan for 10-12 weeks. Attempting to compress below 6 weeks for anything but the simplest setup usually results in skipped testing or inadequate training -- both of which create problems that take longer to fix than the time you saved.

Will I lose candidate data when switching ATS systems?

Data loss during an ATS migration is preventable with proper planning. The most common data that gets lost isn't candidate records themselves -- it's metadata: activity logs, email thread history, interviewer scorecards, and custom field values that don't map cleanly between systems. To prevent it: export everything your current ATS allows, verify the export contains all expected records, run a pilot import of 200-500 records and check for completeness, and keep a full backup of your exported data outside both systems.

Should I migrate all historical candidate data to the new ATS?

No. Migrating all historical data is one of the most common mistakes. Categorize your data: active candidates (currently in pipeline) -- migrate fully. Recent candidates (last 12-18 months, not active) -- migrate basic records. Archived candidates (older than 18 months, no activity) -- store in backup, don't import. You can always import archived data later if you need it -- but teams rarely do. Importing years of inactive records clutters the system and may create GDPR issues.

What is the best way to export data from my current ATS?

Three methods exist: CSV export (simplest, available in nearly every ATS, but often misses file attachments), API export (most complete, but requires technical resources), and vendor-assisted export (request early -- takes 5-10 business days). The best practice is to use all available methods: vendor-assisted as your primary source, API for any gaps, and CSV as a human-readable backup you can verify in a spreadsheet.

How do I handle active job postings during an ATS migration?

Two weeks before go-live, stop creating new postings in the old system. One week before, recreate active postings as drafts in the new system. On go-live day, publish and redirect your career page. Late-stage candidates (offer, final interview) complete in the old system. Early-stage candidates move to the new system. Check both systems daily during the parallel period for straggling applications.

What should I look for in an ATS vendor's migration support?

Ask five questions: (1) Do they assign a dedicated migration specialist or handle migration through general support? (2) Is data import included or charged separately? (3) How many imports are included (you'll need at least two -- test and production)? (4) What data formats do they accept? (5) What is their typical migration timeline? Vendors who claim 2-week migrations are either defining migration very narrowly or underestimating the effort.

How do I get my team to adopt the new ATS after migration?

Three practices that drive adoption: (1) Involve 2-3 power users in testing -- they become peer advocates. (2) Train by role, not by feature: recruiters get workflow training, hiring managers get a focused 15-minute guide, interviewers get a 5-minute feedback submission walkthrough. (3) Set up a dedicated support channel for the first 30 days with a target response time under 1 hour. Quick responses prevent frustration from becoming permanent resistance.

Can I migrate ATS data using APIs instead of CSV exports?

Yes, and API-based migration is often superior for complex setups. APIs can pull file attachments, activity logs, and relationship data that CSV exports miss. However, it requires a developer or technical consultant. The typical API migration flow: pull from source API into a staging database, transform and map data, then push into target API. For teams without development resources, CSV export with manual verification works well for most migrations under 10,000 records.