Modernisation decision
Modernisation Assessment
Choose what to keep. Be precise about what must change.
We first establish what your system does and what it depends on. Then we compare hardening, refactoring, re-architecting, replacing and stopping against the constraints of your actual product or estate, and recommend a path.
What you receive
The result of this engagement.
A justified choice between retaining, hardening, refactoring or replacing, based on what the system does today, with the sequence and conditions for the chosen path.
- A validated view of what the system does, what it depends on and which parts are sound.
- An option comparison covering retain, harden, refactor, re-architect, replace or stop as relevant.
- A defensible recommendation with cost/time assumptions and confidence limits.
- A transition sequence, boundary map and exit criteria for the chosen path.
When this helps
Recognise the situation.
- AI coding tools make a rewrite look cheap, but no one has checked what the current system does.
- A rewrite is being proposed without a clear comparison of alternatives.
- A review has exposed problems, but the response is still disputed.
- You need a credible sequence that protects useful capability while addressing structural risk.
How it works
Evidence appropriate to the question.
Establish what the system does
Investigate the code, data, integrations and operating evidence that matter to the decision, and the business functions the system supports. Adequate existing evidence, such as an audit or discovery, can shorten this step.
Compare credible options
Assess boundaries, cost and time assumptions, operational risk, reversibility and implementation dependencies.
Recommend a path
Explain the preferred option, rejected alternatives, sequencing and conditions for revisiting the decision.
Implementation handoff
From a chosen path to delivery planning
The handoff identifies the preferred option, rejected alternatives, boundary changes, sequence and exit criteria. Cost and time assumptions remain decision models with stated confidence, not delivery commitments.
Your engineers use that direction to plan and estimate. Further design is useful only where unresolved interfaces, data or operating boundaries need it; the recommended path does not automatically require a full blueprint.
Scope & responsibility
Agree the scope and depth. Keep the boundaries clear.
Scope of the engagement
The work starts by establishing what the existing system does and depends on, within an agreed boundary. Adequate evidence from an earlier assessment, ours or another provider's, can shorten that step. No prior purchase is required.
Limits of reliance
Estimates are decision models with stated confidence, not delivery guarantees. Detailed design and implementation are agreed separately.
The agreed scope of the engagement sets the coverage, deliverables, responsibilities, timing and fixed fee. Any change to the scope is agreed in writing.
Relevant experience
Read the work in its actual context.
Questions
Before you book.
Will you recommend a rewrite?
Only if the evidence and option comparison justify it. Retaining sound architecture and hardening a specific area may be the better response.
Can our existing audit be the starting point?
Yes, if it provides an adequate and relevant baseline. We identify evidence gaps before agreeing the scope.
How long does it take?
A quick path recommendation for a small system usually takes about a week. A full assessment usually takes two to four weeks, longer for a large estate. We agree the timing and a fixed fee before work starts.
Related work
Related services
Each is available as a standalone service when the evidence and scope support it.
What's the decision in front of you?
Tell us the situation and what you intend to commit to. 25 minutes on Teams, no preparation needed. If this scope is not the right fit, we will say so.