Judging TCO of Enterprise Software Upgrades
- 02 July, 2010 05:30
On the surface, vendors' on-premise software upgrades should be welcomed by their customers who: receive access to a bevy of new functionalities and application enhancements; stay current with compliance and regulatory ERP updates; and remain architecturally nimble to integrate next-gen software and services later.
And yet most companies look forward to the undertaking with roughly as much excitement as a lifelong smoker has when scheduling his annual physical.
"Most business and IT execs put off upgrades as long as possible to avoid costs and minimize business disruption," writes Forrester Research principal analyst Paul Hamerman in a new report: "Application Upgrades: How to Make Upgrade Decisions When Business Value Proves Elusive" (Forrester subscription required).
The report offers an incisive, penetrating look at the pros and cons of on-premise software upgrades and the reasons why many businesses still struggle with the decision.
"Cost of ownership is a universal concern among business process professionals responsible for managing enterprise applications," Hamerman notes. "The ownership cost concerns range from the relatively fixed and predictable vendor maintenance fees, internal staffing, and infrastructure support to the less predictable cost of application upgrades."
He refers to app upgrade costs as a "wild card" when companies are trying to determine enterprise software TCO. That is because:
* New Releases Don't Happen Often. Hamerman writes that "the pulse" of releases for enterprise applications beats, typically, once every two years. "Some vendors have attempted to accelerate the pace of enhancements, with mixed success," he adds. (Of course, upgrades are one of the areas where SaaS and cloud services vendors have an extreme advantage over traditional software vendors, since they can roll out upgrades several times a year.)
* Everything Is Optional. "In the world of licensed on-premises software, the application upgrades are optional, at least until release support deadlines become a factor," Hamerman writes. "The optional nature of upgrades means that neither IT apps professionals nor business stakeholders plan and budget for them on a regular basis; therefore the upgrade costs are usually not factored in as part of the ongoing costs of ownership."
* Upgrade Costs Are Hard to Estimate. Most often, enterprise software upgrades are massive IT projects which necessitate external IT help and skillsets. "Estimating the cost of an upgrade involves a number of variables, including the level of customization, whether prior releases were skipped, the extent of new functionality to be deployed, the stability of the new release, and the impact on integration with other systems," Hamerman writes. "Elaborate planning and justification are usually required by the finance department and IT leadership to fund major upgrade projects."
For the software vendors, upgrades are as vital as new license deals. Hamerman notes that well-known vendors (such as Oracle, SAP, Microsoft and Lawson) "require customers to upgrade within five to seven years to avoid loss of support or increased support costs via extended maintenance programs," he states. "From a vendor perspective, a customer that upgrades is a more profitable customer, pure and simple."
So how are vendors' upgrade marketing pushes faring today? According to Forrester research, 5 percent to 10 percent of enterprise software vendors' customers move to the latest release; 40 percent to 50 percent of customers stay on the release prior to the latest one; and 40 percent to 50 percent remain on older releases--including 10 percent to 20 percent of the customer base who stay on releases that are no longer fully supported by the vendor.
Looking at SAP, in particular, Hamerman states that half of its customer base has fallen behind on upgrades.
For customers who remain on older releases, Hamerman notes, the propensity to upgrade becomes less imperative with each succeeding new release. "They lack the resources to invest in the upgrade project," he writes. "High levels of customization make an upgrade impractical, and upgrades become more difficult when releases are skipped, due to schema and architectural changes."