About 6 months ago, I replied to an interesting post on LinkedIn. The thread was started by a recruitment agency director who posted a question asking for suggestions in relation to a new recruitment software provider. The surprising thing was that he was looking to stop using one of the “major brands” in the industry for something else. I’m not going to mention the name of the provider but I decided to take the bull by the horns and left a fairly formal reply about our own recruitment software, what it could offer him and left it there. Shortly after this, I began thinking about his existing system…

• How long had he been using it?
• How much data was there in that system?
• Had he thought about the migration path to a new system?

As a software developer, data migration is one of the items that can cause big problems for user’s looking to migrate to another system and this is often where a lot of companies charge rather large amounts of money to help out. So, I thought I would create a little check list for anyone who’s thinking of switching to another recruitment software provider and wanting to bring their existing data with them.

1. What’s the Quality of Your Existing Data?

The saying “Garbage In, Garbage Out” is very appropriate here. Anyone looking to go through the trouble of migrating could probably do with performing a quick evaluation on the quality of their existing data. What would be the point importing half-complete records or out-of-date information into the new system?  There may be some value in such data to a few recruiters but it’s well worth taking the opportunity to perform a little tidy-up of existing data before it gets extracted and imported into the new system. Think of it as moving house – You wouldn’t bring the contents of the rubbish bin from the old house with you would you?

2. Will You Have to Pay to Get Your Data?

It may sound odd, but you’ll need to check with your existing provider if they will charge you for extracting your data. NOTE – Some providers already offer downloadable copies of your data for an additional fee however I would strongly recommend that you limit access to this functionality internally due to potential issues with data-protection.

“But why? – It’s my data!“

Yes it is your data, but it’s a sad fact of life that just about nothing comes for free. Yes, it’s probably more than likely that your existing provider has a data-extraction system already in place and could extract your data in next to no time, but remember that this extraction process cost them money to develop in the first place, so is charging a small fee to provide such a service completely unacceptable?

“Why can’t they just give me a copy of the database?“

A fair point again, but one which is easy enough to answer. Many database-driven software applications will have a certain amount of their core business logic stored at the database level. Even the design and structure of the tables used to store the data can be something which is unique to a specific product and it would simply be unfair to expect a company to make this public knowledge outside of their own organisation. By providing you with a raw copy of the database files, this is exactly what they would be doing. In any event, you would also need the appropriate database software to read the database files back in again which would most likely cause you even more problems.

The only advice I can give here is that it’s best to ask the question when you sign up with a provider. Some may even be willing to waiver the fee in exchange for a favourable case study or future recommendations in relation to new clients.

3. What Can I “Reasonably” Expect to be Imported Into The New System?

This question is a lot harder to answer. Generally, most recruitment software solutions will share a certain amount of “common data”. What I am referring to when I say “common data” is shared data items. Take a typical candidate record for example; It’s fairly safe to say that most of, if not all systems will store a first name, surname and date of birth against a candidate record. This is exactly the type of “common data” I am referring to.

On the flip-side of the coin, you have “uncommon data“. This is the type of data which causes the problem as it is data which exists in the old system and may be still required by the client, but has no suitable destination in the new system. For this type of data, you are most likely going to have to take one of the following actions:

1. Forget the uncommon data and learn to live without it in your new system
2. Pay the company that develops the new system to customise their product in order to make it fit your uncommon data.
3. Look for another product which can facilitate the uncommon data out-of-the-box
4. Forget all these crazy thoughts about migrating to a new system and continue living with the problems of your existing system (= not ideal)

Once again, it’s best to talk to the new provider first – Most will not bite…much and it’s in their interests to get another happy customer on-board is it not?

Finally – It’s Not As Bad As It sounds – Preparation Is Key

Easy for me to say right? But remember, there are a wealth of people and service providers who can help you out here. You just need to do as much preparation as you can first and be prepared for a few “issues” along the way. It may also be beneficial to talk with your new provider about a trial run of the new system with some sample data first in order to help iron out any problems and minimise the downtime between your old system to new system switch-over.