Home
 > Research and Reports > TEC Blog > Support for Old Releases-Good for the User but Is It Good...

Support for Old Releases-Good for the User but Is It Good for the Vendor?

Written By: Predrag Jakovljevic
Published On: December 17 2003

Introduction

A slew of recent announcements and vendor analyst briefings might be showing an interesting trend. Namely, enterprise software vendors are becoming more amenable to pledging support for older (even quite antiquated) product releases, much to the delight of anxious users who still rely on those releases. Until very recently, these users were faced with vendors' more or less subtle ultimatums and deadlines by which they should migrate to current product releases, or else.

In the recent past however, Made2Manage (with continued support for the Visual FoxPro database-based product release), Adonix (with continued support for the recently acquired CIMPRO Classic and CIMPRO V products), Epicor (with continued support and certain enhancements for venerable Avante, DataFlo, InfoFlo and for the recently acquired MANAGE 2000 product), and MAPICS (with continued support for recently "stabilized" Point.Man, albeit with the option to migrate to the recently acquired and more promising SyteLine product) would be some examples of the vendors that have announced that they will support the respective aged versions of their products. These vendors are encouraging their customers to consider migration at the customers' convenience some time in the future.

Also notable was the recent PeopleSoft pledge to continue to enhance and support the former J.D. Edwards IBM AS/400-based World Software (now renamed as PeopleSoft World), while at its recent worldwide partner conference, Microsoft Business Solutions promised ten years support (till 2013) for all its current product lines on diverse proprietary technologies, even after the so-called Project Green (i.e., new single code platform based on the Microsoft Business Framework including .NET) becomes available some time in 2006. Most recently, Geac Computer Corporation announced a set of programs, called Value for Maintenance, designed to help customers better integrate Geac and third-party software and simplify the Web enablement of the company's applications, whereby the programs will be rolled out first to Geac's legacy mainframe-based E Series and M Series products.

The list of similar announcements could go on, ending with the very recent announcement by SSA Global to offer ongoing support for its recently acquired Baan solutions and also a product roadmap into the future. Incorporating feedback from existing customers, the initiative includes enhancements, extensions, a new thin client user interface (UI) for existing Baan IV and Baan ERP 5 product lines, and a commitment to the delivery of the next generation ERP platform SSA Baan ERP 6, previously codenamed Gemini. This is the reversal of the decision made by Baan when it was part of Invensys. At this stage, SSA Global raises the bar with its claims that "no product will be sunset," whereas most other vendors pledge the support for older products only for some unspecified extended period of time.

In any case, this is good news for user organizations that want to stay on the older release, but is it necessarily a good business model for the vendor?

Why Do the Users Want to Stay on an Older Release?

These announcements are indisputably a sigh of relief for customers who want to remain on an older release. But why do they want to resist the upgrade? As with many things in business, the cost of upgrade often outweighs the value of upgrade.

Factors on the cost side of the evaluation are reapplying modifications, redoing integrations, the need to retrain users (users become attached to the old product that "has been working"), and the general cost of business disruption. The vendor can mitigate some of these costs by supplying conversion tools, training, etc. but much of the cost is unavoidable.

Factors on the value side of the evaluation are new features and support for newer technology, such as Web enablement, collaboration with trading partners, and self-service applications for mobile users to name some. However, users tell us that frequently the features offering the most value are the ones that the users have addressed through modifications, which reduces the value of new features. The situation becomes particularly complicated for the product releases that have been heavily modified/enhanced by a value added reseller (VAR), particularly in cases where the VAR has gone out of business. For more about the upgrade rationale and dilemmas, see The Old ERP Dilemma - Should We Install The New Release?.

Vendor Considerations—It is About the Money

The decision to support older releases is like any other business decision, it is all about the money and profitability. As with any business, if the vendor can make money by providing support for older releases, it is good business for the vendor. The decision may be sugar-coated with pronouncements about doing what is good for the customer, but both the vendor and the customers know that the first consideration must be the money.

