How to Switch Applicant Tracking Systems: Export, Migration Plan and Cutover Week

To switch applicant tracking systems safely, export everything from the old tool first, decide what is worth importing, run the new system in parallel on one live job, then cut over in a single planned week and keep the old system read-only for a few months. Most failures come from skipping the export or the parallel run.

Why switching feels risky, and how to shrink the risk

Changing your applicant tracking system is a project that nobody wants and everybody eventually faces. The old tool got too expensive, too slow, too complicated, or the team outgrew a spreadsheet. The fear is reasonable. Candidates are real people, some are in the middle of interviews, and a lost record can mean a missed hire or a data protection problem.

The risk is manageable because most of it is predictable. You lose data when you do not export it. You lose candidates when messages fall into the gap between systems. You lose goodwill when hiring managers are asked to learn a new tool in the middle of a hot search. All three are planning problems, not technology problems. This guide gives a plan you can run with a small team: what to export, what to bring across, how to run the two systems side by side, and what the cutover week should look like. If you are still deciding whether to move at all, read /applicant-tracking-system first, and for an older-style tracker see our article on moving off a spreadsheet.

Step one: decide if you really need to switch

Before any migration work, test the reason. Write the problem in one sentence, such as "we pay for seats we do not use" or "recruiters do not update the pipeline because the tool is slow". Then ask whether a setting, a training session or a cheaper plan on the same system would fix it. Switching has a cost that is easy to underestimate: the hours of planning, the dip in productivity, the risk of lost data, and the learning curve for every hiring manager.

Good reasons to switch are a price you cannot justify at renewal, a missing feature you need weekly, a vendor that has stopped improving, support that does not answer, or growth that the old tool cannot carry. Weak reasons are a competitor's demo looking shinier, or one frustrated recruiter. If the contract is about to auto-renew, check the notice period first, because the calendar may decide your timing. Our checklist at /compare shows how to weigh vendors side by side. If your answer is still yes, you now have a written reason, and that reason becomes the success measure at the end of the project.

Step two: export everything before you do anything else

The first practical step is to take a full copy of your data out of the old system, before you sign anything new. Vendors are most helpful while you are a customer, and slowest after you cancel. Do the export while you still have full access.

Ask for or find the following, and keep each as a file on a drive you control.

The right-hand column is the point. If a category is often missing, test for it now. Run the export, open the files, and check that a candidate you know well appears with their notes and CV. If the vendor says a category cannot be exported, ask in writing, because that answer matters for the contract (see /blog/applicant-tracking-system-contract-and-renewal-checklist-terms-to-read-before-you-sign). Keep a copy of the raw export untouched. Everything you do later works on a copy.

Step three: decide what is worth migrating

You do not have to move everything. Moving every record from the past six years is the default plan, and it is rarely the best one. Old data costs effort to clean, can clutter the new tool, and may carry retention duties you would rather not extend.

Split your data into three groups. Active data is every candidate in an open job or an unfinished process. Move all of it, with notes, stages and documents, because people are waiting on you. Reusable data is the talent pool: strong people you would contact again for a future role. Move the ones with a recent date, consent to be kept, and a note on why they were good. Archive data is everyone else. Keep it in the original export, stored securely, and do not import it.

Retention rules differ by country and sometimes by candidate type, and they set the maximum time you may keep candidate data. Check local law before you decide how long the archive lives. If you have no policy, this is the moment to write one, because a migration is when you are already touching every record. As a rough method, use dates: import candidates active in the last twelve months, import talent pool records with consent, and leave the rest in cold storage. These are example thresholds, not a rule.

Step four: map fields and clean the data

Every system names things differently. One calls the stage "Screening", the next "Review", the next "Phone screen". One stores a full name in one field, another in two. If you import without mapping, you get a mess that takes longer to fix than the mapping would have.

Open the export and the new system's import template side by side, and build a simple map: old field on the left, new field on the right, and a note on anything with no home. Decide a rule for each stage. Merge stages if your new pipeline is simpler, and write the old-to-new mapping down so that reports can be compared later. Clean the obvious problems in a spreadsheet before import: duplicate people, emails with typos, phone numbers in five formats, and blank names. Check how the new tool handles duplicates, because importing the same person twice creates two histories.

Work on a small sample first. Import twenty candidates into a test job and check each field. Rezumz, for example, imports candidates from a CSV into a job and handles duplicates, so a small test file tells you quickly whether your columns line up. Whatever tool you move to, ask the same question: what does the import do with a candidate it has already seen, and can I undo an import? Do not import the full set until the sample looks right. Keep the sample file and the checked result, because they double as a test you can repeat if the first full import needs to be redone.

Step five: run both systems on one live job

The safest cutover is not a cutover at all, at first. Choose one real job, ideally a mid-priority role with a small applicant pool, and run it entirely in the new system while everything else stays in the old one. This pilot exposes the surprises that no demo shows: an email that does not send, a stage name that confuses hiring managers, a report that does not match.

