ATS migration field notes: moving from Personio to Ashby

Over the past few months, I led an ATS migration project for a company planning roughly 100 hires this year across white collar and blue collar roles. They were moving from Personio to Ashby, and the project went live on 9 January 2026.

This is not a guide that tells you which ATS to pick or how to evaluate vendors. This is about the decisions that shaped this migration, the mistakes I made, and what worked in practice. This is what I learned from one migration project. It's not comprehensive, and your situation will have different constraints and priorities.

I've written about parts of this project on LinkedIn already (Part 1, Part 2, Part 3, Part 4, Part 5). 

This article pulls those threads together and adds the lessons I couldn't fit into individual posts.

And it is not an all encompassing view, things are being left out for confidentiality reasons and simply…for space. You can talk to me if you want to know more ☺️.

What We Were Solving For

The team left Personio because they'd outgrown what it could handle as an ATS.

With 100 planned hires and a four-person recruitment team, they needed:

• Reporting that answered questions immediately, not after someone spent two hours building a manual dashboard

• Automation that reduced admin work (scheduling, AI, feedback chasing, candidate updates, etc.)

• AI capabilities built in (interview recordings, note-taking, CV screening, fraud detection)

• Workforce planning integrated with hiring, so the plan and the pipeline lived in one place

• Better stakeholder and candidate experience (clearer visibility, proper feedback forms, automated communication)

• Innovation and constant relevant feature releases 

And switching tools meant rebuilding everything from scratch.

What we had to decide upfront

Here are some of the choices that determined how the project went. Some of these we got right. Some I'd do differently next time.

1. Migration scope and data retention

I will not share what we chose in the end, that is proprietary information and ultimately, you decide for yourself.

We migrated what we needed to operate and stay compliant. More data means more cleaning, more mapping, more risk.

2. Process migration philosophy

The question was whether to redesign processes during migration or replicate what exists and optimise later.

We chose replicate first, optimise second.

When you redesign processes at the same time as switching tools, you're changing two things simultaneously. If something breaks, you won't know whether it's the tool, the process, or both. 

The feedback loops get messy, and you create risk you can't isolate.

So we rebuilt what existed in Personio. We made small improvements where it was sensible (updating feedback forms to capture clearer hiring signals, for example), but we parked major process changes for after go-live.

That doesn't mean we accepted everything as-is. It means we documented the current state thoroughly, built it cleanly in Ashby, then gave the team a stable foundation to build on once the migration was behind them.

The instinct when you see a new system with better capabilities is to redesign everything at once. Resist that instinct. You'll have time to optimise once people are comfortable with the tool.

3. Go-live approach

We didn't freeze hiring during the transition. The company extended their Personio contract (smart) which gave us breathing room.

A few roles were actively interviewing during the transition. We kept those running in Personio until candidates moved through their process. Everything else shifted to Ashby at go-live.

We emailed candidates to explain the system change, rebuilt interview schedules manually in Ashby to match what had been set up in Personio, and made sure nothing got dropped.

If we'd tried to run both systems in parallel for all roles, the complexity would have been unmanageable. If we'd forced a hard cutover with active candidates mid-process, we'd have created a terrible candidate experience. The middle ground worked.

4. Documentation strategy

I built a comprehensive documentation library in Google Drive before go-live. Every process, every email template, every configuration decision was documented in Google Sheets and Docs.

This wasn't for my benefit. It was for theirs.

Once Personio gets switched off, the team needs a reference library they can access without relying on institutional memory or calling me every time they have a question.

📖 The library included:

• All Personio exports (jobs, candidates, templates, evaluation forms, rejection reasons)

• Mapped custom fields for candidates, jobs, and offers

• Interview evaluation standards updated for Ashby

• Email templates documented with instructions

• Links to Ashby's knowledge base organised by topic

• Access level matrices showing who can see what in the system

• The 2026 hiring plan

• Process maps for current workflows (offer management, hiring handover to HRIS, etc.)

I also included a list of upcoming tasks with ownership. Things like defining rejection reasons, setting up interview briefings, building automation for saved candidates, configuring notifications.

The goal was to leave them with a system they could manage independently, not one that required ongoing consultant support to function.

What complicated the timeline

The things that caused delays weren't the ones we'd planned for. There were coordination gaps and data problems that surfaced mid-project.

