5 "Gotchas" in ATS Migration: Tackling Custom Fields, Integrations, and Compliance

Every ATS migration looks simple on paper: export data from the old system, import it into the new one, done. In practice, enterprise ATS migrations routinely go sideways — not because the technology fails, but because teams underestimate the complexity hiding in their own data.

This post covers the five most common gotchas we see in ATS migrations — custom field mapping, activity data linkage, integration breakage, compliance and data retention, and active vs. inactive pipeline confusion — along with concrete steps to address each one. If you're planning a move between platforms like Greenhouse, Lever, iCIMS, Workday, or Taleo, these are the problems worth solving before migration day.

Gotcha 1: Custom Field Mapping — Where Does All That Unique Data Go?

Custom fields accumulate over time. A quick "add field" here, a new dropdown there, and your ATS becomes a bespoke database tailored to your hiring processes. That's useful — until you need to move it somewhere else.

The Problem: Your legacy ATS might have fifty custom fields — everything from skills taxonomies to hiring manager preferences. Your new ATS may offer fewer custom fields out of the box, or the field types don't match. A multi-select checkbox for "Skills" in Greenhouse doesn't map cleanly to a single text field in another platform. Where does that structured data go? How do you avoid losing context your team relies on daily?

Why It's a Gotcha: Each custom field exists for a reason — tracking qualifications, internal process stages, or compliance-related information. Mismanaging this data leads to:

• Loss of historical context: Recruiters can't understand why a candidate was rejected or advanced.
• Broken search and filtering: Key criteria become unavailable.
• Compliance gaps: If custom fields hold legally required information, their loss creates real risk.
• Adoption resistance: If the new system feels less capable, recruiters will resist using it.

How to Handle It:

This demands a rigorous data mapping and cleansing phase before you touch the migrate button.

1. Audit and Inventory: Get a complete list of every custom field in your old ATS. Document its purpose, data type, and whether it's actively used.
2. Strategic Mapping: For each field, decide its fate:
   • Direct Map: Can it map to an existing field (custom or standard) in the new ATS?
   • Reconfigure: Does it need transformation (e.g., merging two old fields into one new one)?
   • Archive/Sunset: Is it obsolete? Can its data be archived off-system for historical reference?
   • Alternative Representation: Sometimes a custom field is better represented by a different feature in the new system (e.g., tags instead of a dropdown).
3. Data Cleansing: Custom fields accumulate messy data — inconsistent entries, typos, outdated formats. Clean it before migration. Don't move junk data into a new system.

This is not a task automated, template-driven tools handle well. Every organization's custom fields reflect its unique processes, and a standard mapping template won't account for that.

Gotcha 2: Losing Activity Data — The Context Behind Every Candidate

You successfully move candidate names, contact info, and custom fields. Then recruiters log in, click on a candidate, and find silence — no interview notes, no hiring manager feedback, no record of salary negotiations. The profile is there, but the story is missing.

The Problem: Activity data — interview notes, internal communications, feedback forms, email threads, resume versions, call logs — is the qualitative context that makes candidate records useful. Migration tools designed for bulk transfer frequently struggle to link these pieces to the correct candidate records, especially when data structures differ significantly between platforms. They might extract the notes but drop them into a generic repository, severing the connection to specific candidates.

Why It's a Gotcha:

• Loss of institutional knowledge: Your team's collective memory about candidates disappears. Re-engaging past applicants means starting from scratch.
• Compromised decision-making: Hiring managers rely on detailed feedback to compare candidates. Without it, they're working blind.
• Legal vulnerability: Historical communication around rejections or accommodations can be critical for defending against legal challenges.

How to Handle It:

Verify that your migration approach can accurately link activity data to the correct candidate records. This isn't about moving data — it's about preserving relationships within that data.

