That’s why some CIOs see upgrades as a prime opportunity to flush custom code from the system and replace it with a standard software program or interface from a vendor. Removing custom code makes it easier to upgrade because you don’t have to rewrite the code each time a new enterprise version comes out. It also makes it easier to integrate the software with other software systems inside the company.

"I think the effort required to upgrade is directly related to the amount of custom code you have," says Rafael Sanchez, CIO of Burger King. The Miami-based restaurant chain built a custom software program to handle its real estate dealings when it first installed SAP R/3 in 1995. But this year Sanchez replaced it with standard functionality from SAP. "We reduced the custom code in the real estate package by 90 percent, in finance we got rid of 60 percent, and in HR we’ll lose 60 to 80 percent," he says. "All that means is that we’ll have fewer software applications to support internally."

But CIOs must be careful before they get rid of their customized code during an upgrade. Business users may love that code, so you need their backing?or at least their understanding?for why you’re dropping it, says Cheryl T. Smith, the former senior vice president and CIO of KeySpan, a Brooklyn, N.Y.-based gas and electric company. (Smith became CIO at McKesson in September.)

During recent upgrades to KeySpan’s Oracle ERP system, Smith and Don Stahlin, director of IT, identified all the customized components of the software and the opportunities to go to standard functions in the package’s new version. They met with users to see which customizations they were willing to give up. When the two groups disagreed, they brought the discussion before a steering committee composed of functional and business leaders from across KeySpan.

Smith and Stahlin came up with costs for two options: modifying the actual ERP code of the new version (expensive and difficult) or adding a custom program outside of the ERP system to perform the function. That helped users understand just how much effort IT had to put into writing and maintaining those customizations, says Stahlin. But the users also had to do some research before they could go before the steering committee to plead their case. They had to come up with a "no-technology" option, usually a change to the business process to fit with the software out of the box.