As technology and business needs are constantly changing, software upgrades are the best way to extend the utility of a company's major investment in systems and software.

AMR Research gives users' top three reasons for migrating to new software releases as the following:

1. New functionality: to significantly enhance the company's performance, either by boosting productivity or lowering operating costs.
2. New technology: primarily to improve system performance, but also on the expectation of lowered maintenance costs.
3. Maintenance: vendor is ending support for the existing release.

Arising from the above, iTSHOWCASE News asked the following questions about the upgrade experience.

Q: Supposing a user thought that an up-grade didn't offer sufficiently new functionality so they passed on it. Does this then make going from say release 3 to release 5 a far more difficult process in the future?

Mazahir Mohamedali, Lilly Software Associates
Not always but it can do.  Usually database migration tools are written to assume the customer is upgrading from the previous release.  However, it is not uncommon for people to leapfrog between releases so the migration process uses 2 steps, the first to take them from "3" to "4" and the second to go from "4" to "5".  Obviously the user never sees the interim "release 4" stage but such a route is more cost effective than writing specialist migration scripts to go from 3 to 5. It is also more reliable as the scripts used will have been tried and tested rather than developing specialist scripts for each and every migration situation.

Howard Joseph, K3
We can support any customer in the migration to a later release no matter what version they are currently using. Our advice however would be that they shouldn't fall too many releases behind. With the high level of development of IMPACT - now SYSPRO 6.0 - upgrades become a little more difficult for customers if they fall more than two releases behind. Keeping relatively up to date means there is less training, data conversion and changes in business processes when an upgrade is implemented.

Doug Miles, Infor:Swan Business Solutions
The benefits from an upgrade will depend on the maturity of the product. Upgrades to younger products or modules will generally add considerably more functionality. The upgrade gain for more mature products is likely to be in a myriad of small details, improving usability and fixing "idiosyncrasies".

Phil Richardson, Exel Computer Systems
At Exel we have automatic procedures that can take customers from older versions of EFACS through to the latest release with minimal disruption.  We never insist on any company taking an upgrade to the latest version of software, we encourage customers to evaluate the business and commercial benefits they will receive from upgrading.

Q: If a customer has modified the existing version of the package and these modifications must now be re-evaluated and re-applied to the new version, what effect does this have on the up-grade process? Is the potential "pain" enough to dissuade a customer from future modification, even if it means changing a business process here and there to fit the software's standard capabilities?

Lilly: LSA always tries to avoid modifications since they can hinder the user's ability to upgrade.  If modifications are unavoidable, we try to write them outside of the core code so as to facilitate future upgrades.  Only as a last resort do we modify core code.  As you rightly point out, this makes it more painful for them to upgrade and yes this can discourage customers from upgrading.  However, new releases often include enhancements and in many instances these enhancements now provide functions as standard where previously bespoke code was developed.  The ramification of this is that the bespoke development is no longer required but specialist migration scripts will be needed to take them from a "modified release 4" to "standard release 5." New technologies such as .NET are specifically aimed at easing the burden for customers that want modifications.  Basically .NET architecture allows user specific applications / screens / functions to be developed without resorting to code changes in the rest of the software. 

K3: Our policy is to build around SYSPRO using the same environment as the standard software to minimize the effect required when an upgrade is required. We have a controlled methodology ensuring that all changes to a standard source can be quickly identified and re-applied to new versions. 
SYSPRO 6.0 is based on Microsoft's .NET architecture and new bespoke developments are increasingly using this technology drawing on an extensive library of software components. This greatly reduces the issues of upgrading modified systems.
The "proof of the pudding" is that K3 has sites, with bespoke software, which have successfully moved through successive generations of our software since we started trading over 21 years ago.

Infor:Swan : Before going ahead with bespoke changes, check the vendor's policy on re-application to upgrades. If there is a support surcharge for bespoke, does this cover all upgrade situations or might there be additional charges or consultancy costs? Would the vendor consider incorporating your bespoke as standard in the next release? Might this require small compromises in your specification?

