2: The move to Internet architecture changes everything for the IT staff and end users.

All the big vendors have moved their software from a client/server architecture, in which PC-based software accesses a central server through a company's network, to an Internet architecture, in which a Web server joins the mix and the software is accessed through the public Internet and a Web browser. It's new turf for both IT staffers and end users. Staffers suddenly must see the Internet as the platform for the company's most important applications. End users must learn different ways to access programs and absorb all the business process changes that come when they can collaborate with people outside the company. These added capabilities are a good thing, of course. But the planning and change management that is required make them a migraine minefield.

3: The vendor's "desupport date" frustrates a CIO's best-laid plans.

The desupport date is the ticking time bomb of enterprise software upgrades. A vendor says, We won't support version XYZ of our software after this date. Technology changes and customers - especially new ones - demand fresh functionality. Vendors can't afford to support six different versions of their software simultaneously.

But CIOs object to what they call surprise desupport announcements that most major vendors have made in the past few years. They say they aren't getting enough time to do one upgrade before a vendor announces a desupport date for an older version.

Nextel's LeFave has been through this. "When the vendor comes to you and says the product is at the end of its life cycle, that's code for saying, I'm going to be putting my maintenance and development resources on a new product, and you're not going to get anything unless you pay for it yourself," he says. Even if the vendor continues to support old software versions, it will shift the bulk of its people and resources to new versions so that finding someone knowledgeable about your old version becomes like trying to find a department store salesperson on red-tag clearance day.

"I'd like to have a road map of when upgrades are planned and when to expect them so that we can do our planning better," says LeFave.

The average time between upgrades has shrunk from three years in the early 1990s to 18 to 24 months, according to AMR Research, and CIOs have lost the ability to keep up. "Vendors are pushing new code out as fast as they can - so rapidly that you may have updates coming at you almost monthly," says Pat Phelan, an ERP analyst for Gartner (US). "The vendors don't seem sensitive enough to the fact that the average buyer can't absorb that kind of change."

With all these difficulties, a few brave CIOs are fighting to push back the desupport dates. In July 2001, 58 members of the 2200-member independent Oracle Applications Users Group (OAUG) signed a petition urging Oracle to extend the support date for version 10.7 of its ERP software from June 2002 to December 2004. This petition came after Oracle had already extended the desupport date for 10.7 from June 2001 after customers complained bitterly about all the bugs - about 5000 of them, according to customers - that appeared in the initial release of the 11i software in June 2000. (Oracle declined to comment on the number of bugs in 11i.) In the end, Oracle and the OAUG compromised, and the desupport date was extended to June 2003. The other major enterprise vendors - JD Edwards, PeopleSoft, SAP and Siebel, which, like Oracle, have released ambitious upgrades of their software in the past few years - have all extended desupport dates for previous versions in response to customers' complaints about bugs and performance. (In addition, some companies have found third-party support for software after a vendor-announced desupport date.) Download These Scream Savers.

CIOs have two choices when it comes to upgrades: go along or fight. But both options require more planning than most CIOs do now. Even if upgrades aren't a continuous process (and some overworked CIOs may think they are), planning for them must be. It's the only way you can make upgrade decisions without your back against the wall of a desupport date. We've uncovered best practices for building a solid internal governance structure for managing upgrades and staying on top of your vendor's upgrade schedule; for minimising customisations to ease future upgrades; and for organising with your peers to negotiate for desupport dates that won't cripple you.