When change isn’t the right kind of progress

In the fast-paced world of software development, change is often celebrated as a sign of progress. New versions promise improved performance, enhanced security, and shiny new features. Consequently, for many organisations, upgrading feels like the natural next step. But is it always the right move? The reality is more nuanced. Sometimes, the most strategic decision is to stay put. After all, change doesn’t come free from costs, risks and challenges.

Business dependency

Every product begins with a vision, evolves through continual development that culminates in numerous releases, and eventually reaches retirement. This lifecycle is well understood in technology circles. However, what’s often overlooked is the business perspective, particularly the deep dependency businesses form on specific versions of software. Over time, entire processes and even cultural norms become intertwined with a product’s capabilities.

When a version of software delivers everything your business needs, both reliably and efficiently, why change? For many organisations, that version becomes the backbone of critical operations. It’s not just a tool; it’s infrastructure. Altering it can feel like replacing the foundation of a building just because a newer material is available.

There are many examples of this, you’ve probably experienced this personally too, that a piece of software does exactly what you need it to, just for that familiar and reliably robust experience to be shattered with an undesired latest brand-new release.

Change isn’t free

Upgrading software isn’t just a technical exercise: it’s a business transformation. Every change introduces risk: risk of downtime, risk of incompatibility, risk of disrupting finely tuned processes. Costs are incurred in retraining staff, rewriting integrations, and revalidating compliance. For industries where precision and reliability are paramount, financial services, healthcare, manufacturing, these costs can be significant.

Moreover, change for change’s sake diverts resources from initiatives that create genuine value. Instead of investing in innovation or customer experience, for example, teams are consumed by technical projects that offer questionable gains. In a world where competitive advantage depends on focus, this misallocation can be detrimental.

Current doesn’t always mean better

There’s an accepted norm that staying current is synonymous with staying secure and efficient and aligned with best practice. Whilst there are indisputable benefits from some upgrades, it’s not universally applicable. Mature software versions often receive long-term support, ensuring stability without mandating upgrades. For businesses that prioritise reliability and stability over significant new features, these mature versions can be a sensible safe harbour.

Sometimes factors other than features and functionality become a powerful catalyst for change, for example, significant licensing changes that alter the economics of the platform, placing increased pressure on budgets and operational costs.

The question becomes: does the benefit justify the investment and the risks?

The answer comes very much in the form of ensuring you know why you are upgrading. Upgrades should be driven by clear, measurable benefits and risks should be fully understood, they should not be driven by the fear of being “left behind” or the desire to be “current”. If the current version meets your operational needs, complies with regulatory requirements, and integrates seamlessly with your ecosystem, the desire to upgrade may be more cultural than practical.

Open-Source advantage

This is where open-source software introduces a compelling alternative (read about our commitment to open source). Unlike proprietary products, where the vendor dictates the roadmap and retirement schedule, open-source solutions empower users to take control. If a version works perfectly for your business, you’re not at the mercy of a vendor’s lifecycle decisions. A group of interested parties, vendors, customers, and community contributors, can maintain and evolve the product indefinitely.

This collaborative model offers two major benefits:

1. Longevity without lock-in

• Continue using a stable version without fearing forced obsolescence.
• If/when official support ends, the community (including your own teams) can step in to provide patches, security updates, and even new features.

1. Direction driven by real needs

• Development priorities reflect actual business and user requirements, not vendor roadmaps.
• Community focus ensures that resources are spent on improvements with tangible business value.

Fluxnova: A real-world example

A great example of this principle in action is Fluxnova, the open-source fork of Camunda. When Camunda announced a licensing change for their product, many organisations faced uncertainty about the future of their workflow platforms. Rather than being locked into a vendor-driven roadmap, a core community rallied with FINOS (Fintech Open Source Foundation) to create Fluxnova, publicly launched in October 2025. Read more about Scott Logic’s Fluxnova Migration Service.

Fluxnova (Project Page on FINOS’s GitHub Repo) offers a choice for those where an upgrade isn’t their chosen path; the current version does what is needed and underpins a vast array of business-critical processes. In this scenario, new features aren’t as valuable as being able to maintain the current business operations and continuing to use a familiar, stable product without disruption.

Critically, Fluxnova now gives those business consumers a voice in its evolution. Fluxnova (GitHub Repo) is governed by a consortium of maintainers, ensuring that its development aligns with real-world needs rather than commercial pressures. For organisations heavily invested in Camunda workflows, Fluxnova provides continuity, control, and confidence, demonstrating the power of open-source governance in safeguarding critical systems.

Fluxnova’s journey isn’t a new path, it’s a well-trodden one: OpenTofu fork of Terraform (2023), OpenBao fork of HashiCorp Vault (2023) and Valkey fork of Redis (2024). Similar examples are likely to emerge in the future.

Keep what works: improve what matters

To clarify, this isn’t an argument against progress. Continual product development is vital for addressing emerging needs and advancing technology, but progress and change should be both purposeful and warranted.

Organisations must assess the tangible benefits of upgrading against the costs, risks and challenges it poses. In some situations, the smartest move is to channel resources into areas that drive growth, new products, better customer experiences, operational efficiencies rather than chasing version numbers.

Change is not inherently valuable; its value lies in the outcomes it delivers. For businesses deeply invested in a particular software version, staying put can be a sign of wisdom, not stagnation. And when that version is open source, the power to sustain and evolve it lies in your hands. The goal isn’t to resist progress but to pursue it with intention where and when it matters most.