1. Identify All Activity Data: Don't limit your scope to "notes." Account for everything attached to a candidate record — feedback, emails, attachments, status change logs.
2. Understand Relational Structures: How does your old ATS link notes to candidates? How does the new one? These structures are rarely identical across platforms like iCIMS and Lever, or Taleo and Greenhouse.
3. Test Individual Records: In sample migrations, check individual candidate profiles to ensure all associated activity data is correctly displayed and linked. Can you see interview notes? Is the email thread intact?

Gotcha 3: Broken Integrations — When Your Hiring Ecosystem Stops Working

Your new ATS is live. Then the calls start: background checks aren't initiating, the careers page application button returns a blank screen, calendar scheduling is broken. Your new system has become a hiring roadblock.

The Problem: Modern ATS platforms are the hub of a complex ecosystem — careers website, HRIS, payroll, background check providers, assessment platforms, calendar tools, video interviewing solutions. Each integration is a connection passing data between systems. A migration can break these connections if they aren't reconfigured and tested for the new environment. This is especially common when moving between platforms with different API architectures (e.g., migrating from a legacy system like Taleo to a modern API-first platform like Lever).

Why It's a Gotcha:

• Immediate operational disruption: Hiring slows or stops. This impacts time-to-hire and candidate experience.
• Reputational damage: Broken careers pages or unresponsive applications reflect poorly on your employer brand.
• Cost implications: Delays in hiring critical roles have direct financial impact.

How to Handle It:

Map and test every integration in a sandbox environment. This is non-negotiable.

1. Integration Inventory: List every application and service currently integrated with your old ATS. Document what each does and how it connects.
2. Reconfiguration Plan: For each integration, determine how it connects to the new ATS. Does the new platform have native integrations? Will you need middleware? Are there new API keys or authentication methods?
3. Sandbox Testing: Before go-live, set up your new ATS in a non-production environment. Connect all integrations and run end-to-end tests — submit a test application, schedule a dummy interview, initiate a test background check. Verify data flows correctly in both directions.
4. Phased Rollout: For complex integration ecosystems, consider a phased rollout rather than a big-bang approach.

Gotcha 4: Compliance & Data Retention — Don't Migrate Your Legal Liabilities

You've been collecting candidate data for years. Every application, resume, and interaction is stored. That seems thorough — but migrating all of it without considering data retention obligations can create serious legal exposure.

The Problem: Regulations like GDPR (Europe), CCPA (California), and LGPD (Brazil) grant individuals the right to erasure or mandate specific data retention limits. Migrating candidates who applied seven years ago and were never hired — without a legitimate business reason to retain their data — can put you in violation, risking fines and reputational damage. Automated migration tools don't have the logic to distinguish between data you're legally permitted to migrate and data you're not. They move everything you point them at.

Why It's a Gotcha:

• Regulatory penalties: GDPR fines can reach 4% of global annual revenue. CCPA penalties can reach $7,500 per intentional violation.
• Reputational harm: Data privacy violations erode trust with candidates and employees.
• Increased attack surface: Storing unnecessary data increases exposure to security breaches.

How to Handle It:

Establish clear data retention rules before migration begins. This is your chance to clean house.

1. Consult Legal Counsel: Understand your specific obligations regarding candidate data retention in all relevant jurisdictions.
2. Define Retention Policies: Based on legal advice, establish clear rules. Example: "Do not migrate candidate profiles inactive for 3+ years unless they explicitly consented to longer retention."
3. Implement Data Lifecycle Management: Use the migration as an opportunity to set up automated archiving or deletion in your new ATS.
4. Document Everything: Record your data retention policies and the decisions made during migration. This documentation is essential for demonstrating compliance in an audit.

Relevant standards for evaluating a migration partner's security posture include AICPA SOC 2 Type II, GDPR, ISO 27001, and HIPAA.

Gotcha 5: The Active vs. Inactive Pipeline Mess

All candidates are migrated. Recruiters log into the new system, open the active pipeline, and find thousands of candidates — many of whom applied years ago — showing up as "active." The pipeline is immediately unusable.

