Customizable enterprise software: a decade old trap
·
Vendors sold customization as a way to fit software to the business. It also made leaving expensive, and subscriptions charged for that expense every year.
Enterprise software has sold the same promise for thirty years: it will not force your process into someone else's template. Change the fields, the workflows, the screens, and the rules, and make it fit.
A finance team adds approval steps, a support team builds escalation logic, a product team wires a release gate to a test suite, and consultants map all of it onto how the company works.
The bill for that work arrives later, and not on an invoice. The more the software fits, the harder it is to replace.
The playbook
SAP ran it first. Customers spent years encoding operations into ABAP modifications, custom tables, and user exits, until the system became the company's institutional memory. Every upgrade then had to account for every modification, and the vendor's roadmap and the customer's codebase were welded together.
Atlassian copied the model with Jira. Server licenses were affordable, the plugin marketplace was enormous, and teams could bend workflows, custom fields, and automation to almost anything. In 2020 Atlassian announced that Jira Server would reach end of life, with support ending in February 2024, and moved customers to Cloud or Data Center. Both carry annual subscription pricing, and Data Center has seat minimums. Custom fields, scripts, and Groovy logic written years earlier did not travel cleanly.
Why customization creates lock-in
Export your data and you get rows, issues, comments, and attachments. You do not get behavior. Most of the value sits in the rules between the records: which fields appear for which issue type, what happens when a status changes, who gets notified. That logic lives as configuration inside the vendor's product.
A new tool takes your data and asks your team to rebuild the logic. Nobody can fully describe it, because it accumulated over years, one request at a time. The customization that made the product fit is the reason you cannot leave cheaply.
Subscriptions turn the screw
Perpetual licenses had a floor: you bought a version, you ran it, and support renewal was a real choice. Subscriptions remove that floor. Access depends on a recurring payment, and the vendor sets the price. Renewal is also when the vendor re-prices your position in the market.
Customization raises the cost of leaving. Subscription raises the cost of staying. The floor moves on the vendor's schedule too: features migrate to higher tiers, seat definitions widen, and usage limits appear where none existed before.
What to look for instead
Customization has a legitimate place: every company has rules no vendor will build. The question is who controls it, and what happens when the relationship ends.
How Windshift answers this
Windshift's core is open source under AGPL v3, so it can be inspected, patched, run, and forked. Why Windshift is open source covers what that means in practice. Plugins run as WebAssembly modules through Extism with a defined set of host functions, so custom behavior keeps a boundary. When a team does leave, the migration tooling brings records and structure across, not just rows.
You can download a release, run it on your own hardware, and keep running it for as long as you want, whether or not we are still around to help. If we ever take the product in a direction you disagree with, you can fork it and carry on.