The Old ERP Dilemma--The Refresh Option

  • Written By:
  • Published:


If your enterprise resource planning (ERP) system is "old", if it is highly modified, if it is far behind in releases, and if it is not really serving your current needs, you may be thinking of replacing it. Many companies ignore the option of "refreshing" the existing system up to the current release and implementing modules and functions added since your original purchase. It works for some people, but will it work for you?

What Is Old?

In the article, the Old ERP—Dilemma: Replace or Add-on old ERP is defined as

If your system has green screens, you have an old ERP system. If your system has a GUI (Graphical User Interface) but not something that looks like most Windows applications, you have an old ERP system. If the system was introduced in the 80's, you have an old ERP system. If your vendor is no longer enhancing the system in "new areas," you have an old ERP system. If your vendor is becoming a "have not" of the ERP industry, maybe old age is approaching.

That article explores the dilemma of replacing what you have or adding on. Other articles in the Old ERP Dilemma series explores other issues around have a system that meets this definition. Here, we explore an additional option: the refresh option.

What Is The Refresh Option

If you are thinking a replacement system is possible, an option is to refresh the system instead of replacing it. The refresh option means you stay with the same vendor and product and reinstall it using the most current release. Like any business decision, both plus and minus issues exist.

Not having to pay for new software is a plus, however, often a vendor may want some money to allow you to get the newest release (coming current in their words). The implementation will be simpler than it was the first time or than with a new vendor or product. For example, users know the basic system and will only have to be trained on the changes; many of the required decisions have been made already; and data conversion may not be an issue or be a minimum challenge. Of course, you should rethink business processes, data issues, and etc. but most of the decisions, training, and data will still be valid.

As part of a refresh, consider new functionality added to the existing system in later releases or from newer modules. For many of these functions, you will find that much of the groundwork has already been done and implementation will be less burdensome than other options.

What about modifications? For some, the motivation of refreshing the system is to eliminate existing modifications and the limitations and expense associated with them. Often, the requirements that originally drove your modifications have been addressed in the current release. But if modifications are still required, they will have to be added.

What are the minuses of a refresh? First, you still have an old system, just a newer version of that old system. You may find that some of the needs are not or cannot be fulfilled via the refresh route because the vendor never addressed these issues. Often, the older software has not been updated for needs that surfaced in the last few years (Sarbanes Oxley, web access, business intelligence, etc).

A very realistic issue is user acceptance. If the old system gets the blame for business problems, is a morale issue, or just suffers from bad press internally, users may not accept any solution that carries the old name.

The Alternatives to Refresh and the Trade-Offs

The alternatives to refreshing the system include doing nothing, renovation, or replacement. All carry a list of plus and minus issues.

Doing nothing means you do not have to write any checks (a plus) but does not solve the business issues that started the thought process in the first place (a minus and actually a cost). The "do nothing option is really just delaying what you have to do eventually. That may be acceptable, but it is not without cost—often a much greater cost than anyone realizes.

The renovation option means spending money to fix some of the things that are problems with the existing system (vendor, product, and release). These could include adding third party modules, custom coding enhancements, or investing in integration. This option can solve some problems but you may not be able to afford to solve some of the most pressing issues. The big negative is that you still have the old system as the foundation and it will continue to be a problem. Both the "do nothing" and the "renovation" options are trade-offs of cost versus business benefit. In both cases, you are deferring a replace decision that will have to be made someday—and deferring this replace decision may be justified

Replacing the system with a new one is a big decision. On the positive side, you get a system that (should be) better at handling your needs and one which has a longer life expectancy that what you have.

But the realities of the replacement strategy are that it costs more and takes longer than our do nothing or renovate strategies. You have to write checks for buying and installing the replacement system. You will suffer the cost of business disruption. For more information on the plus and minus of the replacement strategy, see the article referenced above.


Whether to replace an existing system with a new one is not an easy decision. Other than the "do nothing" option, for all three remaining options, you are talking cost, time, and disruption versus both short-term and long-term benefits. But these three options should be considered because all offer pluses and minuses that must be understood before the right course is decided.

The "do nothing" option is the fall back position, a no decision option. Only make it when you decide the other options are not superior.

The refresh options must be explored with the incumbent vendor and others to fully understand the cost, time, and impact. This is not looking at the incumbent and other vendors as part of the same process as searching for a replacement. The pluses and minus are different and the refresh option must be evaluated on its own merits. It should be compared to the replacement option, but the business cases are very different.

The replacement option is finding a vendor and product that will do a better job. Part of the criteria is the difficulty of moving from where you are to where that vendor wants to take you. Most vendors see implementation as if no existing system is currently in-place. Buyers must understand the "going off the old" part of the implementation process. Remember, the gain from the replacement system is the marginal benefits over the benefits of what you have today. The "old system" may not be great, but it is providing some value.

About the Author

Olin Thompson is a principal of Process ERP Partners. He has over twenty-five years experience as an executive in the software industry. Thompson has been called "the Father of Process ERP." He is a frequent author and an award-winning speaker on topics of gaining value from ERP, SCP, e-commerce, and the impact of technology on industry. He can be reached at

comments powered by Disqus