The ongoing migration challenges faced by thousands of major corporations highlight a critical dilemma that business technology leaders encounter when allocating capital: choosing between an off-the-shelf enterprise resource planning platform and a custom-built solution. Industry data underscores the gravity of this choice, revealing that technology decisions made today invariably dictate corporate operational agility for a decade or more.
According to market research from Gartner, by the end of 2024, only about 39% of the roughly 35,000 companies running SAP’s older ECC platform had acquired licenses to transition to the newer S/4HANA system. With mainstream maintenance for the legacy ECC platform scheduled to conclude in 2027, Gartner projects that approximately 13,000 of those organizations will still be operating on ECC by the year 2030. These businesses will be paying steep fees for extended support on software they originally intended to replace years prior, trapped by the high costs and complex friction of leaving their legacy environments.
This massive backlog serves as a stark warning for any organization selecting an ERP system today. Because an ERP choice is made once and sets the operational agenda for ten years, conducting an honest financial assessment of both custom and packaged routes before signing any contracts is vital. Overlooking this comprehensive upfront budgeting is a primary driver behind the demand for specialized ERP development services, such as those provided by firms like Crunch-IS, where corporate buyers seek clarity on where enterprise architecture budgets actually go.
The License Is the Smallest Number
When evaluating packaged software options, corporate finance teams frequently underestimate the long-term cost trajectory. Vendor support contracts typically run at approximately 22% of the net license value every year. This has long been the standard rate set by SAP for its Enterprise Support tier, and enterprise software giant Oracle has historically maintained a matching pricing structure. Over a standard ten-year lifecycle, maintenance and support fees alone accumulate to more than twice the cost of the original software license, and this expenditure occurs before the organization has paid a single dollar for integration work, custom reporting, or outside implementation consultants.
Furthermore, subscription pricing models are subject to continuous upward drift. Data from the SaaS Inflation Index published by Vertice indicated that average software price increases reached 12.3% year-over-year. Moreover, Vertice’s data shows that 55% of major software vendors raised their prices over the course of a single year. Consequently, building a five-year cost model that assumes subscription fees will remain flat is entirely fictional, yet many budget proposals presented to corporate boards rely on precisely this assumption.
Acknowledging these financial realities does not automatically render an off-the-shelf software package the wrong choice. Rather, it means that any valid financial comparison must run over the full lifecycle of the system, factoring in realistic, recurring price increases, or it ceases to be a meaningful comparison at all.
Paying for Features Nobody Opens
Another critical consideration in the ERP selection process involves software bloat and the utilization rates of pre-built features. Product analytics firm Pendo analyzed feature usage across 615 different software subscriptions and discovered that an astonishing 80% of features in the average product are rarely or never utilized by end-users. Conversely, the analysis found that roughly 12% of features generated 80% of daily user activity.
While this specific usage data is gathered across broader software categories rather than strictly enterprise ERP systems, any operations manager who has watched a warehouse team navigate three separate screens within a forty-module suite will immediately recognize the pattern.
When an organization purchases a packaged ERP, it acquires the entire catalog of features and attempts to configure its internal workflows around most of a system it does not fully use. By contrast, with a custom-built ERP, an organization pays exclusively for the functionality that is actively developed, meaning effective scoping becomes the absolute core of the project.

Yet this approach presents a significant operational catch. Most companies struggle to accurately identify and name their essential 12% of required features in advance. This difficulty represents the strongest argument in favor of purchasing commercial software: a mature, off-the-shelf package allows an enterprise to discover what processes it actually utilizes organically, without having to fund the initial engineering of functionalities it may never need.
Custom Code Has a Maintenance Bill Too
Opting for a bespoke enterprise system does not allow an organization to escape ongoing upkeep costs. Instead, a custom build shifts the maintenance financial burden entirely in-house. In a comprehensive survey conducted by McKinsey involving fifty chief information officers at large financial services and technology firms, respondents estimated that accumulated technical debt equaled between 20% and 40% of the total value of their entire technology estate.
Furthermore, these CIOs reported that 10% to 20% of the budget originally designated for developing new products was being continually diverted simply to manage existing technical debt. Sixty percent of the surveyed leaders confirmed that this internal debt had steadily grown over the preceding three years.
A custom ERP that is rushed to completion without adequate automated testing or thorough documentation serves as a direct path to accumulating these problematic figures. This practice also concentrates critical institutional knowledge within a very small group of software developers. When those key individuals eventually depart the company, the enterprise is left owning an opaque black box that happens to manage payroll and core logistics.
Conversely, custom software builds that age well and maintain long-term utility typically share three foundational operational habits. They are written against a rigorously documented data model, they ship with comprehensive automated tests that any incoming technical team can execute on their first day, and they are built so that personnel outside the original development group can successfully deploy updates.
Most Companies Bring in Help Too Late
The timing of outside expert involvement can heavily influence the success or failure of an enterprise software implementation. Research compiled by Panorama Consulting from a survey of 140 organizations that implemented ERP systems revealed that while 64% of those companies eventually hired an external consulting firm to guide the project, fewer than one-third utilized outside experts during the crucial software selection phase.
As a result, specialized help frequently arrives only after the most expensive strategic decision has already been locked in, leaving consultants to spend the remainder of the project attempting to work around fundamental structural mismatches.
Decide on Processes, Then on Products
The massive backlog of legacy systems remaining on older platforms like SAP ECC illustrates what happens when an enterprise platform is chosen primarily for its extensive feature list and subsequently kept in place solely because the switching costs are too high.
Ultimately, the most useful strategic inquiry extends beyond the binary debate of custom versus packaged software. Leadership teams must determine which two or three core business processes they would categorically refuse to alter for any software vendor. Organizations should build custom solutions around those differentiating processes, purchase off-the-shelf packages for standard administrative and operational needs, and calculate the true price of eventually leaving a platform into the financial spreadsheet before the initial contract is signed. Enterprises that cannot clearly answer those foundational process questions are not yet ready to choose either route.
