لماذا يكلف تغيير برمجيات المؤسسات أكثر من شرائها

The software was purchased for £180,000. Implementation was another £320,000. Eighteen months later, the business wanted to add a new approval tier to the purchase order workflow — the kind of change that takes a developer twenty minutes to make in a well-architected system.

The vendor quoted £38,000 and a ten-week delivery timeline.

The operations director pushed back. The vendor explained that the change required a configuration review, a regression test against the existing workflow logic, a UAT environment setup, and sign-off from three of their senior consultants. It was non-trivial.

He authorised the change request. He had no choice. The business needed the approval tier. The data was in the vendor's system. The workflow logic was in the vendor's system. And only the vendor's consultants knew how to change it.

This is not unusual. It is the standard economics of enterprise software post-implementation.

The Common Belief

Once the system is implemented and working, ongoing changes are minor and infrequent. The implementation investment is a one-time cost. After go-live, the system runs with minimal intervention and modest annual support fees.

This is the cost model presented at the point of sale. It is the basis on which the business case is built. It is why the CFO signs the contract.

Why That Belief Is Wrong

The belief that enterprise software changes are minor and infrequent is wrong in two ways.

First, business requirements change constantly. Every business change — a new product line, a regulatory requirement, an acquisition, a change in approval authority, a restructured service offering — creates a requirement to change the system. In a business of any operational complexity, meaningful system change requests arrive several times per year.

Second, enterprise software changes are expensive not because the changes themselves are complex, but because the way enterprise systems store configuration makes every change opaque to anyone other than the vendor's trained consultants. The configuration lives in a proprietary data model that cannot be understood without vendor-specific expertise. Changing it correctly requires that expertise. The vendor holds it. You pay for it, every time.

The post-implementation total cost of ownership is therefore not the support fee. It is the support fee plus the cost of every change request, every upgrade, every regression test, every configuration review. For a mid-market business with a live ERP, this cost is typically between £80,000 and £200,000 per year — over and above the licence fee.

What Actually Happens

Enterprise software creates lock-in through a mechanism that is rarely described plainly at the point of sale: configuration opacity.

When an ERP system is implemented, the configuration decisions — how workflows are structured, how approval logic works, how finance rules apply, how data flows between modules — are encoded in a proprietary format that only the vendor understands. This is not malicious. It is architectural. The system stores configuration in database tables whose schema belongs to the vendor. Reading those tables correctly, and modifying them correctly, requires the vendor's expertise.

The consequence is that the business cannot change its own system without engaging the vendor. Even for changes that are operationally simple. The bottleneck is not the complexity of the change — it is the knowledge required to make it correctly.

This creates a specific power dynamic: the vendor's post-sale revenue depends on the cost and frequency of change requests. A system that was easy to change would have lower post-implementation revenue. The vendor's commercial interest is in systems that require them for every modification, and the architecture reliably produces that outcome.

The result is a post-implementation relationship where:

• Simple changes take weeks and cost thousands
• Complex changes take months and cost tens of thousands
• Changes the vendor has not prioritised in their product roadmap are delivered late, if at all
• Customisations create upgrade risk — changes that work in the current version break in the next
• The business cannot evaluate the cost of a change until after the vendor has assessed it, which requires paying for the assessment

Real-World Example

Company: Forsyth Distribution Services
Industry: Third-party logistics and warehousing
Size: 220 staff, £28M revenue
Problem: Post-implementation change costs exceeded original implementation budget within three years

What happened:

Forsyth implemented a mid-market ERP in 2021 at a total cost of £680,000 (licence plus implementation). The go-live was broadly successful. The system covered warehouse management, inventory, finance, and customer billing.

In the thirty-six months following go-live, Forsyth raised twelve change requests with the vendor. The changes included:

• A new billing model for a major new client with bespoke rate structures
• A regulatory compliance change for temperature-controlled goods reporting
• An integration with a new carrier for parcel tracking
• Three workflow modifications as the business restructured its approval hierarchy
• A reporting module for a new service line

The total cost of the twelve change requests: £612,000. Excluding annual licence fees and support contracts.

Outcome:

Forsyth's total cost of ownership in years one through three was £1.29M against an original business case that projected £820,000 over the same period. The gap — £470,000 — was composed entirely of change request costs that were not visible at the point of sale.

