Planning ERP Upgrades - Part 1: Why do you need to Upgrade?
Upgrading an existing ERP system generally doesn’t involve the same level of upheaval as a new implementation, but it’s still an important technology project carrying a substantial cost that needs to be done properly. What are the key things to look out for?
The reasons for undertaking an ERP upgrade usually fall into one of a small number of categories. Upgrades can be undertaken on a voluntary basis (because it’s believed that some benefit will accrue) or they can be forced. One of the most striking points to note is that a very large proportion of upgrade projects are involuntary.
Voluntary Upgrades
- The most common reason for a voluntary upgrade is to take advantage of improved functionality provided in newer versions of the ERP software. The improvements delivered can range from whole new modules to improved reporting capabilities to the provision of additional technical tools such as workflow and alerts.
- Voluntary upgrades can also be undertaken for technical reasons; for example, to migrate to a newer or different database in order to support other business application initiatives. A good example of this might be a company running MS Dynamics NAV on C/SIDE deciding to upgrade to the current version and switch to MS SQL Server.
Forced Upgrades
- The most common cause of a forced ERP upgrade is an outdated technical environment. One example I’ve seen recently involved a situation where the server operating system had to be updated as it was out of support but the ERP system wasn’t supported on the new version of the OS. Cue a forced ERP upgrade.
- The announced withdrawal of support services for older versions of ERP systems is the other main driver for forced upgrades. ERP vendors will only continue to support older software for a limited period – the duration depends on the vendor but can be up to ten years if you’re lucky. Eventually the curtain will fall on the old software and you’ll be left with the options of upgrading, paying a hefty premium for support (not always an option) or taking the risk of operating an unsupported system.
- It’s unusual to be forced into an upgrade to enhance functionality, but it could happen where the change is required for regulatory reasons or in order to comply with customer requirements.
The reasons outlined above are the typical primary drivers for upgrades, but there can be a whole host of secondary objectives:
- Even if the upgrade is forced, organisations should take the opportunity to see what benefits can be derived from the new version of the software. Many companies decide to avoid implementing any new functionality during the upgrade to reduce the risk and limit the extent of the change experienced by users, but smart organisations will follow on from the initial upgrade project with a series of high strategic value projects enabled by the upgraded software.
- Most organisations tend to lose expertise in the use of the ERP system over time, as those involved in the original implementation leave and newer users just learn the bare essentials in order to run the system. Inevitably the capability of the organisation to get the best out of the system diminishes. Upgrades are a great opportunity to address this problem and to put in place structures to extract maximum advantage from the investment in ERP.
- Many systems are implemented with a large number of modifications and customisations to fill functionality gaps. It’s likely that the latest release of a system originally implemented 6 or 7 years ago will now have standard functionality capable of addressing many of the requirements that originally needed customised solutions. Make it your objective to avoid customisations in your upgrade project by, where possible, using standard functionality to replace existing modifications.
This blog was written by John Donagher, Principal Consultant at Lumenia. Read the other blogs in the series 'What will the Upgrade cost?' and 'The Upgrade Implementation Project'. If you would like further information on ERP Upgrades or any other aspect of ERP please send an e-mail to John Donagher.