5 Migration Myths – understanding & moving recruitment software data

A key question when implementing new software is what to do with your current data. Unless you are using pen and paper, you have candidates, clients and contacts in a different system. Moving that data from one system to another requires a migration engineer to perform the process.

If you have never been through the process before, you could be forgiven for thinking it’s as simple as a quick ‘copy and paste’ approach. Let’s try and dispel a few myths!

Myth 1: A migration is a quick and simple process.

Far from it! Moving data from one system to another is an extremely complex task. A database is typically made up of fields and tables, with links and relationships between them. These can range from a very simple structure, to something extremely complex. Different systems have different requirements, which could be broken or cause errors in your new system if data is not moved correctly. Make sure you ask questions about the process and all the steps are clearly explained to you.

Myth 2: If you have migrated from ‘X Software’ before, can’t the process be repeated?

There are many recruitment software companies out there. Some offer pretty standard solutions, while others allow for configuration. Even with standard software, there can also be different versions of the same software with different database structures. There may be ‘standard’ migrations that your software company have built that can be reused (check with your sales executive for more information). Your data should always be reviewed to make sure your previous supplier hasn’t changed their database structure or any requirements for that product. Any cost related to a ‘standard’ migration is related to translations, quality assurance testing (QA) and running samples, and the final Go Live migration.

Myth 3: You can easily import your own data

This isn’t entirely impossible…but unless your technical person has previous migration experience, it could get messy. A recruitment software company should pride themselves on the skills and professionalism of their Data Migration Engineers. They should have extensive knowledge of the application and database structure you are moving to. Moving your data is an extremely important part of the process. If done correctly, it can aid in a smooth transition from your legacy product to your new software. If approached without the knowledge and skill set needed, it can be a very challenging process. One other consideration is the ability to support you on the product should your own migration be completed with issues.

Myth 4: Everything can be migrated from your legacy system

Would you want to migrate everything from your current system? Is all your existing data high quality and still relevant? Doing a migration is a great time to assess your data, and only bring over the best quality records and information. It could be possible to map every single field and bring over every single record, but use this time wisely and do some housekeeping.

Data cleansing is an important part of the project. Consider using some kind of filtering, such as only migrating candidate records who have been placed on a job within X number of years, or only bring notes or journal entries from the past five years.

How will you handle duplicate data. Do you have 3 ‘John Smith’ records that are really the same person? Are there a handle of ‘ABC Company’ records that should all be one company? If your current system allows for merging of records, start tackling this now. Your data is migrated as it is delivered, and cannot be merged during the process. You should be provided guidance and support as to what methods can be used to help remove duplicates as part of your afore mentioned filtering criteria.

If you have a very small number of records, say 1,000 or less, it might be more cost effective to manually enter that information and not to do a migration. Remember, rubbish in one system is just rubbish in the next.

Myth 5: There is nothing clients can do to determine the outcome of the migration

Not true. You can always make a difference! There are several things that can help assist. Having a designated internal project manager for the migration is a key component of its success. Be sure to have someone with technical knowledge of the database you are moving from and the application and business workflows involved in the process. This is extremely helpful when making mapping or translation decisions. If you have duplicate records, merge or delete as permitted within your current system. As mentioned, this is not a process that can be completed as part of the migration.

As a client, you will be given specific milestones and goals throughout the timeline. Meeting these will help keep the migration on track, therefore keeping the costs within the original quoted amount.