Upgrade or Re-implementation

All companies continually face the question: Should we upgrade? And if so, when? Opinions vary on how often a company should perform an upgrade. Many tend to postpone such activities until strictly necessary—such as when disruptive errors can be resolved through an upgrade, when new functionality is deemed important, or when the current system version is no longer supported. Others make it part of their ERP strategy to always stay “up to date” and proactively seek business advantages in the newest version of the ERP system.

Sometimes it is easier to tear the house down than to try to rebuild it!

Vendors continuously develop their ERP systems. Typically, this development occurs both on a technical level (e.g., new communication methods, new integration approaches, new technologies that make the software faster, new features, incorporation of new technologies, etc.) and on a functional level, meaning more functionality is programmed and becomes part of the standard package available to the customer when upgrading. Different vendors have different upgrade strategies. Many choose to release a new version every one or two years and in between release larger or smaller packages consisting of bug fixes and minor functional improvements. Some new functionality can be activated without assistance from the vendor, while other functionality requires configuration to work. Increasingly, we see entirely new software generations being introduced, where existing software is discontinued from support.

We often find that it may be more appropriate to re-implement rather than upgrade a solution. There may be several reasons for this, for example:

• The software version in production may be so old that the vendor does not support a direct upgrade to the newest version.
• There may be so many customizations that a project is needed to reassess the necessity of those customizations, based both on new capabilities in the software and on changed business needs in general.
• Changes in the business—such as new products or markets—may have led to rapid “bolt-on” additions to the solution, and a re-implementation can provide an opportunity to follow best practices in a new implementation.

Regardless of the reason, a re-implementation is typically a larger task than an upgrade, and one must think more in terms of a “new solution” compared to an upgrade, which is often approached as a technical exercise requiring minimal involvement from the business.

We often see that re-implementations are the result of having implemented far too many customizations in the solution. Therefore, it is essential to think twice before deciding to develop customizations that are not supported by standard upgrades.

There is no doubt that the trend we see today—where new solutions are cloud-based and, as some vendors say, “evergreen”—means that the number of customizations is reduced, and we will see fewer large re-implementations in the years to come.