The Problem: Migration tools often lack the logic to differentiate between genuinely active candidates (currently in an open hiring process) and historical candidates (applied in the past, no longer under consideration). Without this differentiation, every candidate profile may land in the most prominent "Active" status. This is one of the less-discussed migration problems, but it has an outsized impact on recruiter adoption and day-one usability.

Why It's a Gotcha:

• Pipeline clutter: Recruiters can't identify who they should be working on right now.
• Decreased efficiency: Time is wasted sifting through irrelevant profiles.
• Poor adoption: If the new system is immediately frustrating, recruiters revert to spreadsheets.
• Skewed metrics: Time-to-fill and pipeline velocity become meaningless.

How to Handle It:

Use the migration as an opportunity to define clear rules for active vs. archived status in the new system. This is strategic data placement, not just data transfer.

1. Define "Active" and "Inactive": Work with your recruiting team to establish objective criteria:
   • "Any candidate currently in an open requisition."
   • "Any candidate who applied within the last 6 months and is still in review."
   • "Any candidate with a 'hired' status in the past 30 days."
2. Status Mapping: Map old ATS statuses to new ATS statuses (e.g., "Interviewing (Old)" → "Interviewing (New)", "Rejected (Old)" → "Archived (New)").
3. Conditional Migration Logic: Implement rules in your migration scripts:
   • "If status is 'Hired' or 'In Progress' for an open req → Active."
   • "If status is 'Rejected' or 'Closed' and applied 6+ months ago → Archived."
   • "If no activity for 12 months → Long-Term Archive."

This is where custom migration scripts outperform template-driven tools. Your definitions of "active" and "inactive" are specific to your workflows, and a generic tool won't account for them.

Rollback Planning: What Happens When Something Goes Wrong

No migration guide is complete without addressing failure recovery. Even with careful planning, migrations can surface unexpected issues after go-live — broken data relationships, missing records, or integration failures that only appear under production load.

Before starting your migration:

• Maintain a complete backup of your source ATS data in its original format.
• Define rollback criteria — what specific failures would trigger reverting to the old system?
• Establish a rollback window — how long after go-live can you still revert? Coordinate this with your ATS vendor.
• Test your rollback process in your sandbox environment, not just the migration itself.

Having a documented rollback plan isn't pessimism — it's professional risk management.

ATS Migration Checklist

Here's a consolidated checklist extracted from the five gotchas above:

Pre-Migration

• Complete inventory of all custom fields (purpose, data type, active usage)
• Data mapping document: every source field mapped to a destination field, transformation, or archive decision
• Data cleansing pass on custom fields
• Full inventory of activity data types (notes, feedback, emails, attachments)
• Integration inventory: every connected application and service documented
• Legal review of data retention obligations by jurisdiction
• Defined data retention policies with clear rules
• "Active" vs. "Inactive" candidate criteria defined with recruiting team
• Status mapping document: old statuses → new statuses
• Rollback plan documented and tested

During Migration

• Sample migration run with individual candidate record verification
• Activity data linkage verified on sample records
• All integrations connected and tested in sandbox environment
• End-to-end integration tests (application submission, interview scheduling, background check)
• Conditional migration logic applied for candidate statuses
• Data retention rules enforced — only permitted data migrated

Post-Migration

• Recruiter spot-checks on candidate profiles (custom fields, activity data, status)
• All integrations verified in production
• Metrics baseline established (pipeline counts, active candidates)
• Rollback window monitored
• Migration decisions and data retention policies documented for audit trail

Automated Tools vs. Engineer-Led Migration

Conclusion

The success of an ATS migration isn't determined by choosing a great new system — it's determined by how carefully you handle the transition of your data and processes. The five gotchas above — custom field mapping, activity data preservation, integration continuity, compliance enforcement, and pipeline hygiene — are the problems that derail migrations, and they're all solvable with proper planning.

The common thread: automated, template-driven tools work for simple migrations, but they consistently fall short when confronted with the unique data structures, integration ecosystems, and compliance requirements of real organizations.