A company buys a COTS CRM platform and heavily customizes it to match its exact sales process by directly modifying core workflow logic. Eighteen months later, upgrading to the vendor's new major version breaks most of the customizations. What went wrong in how the customization was done, and how should it have been managed instead?

## The failure pattern This failure pattern -- often informally called 'the COTS customization trap' or 'core hacking' -- happens when a team treats a bought platform's internals as if they were the team's own codebase, editing workflow engines, database schemas, or core business logic files directly instead of working through the interfaces the vendor designed for extension. It is one of the most common and expensive failure modes in enterprise software adoption, and it shows up across CRM, ERP, and content-management deployments alike. ## Core layer and extension layer Mechanistically, most mature COTS/SaaS platforms ship two layers: - **a core layer** the vendor owns, tests, and evolves under their own release schedule - **an extension layer** -- plugin APIs, configuration-driven workflow builders, scripting sandboxes (e.g., a CRM's formula/Apex-like language), webhooks, and custom-field frameworks -- that the vendor explicitly commits to keeping stable or migrating forward across versions. When customization stays inside the extension layer, a major version upgrade is the vendor's problem to keep compatible, because that's the contract the vendor is selling. When customization instead patches or overrides the core layer directly (modifying vendor source, injecting SQL that assumes a specific internal schema, monkey-patching a workflow class), the team has silently taken on the vendor's own maintenance burden without any of the vendor's foresight into what the next release will change. ## Why teams do it anyway This pattern exists because business stakeholders reasonably want the bought tool to fit their process exactly, and the extension layer sometimes feels slower or more limited than just editing the thing directly, especially under deadline pressure. Teams rationalize core modification as a shortcut, not realizing they are trading a one-time convenience for a recurring, compounding liability. ## The trade-off The trade-off is stark once framed correctly. - **Customizing through supported extension points** costs more up front -- the extension APIs are often less flexible than raw code access, forcing some workflow compromises, and the team has to learn the vendor's specific extension model. In exchange, upgrades remain the vendor's responsibility, support tickets stay valid (many vendors refuse support once core files are modified), and the customization survives version changes because the vendor tests the extension layer's backward compatibility as part of shipping every release. - **Modifying the core layer directly** is faster today and gives unlimited flexibility, but every subsequent vendor release becomes an unplanned, uncontrolled migration project, support contracts are frequently voided, and the team ends up doing bespoke-software maintenance work while still paying full SaaS/license fees for a product they can no longer safely upgrade. ## In production In production, this failure shows up as: - an upgrade that was supposed to be a routine, low-risk vendor release turning into a multi-week fire drill because dozens of core-modified workflows silently broke - a vendor support ticket being rejected with 'this system has been modified outside supported parameters, please restore to baseline before we can assist' - a company deliberately staying multiple major versions behind current because nobody can afford the migration, which then means missing security patches and losing features other customers get for free Over time this often forces exactly the outcome the company was trying to avoid by buying in the first place -- a de facto in-house maintenance team, but now maintaining someone else's codebase instead of one designed for extension. ## A real-world pattern A well-known real-world pattern of this is enterprise ERP and CRM deployments where organizations directly modified vendor source code (a practice long associated with heavily customized SAP and PeopleSoft installations) rather than using the vendor's sanctioned customization layers (like SAP's user-exits/BAdIs or Salesforce's Apex/Lightning framework), and later found upgrades so expensive and risky that they either skipped years of releases or undertook costly 're-implementation' projects to strip out the core modifications and rebuild the same behavior through supported extension points. Some of these projects took longer and cost more than the original implementation, because untangling years of accumulated core patches from a live production system, without breaking the business processes running on it, is inherently riskier than building against a stable interface from day one. ## The lesson The lesson generalizes beyond any single vendor incident: when buying a platform, the build-vs-buy discipline of protecting only the genuinely differentiating slice of work applies again, one layer deeper, at the customization layer itself. Customize the thin part of the workflow that is truly unique to the business, through the vendor's supported extension surface, and accept the vendor's default behavior for everything else, rather than re-fighting the commodity-vs-differentiating battle by hand-editing code that the vendor never intended anyone outside their own release process to touch.