In recent years, it has become popular to describe organizations with an enterprise system that has become out of date because of accrued unapplied updates as being in “technical debt.” If organizations ignore this debt too long, it can lead to what we refer to as “technical bankruptcy.” An enterprise system in technical bankruptcy is one where the organization cannot, or finds it exceedingly difficult to, pay off the technical debt. At this stage, the system becomes a true legacy system, frozen in the past and extremely difficult to upgrade.
As shown in Figure 3 from our full report, Avoiding Technical Bankruptcy in Legacy Systems, a small but significant percentage of organizations are in danger of falling into technical bankruptcy or are already there. But organizations that have not upgraded their systems in the five-to-nine-year time frame are in the danger zone: Technical debt is building, and if the organization does not undertake a major upgrade, it risks falling into technical bankruptcy. Organizations in the 10-plus-year time frame are likely already there.
The full report identifies five characteristics of systems that have reached the stage of technical bankruptcy:
- Extensive modifications, extensions, and interfaces.
- Poor understanding of the system by users and IT alike.
- Direct involvement of IT personnel in business processes.
- Legacy system atrophy as shadow IT emerges.
- Upgrade or replacement hard to justify.
“In consulting engagements at our sister IT research firm, Strativa, we occasionally encounter systems that have reached this state of technical bankruptcy,” said Frank Scavo, president of Computer Economics. “You can get out, but it takes a formal and sustained effort, in a sense, like going through Chapter 11.”
In the full report, we identify the symptoms of technical bankruptcy and the devastating effects that it has on the organization. We continue by quantifying the scope of the problem specifically for ERP systems, using our research on the typical age, frequency of upgrades, and extent of modification of these systems. We conclude with recommendations on how to avoid technical bankruptcy and, for organizations that have reached this stage, strategies for getting out and staying out of technical bankruptcy going forward.