How To Change Recruitment Software Without Losing Fifteen Years Of History

Ask a firm owner why they’re still on a recruiting system they stopped liking years ago, and you’ll often hear the same answer. It isn’t the price or the contract. It’s the history.

Fifteen years of candidate notes, client conversations and placements is the most valuable thing many firms own. The fear of losing any of it keeps a lot of people exactly where they are.

That fear is reasonable. Moving systems carelessly can lose things. Moving them carefully usually doesn’t. Here’s a practical guide to doing it carefully, whichever vendor you end up choosing.

Start With Your Contract, Not The Demo

Before you look at a single new system, pull out the agreement you have now. Three dates and terms matter more than anything else.

Your renewal date, and how much notice you need to give before it.

What your current vendor includes in a data export when you leave, and in what format.

How long you have to request that export after the contract ends, and whether any part of it costs extra.

Then work backwards from the renewal date. If you need to give notice in the spring, the planning should start well before that. Plenty of firms end up renewing for another year simply because they left it too late.

What To Export Before You Cancel Anything

Get a full export of your data while you still have full access, and open it to check that it’s complete. Don’t assume. Look for each of these:

• Candidate records, with every field you use.
• Client companies and contacts, and how they link to each other.
• Job orders, including closed ones, and the placements made against them.
• Notes and activity history, attached to the right person.
• Resumes and other attachments, which are often exported separately from the records.
• Custom fields, with a note of what each one means at your firm.
• Email history, if it’s stored in the system rather than in your inbox.
• Templates, saved searches and reports you rely on, even if you’ll rebuild them.

Keep a copy somewhere safe that doesn’t depend on either vendor. If anything goes wrong later, you’ll be glad it’s there.

What Usually Doesn’t Come Across On Its Own

This is the part vendors tend to rush past, so it’s worth slowing down.

Your data can move. The fields, the records and the relationships between them can come across. What doesn’t come across is the way you set your old system up over the years. Which fields sit together, the shortcuts your team built, the order things appear in. That was built around the old software, and the new system will work differently. Migrating your data is one job. Configuring the new system around your workflow is another, and no migration makes the new system feel exactly like the old one.

I think it’s better to know that going in. Budget time for training and configuration before go-live, and a little more afterwards while your team settles in. The firms that struggle are usually the ones who expected the new system to look exactly like the old one on day one.

A few other things often need attention:

• Field meanings. A field called “Source” in your old system might mean something different in the new one. Someone who knows your data needs to decide where each field goes.
• Duplicates you already have. Migration is a good moment to clean them up, and a bad moment to discover them.
• Automations and integrations. Email sequences, job board feeds and connected tools usually need rebuilding or reconnecting in the new system.
• Attachments. Check how they’re handled, and whether they’ll still be searchable once they’ve moved.

What To Ask The Vendor You’re Moving To

The answers to these questions will tell you more than any demo.

• What’s included in the migration price, and what could change it once the detailed data review is done?
• Who does the field mapping, and how much of it falls to us?
• Do we get a test load to check before anything goes live?
• Which parts of our data won’t come across, or won’t come across cleanly?
• How are notes, activity history and attachments handled?
• Can we run both systems side by side for a while?
• When does training happen, and is it before or after go-live?
• Who do we call when something looks wrong in week two?

If a vendor can’t answer the “what won’t come across” question clearly, perhaps that’s an answer in itself.

A Realistic Timeline

How long a migration takes depends mostly on your source system, how much data you have, and how customized your fields are. A firm with a fairly standard setup can move much faster than one with fifteen years of custom fields, so treat any fixed date given before anyone understands your source system with some caution.

Whatever the length, the stages tend to run in this order:

• Scoping. You tell the incoming vendor which system you’re on and roughly how much data you hold, and they outline what moving involves.
• Notice and backup. You give notice on your current contract, take a full export for your own records, and send the new vendor an initial backup of your database.
• Discovery and mapping. The new vendor reviews your data in detail, and your fields are matched to the new system’s fields, with your input.
• Test load. Your own data goes into the new system so you can check it.
• Training and configuration. Your team is trained and the new system is configured around how you work, before anything switches over. Automations and integrations get rebuilt or reconnected here too.
• Final conversion. A fresh backup of your database is taken and converted, so anything your team entered after the test load comes across too.
• Go live. You switch over once the records look right and your team is ready.
• Settling in. Your team gets used to the new system, with support on hand for the questions that come up in the first few weeks.

The stages people tend to underestimate are mapping, and training and configuration before go-live. Leave room for both.

How We Approach It At PCRM

If you’ve read this far, you’ll have noticed that most of this applies to any vendor. That’s on purpose. Here’s how we handle it.

We start with a scoping conversation. We talk through the system you’re on now and roughly how much data you hold. Detailed discovery and data review can then happen after contracting, once we have your initial database backup.

We map your fields with you. You know what your fields mean better than anyone, so you’re involved in deciding where each one goes.

You check a test load before anything switches over. You see your own data in PCRM first, and nothing goes live until you say the records look right.

Data migration typically takes two to eight weeks, starting when we receive your initial database backup, depending on your source system and the size and complexity of your data. Before go-live, your team gets initial training and PCRM gets its basic configuration. We then take a fresh backup of your database for the final conversion, so nothing entered in the meantime is left behind. Training and onboarding are planned separately from the migration itself.

We’ll be straight about the hard part too. We migrate the data we’ve agreed with you and help configure PCRM around the way your team works. Automations and integrations may need rebuilding or reconnecting, and your old system’s setup won’t come across as it was. We’d rather tell you that now than have you find out in week two.

Your first training session is scheduled within one business day of your onboarding call. And when something does look wrong, our US-based support team answers calls in under 30 seconds on average.

Talk To Us About Your Migration

This doesn’t need to be a product demo. Tell us which system you’re on now and roughly how much data you hold, and we’ll talk through what moving would involve for your firm, what comes across, what may need rebuilding, and how long it’s likely to take.

Book a migration conversation with the PCRM team.