In the past, vendors could minimize the cost of support by forcing all customers to stay current, using the most recent release. This led to a common policy of not supporting older releases because that maximized profits. But times have changed. Many customers do not see the value in staying current with releases. These customers then see less value in support since their release is not supported anyway, and are therefore in jeopardy of stopping support payments. Since the vendor needs these customers to maximize revenue and profits, it is now in the best interest of the vendor to support these older releases.

How the costs work and where is the break-even point? The cost has two elements. First, bug fixing and keeping the software compatible with changes in the operating environment (operating system, database, hardware discontinuation, etc.) is a fixed cost that does not vary with the number of customers supported. On the other hand, the majority of hot line support, distributing bug fixes and other similar cost varies with the number of customers supported. (A portion of these costs are fixed, you need a minimum number of people regardless of how many customers are supported.)

Revenue is derived directly from customers taking support. Indirectly, vendors also typically feel that a customer on support is more likely to purchase more software and services, however few vendors consider this (and they should not) when making the decision whether to support an older release. If comparing the projected cost to the projected revenue, does the vendor see an adequate return on investment (ROI)? If so, then it looks upon supporting the older release as more favorable (other issues are part of the decision like the alternative use of the resources, the value of keeping everyone on one release, etc.) If the analysis does not show an adequate return, the vendor has the following three practical solutions: 1) do not offer support, 2) get more customers to buy support, or 3) charge more for the support. While gaining more customers for support sounds obvious, it is often much more difficult (and thus costly) a feat than expected.

Another possible extreme example is the approach taken by Relevant Business Systems, which until recently, did not have a formal major product release schedule per se for its flagship INFIMACS II product, but would rather deliver only several periodical continuous enhancements that all the existing users get automatically (like patches). Still, this is only possible due to the vendor's sharp focus on complex manufacturers and MRO (maintenance, repair, and overhaul) contractors in the defense sector, and with a relatively small install base of customers keenly interested in these individual enhancements. The picture gets quite a bit more complex for a vendor serving dozens of unrelated industries, where not all users would necessarily want to take new enhancements, which would then result with a number of customers remaining on "unsupported" product versions. The proof of a challenge to support all the versions would be Relevant's decision to institute a formal six month schedule, as to mitigate the releases support conundrum.

While particular vendors are making the decision, each may still look for a longer-term commitment from the customer base as an added incentive to offering support. Even behind SSA's vocal pledge for supporting all its products, each individual product release likely has its own profit and loss (P&L) calculation, so that each business case must stand on its own. Consequently, some releases may still be dropped in the future, while some may have the support price increased. Also, with SSA's impending products convergence strategy in the future (i.e., into future devised SSA iSeries, SSA UNIX, and SSA Financials product lines), the vendor may be thinking longer term and want to hereby keep the customers in the fold.

Recommendations

Users—If support for your older release is something that has value, communicate the need to your vendor. Be prepared to talk about what you are willing to commit to, how much, and for how long. If you are off maintenance contract, is this of value to you (for more info, see The Old ERP Dilemma: How Long Should You Pay Maintenance?)? If so, communicate with your vendor.

Vendors—We still see many vendors who steadfastly hold on to their past policies on support. However, times have changed; the industry has changed, should you reconsider your policy? We understand you are running a business and need to make a profit. For most vendors, this is something that your customers want and you should not be afraid of open conversations on the subject. Explain to the customers that this is a business decision that requires you to make a profit and that the cost of support may increase as the number of customers for that support decreases. It can be good business and good for your customers.

About the Authors

Olin Thompson is a principal of Process ERP Partners. He has over 25 years experience as an executive in the software industry. Olin 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 Olin@ProcessERP.com.

Predrag Jakovljevic is a research director with Technology Evaluation Centers, Inc. (TEC), with a focus on the enterprise applications market. He has over fifteen years of manufacturing industry experience, including several years as a power user of IT/ERP, as well as being a consultant/implementer and market analyst. He holds a bachelor's degree in mechanical engineering from the University of Belgrade, Yugoslavia, and he has also been certified in production and inventory management (CPIM) and in integrated resources management (CIRM) by APICS.

 
comments powered by Disqus

Recent Searches
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.