Back in the 1990s lots of big companies spent millions of dollars customising enterprise class ERP/SCM applications. One of my colleagues, for example, billed well over a million dollars to a client installing SAP worldwide just for hoping around helping local offices install little NT clusters - which he left behind him like so many rabbit pellets.
During this process another firm, hired to help customize the packages selected, billed something closer to twenty million for its work.
Ten years later the campany, now part of a larger conglomerate, has upgraded its hardware, Windows OSes, database software, and networks three times but is still using the original SAP R3 release. What's happened to them is simple: it would require significant effort to bring the customizations forward and there's no appetite for the costs and traumas this could entail.
Notice that I said "could entail" because they think big problems would emerge, but I don't.
Look closely at what they spent the money on and you see two kinds of things: functional changes and interfaces.
Most of the most complex and expensive functional changes reflect business process ideas that were important during the seventies and eighties but were gone long before the work was done. This seems absurd, but it's very common: what happens is that the people who "made their bones" in the company developing and applying those ideas get into positions of power and essentially veto vendors or project plans which fail to incorporate these processes - even though no one still uses them.
Of the remaining functional enhancements, most represent good ideas that have broader applicability and have therefore made their way into the standard or extended product set.
As a result a careful review usually shows that very few, if any, of the functional customizations done in the 1990s actually have to be carried forward today - and replacement with the standard package would therefore improve useability while decreasing support costs.
The interfaces, however, tend to be a different story entirely. What happens with these is that they absorb most of the money during the initial installation - in that client's case, for example, probably three out of every four dollars spent on customization went to interface design, coding, and testing. Once these work, however, they act as a brake on change in either side -because almost anything can cause the transfer to fail.
Today most of those applications, many of them considered obsolete in the 90s, are still in use because changing them would cause the interfaces to SAP to fail - and that SAP installation can't be upgraded to the current release because that would cause the interfaces to those old applications to fail.
In reality, there's an old solution that works: message oriented middleware grabs data from one system, does any necessary conversions, and dumps it into the other. They could do this to interface the old applications to the new SAP structure and then replace those old applications - but they won't.
They won't because they're trapped - too much inertia, too big a first round hangover, too much user management resistance, and nobody in IT is really eager to drive change that would result in cutting the IT budget and staffing in half.