1. Personio's data export structure

I thought the hard part of this migration would be configuring Ashby. It wasn't. The hard part was getting usable data out of Personio.

👉🏻 Personio exports candidate data into a spreadsheet with 85 columns. Not all of them are useful. Some are duplicates with slightly different names (like "applicant source" and "applicant Source"). You can choose which fields to export if you have the patience to scroll through 85 options and figure out what each one does.

👉🏻 The job titles in the export weren't always the job titles showing in the live system. Personio used an older version of the title in the export file, which meant I had to manually reconcile what was live versus what the export claimed was live before I could map candidates to the correct roles in Ashby.

👉🏻 Then there was the CV export. Personio gave us the full download of all their ATS data. Over 16GB of files in ZIP archives. Not organised by candidate. Not organised by job. Just files.

👉🏻 The problem wasn't "how do I upload CVs to Ashby". The problem was "how do I figure out which CV belongs to which candidate for which job when Personio has given me a data dump with no structure".

I couldn't solve that on my own. Ashby's engineering team had to step in. It worked, but it shouldn't have been necessary.

None of this was technically complex. It was just unnecessarily manual because Personio's export structure seems designed to make simple things impossible.

If you're migrating from Personio, build extra time into your plan for data cleaning. You'll need it.

2. Stakeholder coordination gaps

👎🏼 I didn't map internal stakeholders early enough, and I didn't push hard enough to get them embedded in the project from the start.

👎🏼 IT access took longer than it should have because I assumed the urgency was clear across the organisation. It wasn't. I should have worked with the head of people to brief IT properly upfront and get them into the rhythm early.

👎🏼 The career page and employer branding updates came together in the final weeks, but only because the person running it was brilliant under pressure. If I'd mapped who owned what earlier and got marketing involved from the beginning, we could have rebuilt the page properly instead of firefighting at the end.

👎🏼 Process structure changed mid-migration without me knowing (for one role). Stage names were updated internally, which broke my bulk candidate upload. I had to redo the data cleaning and rebuild the Ashby structure.

👎🏼 That's on me for not embedding the team in the system earlier and making sure we had clear communication on what could and couldn't change during the transition.

👎🏼 This was a change programme touching IT, HR, operations, and hiring managers. I should have mapped every dependency early and got those people into the process from day one.

As an external consultant, I ended up being the coordination point by default. That worked in the sense that we delivered, but it created gaps I should have caught earlier if I'd structured the stakeholder work better upfront.

3. Project management drift

👉🏻 I started with a detailed roadmap in a Google Sheet. Every task had an owner, dependencies, blockers, risks, and status tracking.

Then Ashby gave us access to their project management platform. I moved the work there and stopped updating the spreadsheet.

That was a mistake.

The vendor's tool was fine for tracking their side of the work, but it didn't give me the same visibility into our internal dependencies and sequencing. I lost the thread on what needed to happen when, and I didn't catch scheduling conflicts or resource constraints as early as I should have.

👉🏻 If I did this again, I'd keep my own detailed roadmap active throughout the project, even if the vendor has their own system. The extra overhead is worth it for the clarity it gives you.

What Worked

Some decisions paid off immediately. Others only became clear once we were past go-live.

1. Building the documentation library upfront - Creating comprehensive documentation before launch meant the team had a stable reference point once Personio is getting switched off.

• They weren't relying on memory or asking me to resend information. Everything was in one place, organised logically, with clear ownership for next steps.

2. Having a solid internal project lead

• Fabian was my internal counterpart driving this project. When he was unavailable, Patrice (head of people and talent acquisition) stepped in.

• Having someone inside the organisation who understood the project, could make decisions (was empowered by his lead), and could rally the team made the difference between this working and this being impossible.

• External consultants can build and configure and document, but we can't make internal decisions or manage internal politics. You need someone on the inside who owns that work.

3. Not trying to redesign everything at launch

• We replicated what existed, made targeted improvements where they were obvious, and parked major process changes for post-launch.

• That kept the scope manageable and gave the team a stable foundation to build on.

• Once people are comfortable with the tool, you can optimise. Trying to do both at once creates chaos.

4. Protecting live hiring

• Keeping active roles in Personio until candidates finished their process meant we didn't disrupt anyone mid-interview.

