On an old ERP system – upgrade or re-implement?

Although the majority of my experience relates to Microsoft Dynamics NAV over many years, I believe the following comments will still be relevant to other ERP solutions, at least in part.

Many clients are now looking at their ERP investment in NAV, and are acutely aware they are on an “old” version. These versions are still supported, either by Microsoft (with up to 10 years including extended support or, for even older versions, by their partner using “best endeavours”. In addition, by paying an annual fee (e.g. Software Assurance or Enhancement) back to the software vendor, clients are able to receive the licence for the latest version. This then leads to the question – should the client upgrade their existing solution or should they re-implement? There is a third option to buy an alternative solution but that is a subject for another article.

There are three key areas when deciding on the most appropriate course of action – infrastructure, customisations, and data. Obviously, the course chosen should be based on the best return on investment (ROI) to the company. However, the considerations below will directly impact on the ROI calculation:

Infrastructure

It is clear that technology has moved on extremely quickly (think smartphones!). In many cases, the infrastructure supporting an ERP has changed significantly. Hardware moves on – and the equipment being used for the current application may not be sufficient for a future version. Versions of the operating system (e.g. Windows Server) will no longer be supported. New versions of the database system (e.g. Microsoft SQL) will also have been brought to market. This can introduce risk into a business in terms of security and patching, as well as overall performance.  Some questions to consider:

• Is performance an issue with the current version?
• Would performance be improved by a newer version?
• Can any of the hardware be used with a newer version?
• What are the costs of new licenses for Operating systems/database systems?
• Are there any other systems or software impacted (e.g. Shop Floor Data capture, browser versions, PCs)?
• What is the impact of new clients (e.g. managing phones, allowing web access (SSL certificates), browser compatibility)?
• Is this the time to move to a hosted option or the cloud?

Customisations

By customisations, I am referring to changes made to the software which affects the way the original standard solution works. This could be integrations to external systems, or code written which is maintained only for you. In addition, you may have bought external “modules” or ISV (Independent Software Vendor) solutions. There are two key issues concerning customisations:

• Are they still relevant to the way your business works?
• Have they been replaced in the upgraded, later version of the solution?

Often, customisation takes place during the initial implementation as the key users can’t see past not having a certain function – or can’t consider changing the way they work. Time moves on, and with increased knowledge of the ERP solution, the standard functions may actually work for them. Also, businesses change and the customised functionality may no longer be required – or may be needed in another way.

Sometimes, functions are developed to address shortfalls in the core solutions. These could be ISV solutions (e.g. a workflow engine where it isn’t in the core system) or custom code. If these have been addressed in upgraded versions – could the client move closer to standard (and reduce complexity and also annual maintenance on the ISV solution). The overall approach here should be to review modified functionality and establish whether it really still does add benefit (i.e. increase revenue or reduce costs) to the client. If it does add benefit, then the next stage is to establish whether the original approach was the best way of addressing the requirement – particularly taking into account new features in the latest version of the solution.

Data

The final main area for consideration is around data. The one major benefit of upgrading rather than re-implementing is the continued access to data all in one system. However, often after the users have gained deep knowledge of the solution and how it works, they might have set the system up in a different way. This may also be influenced by new functionality (e.g. workflow or reporting options).  In addition, the business requirements may have changed. Departmental segmentation could have changed, company structures skewed by acquisitions/disposals, product groupings re-defined. Overall, the question to ask is:

If we were setting the solution up “from scratch” – would we do it the same?

As noted above, access to historical data is important for reporting and statutory purposes. However, in many cases the data can be left in a read-only state (either in a copy of the existing database or data extract depending on the licence agreement). Reporting tools (including the trusty Microsoft Excel) can be used to access multiple data sources to allow for comparison reporting and should still work for statutory reports.

Summary

This article in no-way suggests either approach is right every single time. Each project should be reviewed on its merit, based around the above factors. Along with the ROI for the client, there will be the complexity of any upgrade (and therefore cost) to be factored in. If the client has not upgraded for several versions, this could be quite extensive – and may indicate a re-implementation is more preferable. Moving to the latest version of the software now, may make upgrades much easier in the future – so the time frame for ROI assessment needs to be considered too.

The client, along with their partner, should work through all the considerations, to make sure there is a (positive) business case – and agree the best course of action.