Read This Before Upgrading Your HR Tech System

This week’s post was written by Ron Conine. Ron is a Project Manager, sitting in St. Louis, who loves the technical side of our work.

Upgrading to the newest version of an HR technology solution can be a big deal. In approaching the decision to upgrade your current HR technology system, it’s important to consider the following situations:

On-premise solutions

This includes on-premise ERP, HCM, HRIS, and possibly best of breed solutions for benefits administration, talent management, time and labor and potentially payroll. Here, we’ll focus on the integrated ERP, HCM and HRIS situations, but the points to consider can be valid for any on-premise solution.

• Customization: Perhaps the biggest reason for choosing an on-premise solution is the ability to customize the system. Most SaaS solutions allow for configuration, but few allow the ability to customize the code and source functionality. (Can’t remember the difference between configuring and customizing? Check out this blog post.) Generally speaking, on-premise solutions allow you to customize and handle large, very unique and complex requirements.
• Timeline: Along those same lines, when you select an on-premise solution, you have it tailored specifically to your organization. It is very common for the deployment and implementation of an on-premise solution to take upwards of 12, 18 and even 24 months to be considered live and fully functioning. A lot of organizations leverage this deployment activity with both internal and external (consulting) resources. In short, the time, effort and financial spend for these deployments is often high. Rarely is a deployment for an on-premise ERP, HCM or HRIS considered a smooth endeavor, but the ability to have a unique solution, which very much fits the objectives, should outweigh the efforts.
• Effort: Like most types of technology, on-premise vendors will routinely offer new enhancements and functionality through upgrades, add-ons, etc. Some of these updates require little effort, but generally speaking, the larger upgrades are intense in terms of effort and often require a lot of consideration in terms of a cost analysis. This is especially true when you have deployed a large number of customizations and modifications to the delivered source code of the product. Often, the first hurdle to consider is simply fatigue. Some organizations have invested not only a large financial spend, but also many, many hours from internal resources. Efforts from not only internal IT, but also HR, finance, payroll and other resources are usually required. Sometimes, when you go through a two-year deployment, the idea of taking on another six to 12 month project is daunting. This may be especially true if the organization feels the solution is finally at an optimal level in terms of usage, functionality and performance.
• Cost: Sometimes an upgrade itself is not expensive in terms of obtaining the product, but the spend considerations to deploy the upgrade are high. More often than not, a large upgrade requires the assistance of a third party to help with the project. This is especially true with highly customized solutions. In short, the modifications put into the current solution require considerable analysis to understand the best way to apply the new upgrade. Poor planning can lead to a very trying project, thus large upgrades usually require a large financial budget.
• Testing: Similar to the testing which went into the original deployment, the upgrade will require the same approach. Basic functional testing and user acceptance testing are an absolute must. Any type of upgrade has to be thoroughly tested of course, but when a solution is highly customized, the unique characteristics which made the solution fit the exact requirements have to be tested in earnest with the new upgrade functionality and enhancements.

Software as a Service (SaaS) solutions

Having covered traditional on-premise solutions above, the alternative situation with regard to upgrades is Software as a Service (SaaS) solutions, which allow you to choose when to adopt the upgrade. Some SaaS providers will allow you to remain on the current version for a certain period time; sometimes this is a few months, sometimes it may be as long as six months. Either way, almost every vendor that allows some flexibility in the timing will eventually require you to accept the upgrade and move to the current version.

The considerations mentioned above for an on-premise solution upgrade may also be true for SaaS situations as well. Generally speaking, in SaaS models the costs to upgrade are minimal, as often the software provider includes the newer version in the subscription or PEPM fee. The caveat may be if you are also considering purchasing an additional module (applicant tracking or onboarding, for example) as part of the upgrade. This often requires an additional financial spend to use the new module.

As part of the process to either accept the new version and/or implement a new module, it is important to remember the following:

• Make sure you have the resources ready to test the upgrade and/or additional module.
• Have a test plan and be ready on an organizational level to successfully use the new features. Usually the vendor will provide a test environment to perform user acceptance testing and plan the organizational readiness. The new version or module should include vendor-provided training, but the burden of testing and preparation falls on the organization.

Sometimes with SaaS solutions, the vendor automatically applies the update or upgrade to all organizations on their system at the same time. Usually, this new version is delivered with the new functionality turned off, but the process of reviewing and testing the new functionality falls to the organization. The same would be true for organizational readiness in this situation. The vendor should be providing training and applicable materials, but the burden of testing and preparation falls to the organization. This would be true not only with system-wide delivered functionality as part of the new version, but also if you are considering rolling out a new module like onboarding and succession planning, for example.

Similar to the situation in which a vendor allows you to choose the timing of accepting the upgrade, some vendors that automatically apply the new version will allow you to see and test the new version in advance (in a test environment). If the option to see the new version in advance is not available, a lot of vendors will refresh your test environment with the newer version or newly purchased module. This should allow you to successfully test and plan before enabling the new version functionality and/or newly purchased module.

When deciding to upgrade or not, all situations have some variance in terms of the financial spend considerations when deciding to upgrade or use new functionality and modules; however, it’s paramount to thoroughly test and understand the new functionally before rolling it out to the organization.