Set a short pilot with clear checks. Candidates can apply and are recorded. Screening works the way the team expects. Interview invitations go out and times are recorded. Feedback from two interviewers is collected. An offer can be drafted, approved and sent. The hire is recorded and the data you need leaves the system. Ask the recruiters and one hiring manager what annoyed them, and fix what you can before the wider move.

While two systems run, protect against split records. Write down which job lives where, post it where the team can see it, and tell hiring managers who to ask. Decide one rule for candidates who apply to more than one role: they stay in the system where their process is happening. It is untidy for a few weeks, and that is a fair price for finding the problems early.

The six-week plan at a glance

Here is a timeline that works for a team of two to ten recruiters. Shorten it if you have few open jobs and lengthen it if you have many. The dates are an example, so anchor them to your contract end date.

Treat week 1 as the one that cannot slip, because it protects your data. Treat week 4 as the one that earns its keep, because it protects your reputation with candidates. If you have a signed contract with a hard end date, count backwards from it and give the project at least four clear weeks.

Cutover week, day by day

Cutover week is where the project becomes visible to candidates. Plan it so that no one is surprised.

On Monday, take a final export from the old system and freeze changes: no new jobs or edits there from this point. Import the delta, which is everything that changed since your main import. On Tuesday, switch the apply routes. Change the apply link on your careers page, update job posts to point to the new apply page, and change the CV inbox address, if you use one. Leave a short notice on the old route if the system allows it. On Wednesday, send any scheduled messages again from the new system, check that candidates in process received a clear message about what happens next, and watch the inbox for confused replies.

On Thursday, check the numbers. Count active candidates by stage in the old system and the new one, and reconcile any differences. On Friday, turn off auto-renew if you have not already, tell your vendor your intention in writing, and set the old system to read-only if it allows. Keep access for at least a quarter, or longer if your retention rules need it, because someone will ask a question about an old hire. Put a date in the calendar to delete the archive when its retention period ends, so the old system does not quietly become a permanent store of data you no longer need.

Tell candidates only what they need: nothing for most, a short note for those mid-process. A sample line is "We have updated our recruitment system, so you may see messages from a new address. Nothing changes about your application."

A worked example

Here is an example with invented numbers. A 25-person agency has 640 candidates in its old tracker, 38 of them in active processes across 6 open jobs, and 90 in a talent pool with dates in the last 18 months. The contract ends on 31 January and requires 60 days notice.

The team imports 90 records, not 640, which turns a three-day cleanup into half a day. They pilot on one job in week 4, discover that hiring managers cannot find feedback in the new layout, and fix it with a 15-minute walkthrough. They give notice on 28 November, 64 days before the contract ends, because they checked the notice date in week 1. In cutover week they reconcile counts and find 2 candidates missing a stage, which a quick edit fixes. The archive export is stored on a restricted drive with a deletion date. None of these numbers are real, but the pattern is: separate who matters, limit what you move, and protect the dates.

Common mistakes when you switch

Canceling before you export. Once access ends, you may never get the data back. Export first, cancel second.

Missing the notice period. A contract that renews unless you give 60 days notice does not care about your project plan. Put the date in the calendar in week 1.

Migrating everything. Bringing six years of stale records into a clean system defeats the purpose.

Skipping the pilot. A demo cannot show how your team uses a tool on a real job with real candidates.

Forgetting the front door. The apply link, the careers page, the job post templates and the CV inbox address all point somewhere. If you change the system and not the links, applications go to the old one.

Leaving hiring managers out. They see the tool for ten minutes a week. A short walkthrough and a one-page guide beat a long training.

Ignoring data protection. Moving candidate data to a new vendor is a change in who processes it. Rules differ by country, so check local law, update your privacy notice if needed, and confirm where the new vendor stores data.

Where Rezumz fits

Rezumz is an AI hiring workspace for small and mid-size hiring teams. If you are moving to it, here is what to expect and what to check.

Rezumz does not bring over stage history or email logs from other systems on its own, so keep your raw export as the archive of record. It suits small and mid-size teams, and the Team plan suits four or more recruiters. It does not suit large enterprises that need deep HRIS or payroll connections, or teams that need one-click multiposting to job boards. Prices: free plan with 2 free candidate analyses, $29 a month, $199 a year, a limited $499 lifetime plan, and Team at $79 a month or $699 a year for up to 10 teammates. See /pricing and try /demo with your own test file.

When not to switch

Do not switch in the middle of your busiest hiring month. Do not switch because a single recruiter dislikes the interface. Do not switch if the real problem is that nobody owns the pipeline, because a new tool will inherit the same habit. And do not switch a week before your contract renews unless you have already confirmed the notice period and the export.

If you are moving off a spreadsheet instead of another system, the same plan applies in a lighter form, and /free-applicant-tracking-system is a useful first stop. The principle is the same either way: export first, move what matters, pilot on one job, and cut over in a planned week.