Should we rewrite our software platform?

1. Describe what the business cannot do

“The platform is old” can hide several different problems. A customer capability may be expensive to add. Releases may require extensive manual checking. A dependency may be approaching the end of support. Or the team may be struggling to explain the behaviour it has inherited. Each calls for a different investigation.

Write down the consequence in business terms and ask the team to show recent examples. For a slow change, follow where the time went: understanding behaviour, changing code, waiting for approval, testing, deploying or correcting defects. A platform replacement needs to address the actual cause of the delay.

Agree what improvement would count. That might be the ability to change a particular workflow safely, remove an unsupported component or onboard a customer without bespoke work. A new language or hosting model is a means of achieving that outcome.

2. Ask for evidence that separates the options

A useful assessment connects technical observations to the specific decisions ahead. Ask the team to explain both the constraint and the assumptions in its preferred remedy. Include operational staff and the people who understand customer exceptions; important behaviour may be absent from the documentation.

Change history

Examine a small selection of recent, relevant changes. Where did effort and waiting accumulate? Include an awkward example and a routine one; explain how representative they are.

Required behaviour

Identify the workflows, integrations, data and exceptions that must survive the transition. Decide which existing behaviours can be retired with business agreement.

Operating risks

Record support deadlines, recurring failures and dependencies on particular people. Distinguish an observed failure from a plausible risk that still needs testing.

Migration assumptions

Show how customers and data would move, how correctness would be checked, and how the business would continue operating while the transition is incomplete.

3. Compare credible ways forward

Ask for alternatives with a similar level of scrutiny. Comparing a detailed list of legacy problems with an idealised picture of a new platform gives the replacement an unfair advantage. Every option should explain its costs, continuing constraints and route to value.

Improve the existing system

A focused change to release verification, a high-change module or an operational process may remove the immediate constraint. It preserves existing behaviour, but deeper structural limits may remain.

Replace in stages

Move a bounded capability while keeping the rest running. This can expose migration problems earlier. It also creates temporary integration, data ownership and dual-operation work that must be funded and eventually removed.

Replace more broadly

A wider replacement may fit where the current design cannot meet essential needs or viable boundaries cannot be established. It requires confidence in behaviour discovery, transition capacity and the point at which the old system can close.

Buy, retire or simplify

Check whether the business still needs to own the capability. A purchased product or simpler workflow may reduce bespoke development, while introducing supplier, integration, migration and operating constraints.

4. Make the transition part of the proposal

“Build the new platform” is only part of the work. Someone must keep the existing service usable, handle changes requested during the build, reconcile data and help users adopt the result. A plan that leaves those responsibilities implicit is difficult to assess.

For each option, identify who owns the transition and where their capacity comes from. Include operating both versions, temporary connections, data validation, customer support and eventual decommissioning. Explain which assumptions are known, estimated or still untested. Avoid an exact completion date that depends on unresolved migration questions.

Choose an early slice that tests a material uncertainty. A representative workflow with real operational constraints tells you more than a polished demonstration that avoids the difficult integration. Agree what would count as a failed test as well as a successful one.

5. Check whether delivery is the first constraint

In James’s work with Pina Vida, the team was already partway through a multi-year modernisation programme. Completed and tested changes could wait months for a sponsored deployment slot. Releases required expensive overnight on-site verification.

James prioritised understanding the verification need, automated checks and smaller releases. Verification eventually became remote and releases became weekly, sometimes more frequent. These are approximate outcomes from his first-hand account of hands-on work with the team.

That account supports a specific lesson: examining how completed work reaches users can uncover an intervention worth making during a rewrite. It does not establish that the wider rewrite was unnecessary, or that another platform has the same constraint.

6. Decide what would change your mind

A recommendation should survive contact with new evidence. Record the conditions that would justify extending, narrowing or stopping the chosen approach. The decision becomes more useful when the team knows which uncertainty it is trying to resolve.

Evidence favouring a wider replacement

A tested limitation prevents an essential business capability; a material support constraint has no viable targeted remedy; or trials show that separating the relevant behaviour creates unacceptable operational risk.

Evidence favouring a smaller intervention

A bounded change removes the demonstrated constraint, or the major delay sits in verification, priorities or approval rather than the parts of the platform proposed for replacement.

Evidence requiring more investigation

The team cannot explain migration correctness, the proposed slice avoids the difficult behaviour, or the alternatives use incomparable assumptions. Commission the missing evidence before expanding the commitment.

7. Leave the discussion with an explicit decision

Bring the technical lead, business owner and operational stakeholders together around a short decision memo. Record the desired outcome, options considered, evidence, unresolved assumptions, owner and next review point. Attach the reasoning to the decision so it can be revisited without restarting the argument.

If a rewrite is already underway, assess the remaining work and value still to come. Make completed progress visible, along with the cost of changing course. Agree what remains worth pursuing and which original assumptions now need revision.