• We communicated the change clearly to candidates, rebuilt schedules manually in Ashby, and made sure nothing fell through the cracks.

• The candidate experience stayed intact, which was the goal.

The Post-Launch Reality

Go-live on 9 January wasn't the finish line. It was the starting point for optimisation.

Here's what we're building now:

• Workforce planning integrated into Ashby, so the hiring plan and the pipeline live together

• Full GDPR compliance logic (consent frameworks, data retention policies, candidate deletion workflows)

• Role-specific automation for candidate communication, feedback requests, and scheduling

• Interview evaluation criteria properly calibrated for different roles

• A custom GPT or Gemini tool to help the team build better prompts for Ashby's AI CV screening (the AI can highlight how well a candidate matches the job description, but it needs good prompts to do that effectively)

• Reporting dashboards and alerts so the team knows immediately when candidates need attention or roles are stuck

• Ongoing training on Ashby's new releases and features

• And more

The difference between "migrated" and "optimised" is significant. Migration means the system works and hiring can continue. Optimisation means the system gives you leverage.

Some ATS migrations stop at "migrated". That's a waste. The real value comes from building on the foundation once it's stable.

🫶🏻 What I Would Do Differently

1. Keep the detailed roadmap active

• Even when vendor tools exist, maintain your own project plan with full visibility into dependencies, sequencing, and ownership.

• The extra overhead is worth it. You'll catch problems earlier and make better decisions about what can slip and what can't.

2. Rally the team earlier and more consistently

• I should have established biweekly team check-ins from the start. Not just project updates, but hands-on time in the system before go-live.

• That would have surfaced concerns earlier, given people time to get comfortable with the interface, and created space to identify bottlenecks or complications before they became blockers.

• I also should have made sure the team read Ashby's documentation and watched their educational videos before launch. Not as homework, but as part of the project plan with clear expectations.

3. Map stakeholder dependencies at the start

• I should have identified every person who touched hiring infrastructure (IT, marketing, operations, HRIS) and got them embedded in the project from day one.

• That means briefing them properly, setting up communication channels, and making sure changes happening internally reached me immediately.

As an external consultant, I can't see what's happening inside the organisation unless someone tells me. Building those feedback loops early prevents things from breaking quietly.

How To Think About ATS Migration Choices

Here is a super basic framework for the decisions that will most likely matter. When to migrate data vs when to archive it

Migrate what you need to operate and maintain compliance. Archive what has legal or historical value but isn't operationally necessary. Skip everything else.

More data means more cleaning, more mapping, more risk. Be ruthless about scope.

How to sequence configuration work

1. Foundations first (user access, permissions, job structures, departments, locations)

2. Core workflows (application forms, pipeline stages, interview processes)

3. Communication (email templates, automated messages, rejection reasons)

4. Evaluation and feedback (interview scorecards, competency frameworks)

5. Data migration (candidates, CVs, historical records)

6. Integration and automation (calendar sync, job board connections, automated workflows)

7. Reporting and analytics (dashboards, alerts, custom reports)

If you try to do everything in parallel, dependencies break and you end up reworking things. 

Things you can change at launch vs. what to park for later

The launch phase is about stability and continuity. The optimisation phase is about improvement and leverage.

Don't try to do both at once.

How to structure documentation so it's useful after the consultant leaves

Your documentation library should include:

• Complete exports from the old system (jobs, candidates, templates, forms, settings)

• Configuration decisions with rationale (why did we set it up this way)

• Process maps for current workflows (what happens when a candidate applies, when an offer is made, when someone is hired)

• Links to vendor knowledge base organised by role and use case

• Access level matrices (who can see what, who can do what)

• Upcoming tasks with clear ownership and context

• Training materials (videos, guides, screenshots)

The goal is not to document everything you did. The goal is to give the team everything they need to operate independently.

The bottom line

Choosing the right ATS matters. And how you execute the transition determines whether hiring actually gets faster and more reliable.

Some migrations stop at "the system works". The ones that succeed keep going until "the system gives us leverage".

That requires documentation, stakeholder coordination, realistic sequencing, and a willingness to optimise after launch rather than trying to perfect everything upfront.

These decisions shaped my project. Yours will be different, but the framework might help you think through what matters for your situation. Think through them early, choose deliberately, and be prepared to adapt when reality doesn't match your plan.

Because it won't.