# Improve the software you have, or replace it?

> Separate a frustrating screen from a structural limitation, and compare improvement, extension, and replacement with evidence.

- Published: Sep 25, 2026
- Topic: Software decisions
- Author: RDR Digital
- Original: https://rdr.digital/blog/improve-or-replace-business-software

“We need a new system” can mean several things. Staff may dislike a screen. A supplier may no longer support a necessary integration. Or the business may have changed so much that the underlying process no longer fits.

Those are different problems. Start by naming the limitation before comparing replacement proposals.

## Make the complaint testable

Ask people to demonstrate the difficult task. Capture the current steps, the desired result, and the consequence of the gap. “Reporting is poor” becomes more useful when it means “the operations manager cannot identify unassigned work without combining three exports.”

For each problem, ask the current supplier or maintainer to explain the available options. Distinguish an existing setting from an extension, and an extension from a change to the core product. Request a working example when the answer affects your decision.

Include constraints that a polished interface cannot solve: access to data, supported integrations, continuing maintenance, and the ability to export records in a usable form.

## Compare three routes

The following is a discussion framework, not a scoring formula.

| Route                      | Evidence that could justify it                                     | What to investigate                                       |
| -------------------------- | ------------------------------------------------------------------ | --------------------------------------------------------- |
| Improve the existing setup | The main workflow fits, but configuration or usability is weak     | Whether the fix is supported and maintainable             |
| Extend a missing part      | A specific valuable task sits outside an otherwise useful system   | Integration access, data ownership, and failure handling  |
| Replace the system         | Essential requirements cannot be met within acceptable constraints | Migration, staff transition, dependencies, and retirement |

For an illustrative distributor, the stock system might remain useful while customers need a better way to request repeat orders. A portal could be worth testing before replacing stock management. That conclusion depends on the actual integration capabilities and operating arrangements.

## Consider a gradual transition where it fits

AWS describes the [strangler fig pattern](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/strangler-fig.html): functionality moves from an existing application to a replacement in stages, with routing directing requests to the appropriate system. Its guidance also describes added complexity, including the routing layer and data synchronization.

That is one architecture option, not a requirement to introduce microservices. Ask a technical reviewer whether your system can be separated safely at all. Shared records or tightly coupled processes may make an apparently small move much harder.

For a business owner, the practical question is simple: what can move independently, and what must continue working together? Request a diagram showing where active records live during each stage.

## Price the transition, not just the destination

Include data cleanup, imports, integrations, training, support during changeover, and the work required to close the old service. Identify contractual commitments and continuing subscriptions rather than assuming they disappear on launch day.

Decide how staff will know which system to use. If two systems coexist, assign responsibility for reconciling differences. Avoid a transition in which both are treated as the authority for the same field without an agreed conflict rule.

Our [data migration guide](https://rdr.digital/blog/planning-a-data-migration) covers the records side of that preparation.

## Make a decision with an exit condition

A useful next step might be a targeted improvement trial or a technical investigation of one integration. Give it a question, an owner, and a decision date.

Write down what would make you stop investing in the old setup, and what evidence would make replacement premature. This keeps the decision tied to the business problem rather than momentum.

If you choose to move gradually, define the pilot and the conditions for expanding it in a [phased rollout plan](https://rdr.digital/blog/planning-a-phased-software-rollout).

## Sources

- [AWS Prescriptive Guidance: Strangler fig pattern](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/strangler-fig.html)