Exel: Within EFACS are tools that enable the customers to modify the software themselves so most customer modifications will be via triggers or components that are outside of the upgrade process.  Prior to an upgrade going ahead the software is loaded onto a test server at the customer site to ascertain what effect any changes will have on current business practices prior to any upgrade occurring.

Q: At what point is a vendor justified in ending support for an earlier release?

Lilly: It's at the vendor's discretion generally but we try to support at least 2 previous releases.  The amount of support will gradually diminish, egg enhancements will not be added to older releases then finally fixes for a particular bug will only be made available at a particular release level.  In practice, most customers have up to 2 years grace on the release they are using.

K3: Our policy is to offer telephone support on any version of the SYSPRO or IMPACT software until the last company stops using it. Nevertheless with very old versions there is always the problem of how many people in the support team still remember the details of these old versions. We have very low staff turnover at K3 but nevertheless there are always new things to learn and even the best people can only cope with so much information!
It is also not possible to maintain too many versions of the same product without compromising the ability to develop new versions and so we do not commit to fixing errors in older versions of the software.

Infor:Swan : Most reputable vendors are reluctant to withdraw support for older releases. However, infrastructure technology moves on, and it is unfair to expect software versions released 3 or 4 years ago to work on the latest operating system platforms and to link with the latest versions of 3rd party programs such as Microsoft Office. Support policies from the underlying database supplier may force the situation. There is also no doubt that supporting a long history of early versions impacts support desk productivity for everyone.

Exel: When a third-party software supplier withdraws their support to the Vendor.

Q: When a software upgrade calls for a hardware upgrade, should companies bite the bullet and invest accordingly? What are the implications if they just don't have the budget?

Lilly: This is a tough one.  Newer releases are often bigger and more resource hungry as they include support for more new technologies.  What happens if Windows grows?  Did we refuse to move from Windows Version 3 because we had to have Pentium processors?  These days people expect their hardware to last 12 - 18 months at most, so it is not as much an issue as it was say 3 or 4 years ago. Such upgrades should be budgeted for up front and it is important to understand that as a company gets to grip with its' software applications, it will do more with those applications and therefore consume more resource.

K3: Software up-grades can be difficult if a company does not have the funds to invest in new hardware. While some software upgrades simply offer deeper functionality and require no hardware or infrastructure changes others represent technological moves forward and will require more powerful PC's servers and networks. As an example, a customer wanting to take advantage of the web-based applications, which will allow their customers to place orders on-line, will need to make a corresponding investment in new technology.

Exel: Hardware should be considered when companies are looking to upgrade software, but it is reasonable to upgrade separately.  We encourage all customers to evaluate an upgrade and look at what benefits they will achieve from moving to the latest version of software.  With the major advances in hardware specifications and subsequent reduction in cost for hardware, machines are usually specified at the initial sale that will survive many upgrades to the standard software without the need for further expansion.

Q: It's a fact of life that bugs that didn't come in the existing release often accompany the new program release. Should a user wait a certain amount of time until the vendor has got a handle on these problems and then proceed with the up-grade or should they plunge straight in, hoping that support people are more willing to help them in return for their timely action?

Lilly: Horses for courses.  We need the "early adopters" who are willing to try new releases, perhaps because they need a particular feature or function.  We encourage such people by offering as much support as necessary to make the pain bearable.  On the other hand, if there is nothing that you require in the new release then there is no reason why you can't wait until the release has settled down.

K3: The SYSPRO 6.0 ERP system is used throughout the world.  In the UK we have a policy of letting the other territories such as South Africa, the USA and Canada try out new upgrades first. We tend to 'Beta Test' the latest version three to four months after it has been used by customers overseas. When we are satisfied that it meets ours and customers' expectations only then will we release the software to customers.

Exel: If there is a business driver to up-grade, customers should go for it.  Before any upgrade goes live a rigorous real life test of the software will be completed with the customers to iron out any issues that may arise before the company becomes dependant on the new software.