The finance director's comment at the three-year review: "We budgeted for software. We should have budgeted for software dependency."

The Cost of Ignoring It

Direct financial cost: Change request fees compound over the life of the system. A business that assumes £50,000 per year in post-implementation costs and experiences £180,000 per year has a material budget problem by year three.

Speed cost: Change request delivery timelines measure in weeks and months, not hours and days. When a business needs to respond to a market opportunity, a regulatory change, or a client requirement, the system cannot keep pace. The competitive cost of being unable to change quickly is rarely measured but consistently significant.

Strategic cost: The business's strategy becomes constrained by what the system can accommodate within a reasonable change request budget. Product decisions, service design decisions, and go-to-market decisions are shaped not by market opportunity but by system flexibility. This is a subtle but pervasive distortion of strategic thinking.

Upgrade risk: Every customisation is a liability at upgrade time. Vendors release major upgrades that break customised configurations. The business faces a choice: pay to re-implement the customisation in the new version, or stay on an older version and lose access to new features and security patches. Neither option is cheap.

Negotiating leverage: A business that is dependent on a single vendor for every operational system change has no negotiating leverage. The vendor knows that switching cost is high. Change request prices reflect this.

What Good Looks Like

Systems designed for change — not just for implementation — share structural properties that enterprise software typically lacks.

Change is declarative, not procedural. In a well-architected system, changing a workflow means changing a description of what the workflow should do, not rewriting code. The system translates the description into behaviour. This makes changes auditable, reversible, and independent of vendor expertise.

Configuration is versioned. Every configuration change is tracked, attributed, and reversible. If a change breaks something, you roll back. The history of what changed, when, and why is always available. This is the structural property that keeps systems aligned with the business as it evolves — not better change management, but architecture that makes change safe by design.

Changes are testable in isolation. A proposed change can be applied to a test environment, validated against the existing system, and deployed to production once approved. The risk of a change breaking something that was already working is managed, not accepted.

The business controls its own configuration. The operational logic — workflow rules, approval hierarchies, finance triggers, reporting structures — is expressed in a format that the business can read, understand, and modify. It does not require vendor expertise to interpret. The absence of this property is precisely why ERP projects take eighteen months — the vendor's expertise is the bottleneck at every stage, from requirements through configuration through change.

ENTMAZ Perspective

The reason enterprise software costs more to change than to buy is that configuration opacity is architecturally embedded. The system stores its operational logic in a proprietary format that only the vendor can modify. This is not a design flaw — it is a feature of the vendor's commercial model.

ENTMAZ takes the opposite position. The operational logic of a business — how it approves things, how it triggers finance events, how it assigns work — is expressed in the compiled business model. The business model is readable, versioned, and modifiable through a structured change process. When the business changes, the model is updated. The update is compiled, validated, and promoted through TEST to PROD.

There is no change request. There is no vendor dependency for operational changes. There is no configuration opacity. The business model belongs to the business, expressed in a format the system can compile and the operator can verify.

The post-implementation cost model is predictable because there are no change request fees. The cost of change is the subscription. That is the entire bill.

Conclusion

Enterprise software that costs more to change than to buy is not a product failure. It is a deliberate commercial architecture. The vendor creates dependency at implementation, and then monetises that dependency for the life of the contract.

The business that buys an enterprise system is not buying software. It is buying a relationship with a vendor who controls the cost of every operational change the business will ever need to make. That relationship deserves to be priced into the original business case — which it almost never is.

The right question at the point of ERP selection is not "what is the implementation cost?" It is "what will it cost us to change this system in year three, when the business is different from the business we are today?"

The answer, for most enterprise software, is: more than you budgeted for.

Key Takeaways

• Enterprise software post-implementation change costs are structural, not incidental — configuration opacity creates vendor dependency by design
• Average post-implementation change costs for a mid-market ERP are £80,000–£200,000 per year over and above licence and support fees
• Change request timelines create a strategic constraint: businesses cannot respond to market, regulatory, or client requirements at operational speed
• The vendor's commercial interest is in systems that require their expertise for every change — this is not an accident, it is the post-sale revenue model
• Systems designed for change are declarative, versioned, and under business control — the cost of change is the subscription, not an additional line item