HR Technology: Systems selection and data migration

by HCA12 Aug 2009


We are about to go to market for a new HR Information System. Currently, we use a variety of databases and spreadsheets, supported by hardcopy files to hold our personnel information. We want to record and manage all this data in one integrated system. What should we take into account in looking for a new system that will do this and what can we do to make data input and migration to the new system as easy as possible?

System selection

Firstly, one of the most important aspects to take into account is the level of integration offered within the solution being reviewed. In other words, is there the ability to record the data once and for this information then be immediately available to other related modules within the solution? For example, once an applicant record is generated within the Recruitment Module, can this information be directly available for HR to conduct a skills match analysis across both applicant and existing employee data as part of a workforce profiling exercise?

Secondly, the solution should have available, as a standard, user defined fields and/or the tools to allow the organisation to customise the database for the purposes of capturing specific data over and above the standard core master file data. This will allow the solution to cater for existing and future data requirements. How easy are these tools to use? Are the customisations maintained and supported following any future upgrades?

Thirdly, does the solution offer built-in reporting capabilities that allow for the extraction of real time data in a variety of easily accessible formats? This is where the value of one integrated solution is realised - the ease of analysing cross module data in a consistent and controlled manner.

Finally, and most importantly, particularly if your organisation is set to expand in the future, is the solution scalable? Can the solution be easily configured to cater for additional employees, changes in organisation structure, new employment conditions (eg, awards, pay rates, allowance variances)? If so, can these changes be easily implemented without the need for extensive vendor involvement (potentially at a considerable cost)? The organisation should ensure that the vendor provides training as part of the initial implementation of the solution in order to ensure this level of self sufficiency can be attained.

Data migration

There are a number of things an organisation can do to ensure the data input and migration process to the new system is achieved as smoothly as possible. These include:

  • Assigning someone the task of centrally co-ordinating the data migration process. This is to ensure a consistent approach to the data migration process, as well as acting as a conduit for the investigation and rectification of data integrity issues.
  • Data cleansing exercise. Data held in existing systems may need to be audited to ensure it is complete and accurate. This may involve the organisation conducting a formal request to all of its employees to review and supply updated personal information. When it comes to data and systems, remember the saying 'garbage in: garbage out'!
  • Grouping similar data sets together (eg, salary, position) and migrate these data sets one at a time. This ensures errors can be rectified in isolation. By segmenting the migration in this manner this will help ensure there are no flow-on consequences as incorrect data in one module could potentially infect related data in another module.
  • Careful consideration also needs to be given to the timing of the data migration. The vendor can assist the organisation in determining the appropriate time to conduct the migration. The number of migrations to occur also needs to be considered and agreed to. It is important to consider the potential risks when deciding on the timing and number of migrations to occur. The migration activity should ideally be conducted in a manner which will result in minimal impact on the implementation resources.
  • The organisation may also need to ascertain whether there is a yrequirement to migrate historical data in addition to the current data. This decision can be determined by a number of factors:

- The integrity of this data ie, accuracy, missing values etc.

-The complexity of the mapping task to convert old codes to new.

-The volume of data to be migrated and its impact on server performance.

-Future availability of the legacy system for historical enquiry/reporting purposes.

  • Finally, all records converted into the new solution need to yundergo a final audit to ensure there are no discrepancies in data between the legacy and new solutions. In addition, communication to all users of both the legacy and new systems needs to take place to ensure any future data:

- is maintained in both systems during the course of any parallel testing or

-is no longer maintained in the legacy system in the event the new solution is now operating in a live environment.

About the author

Justin Corcoran is business development manager at Frontier Software. For more information contact 02 9956 7598 or



Most Read