"Modernise" is one of the most expensive words in technology, because it so often arrives meaning "rebuild". The old system is slow, ugly or hard to change, so the obvious response is to replace it with something new, preferably on a modern platform. Rebuilding has the appeal of a clean start. It also has the track record of overrunning, and of rebuilding the parts that were fine along with the parts that were not.
Rebuild is one option, not the default answer. Most estates are a mix: some capabilities work and should be left alone, some have sound business logic trapped in a poor design, some genuinely cannot meet the outcome, and some should not exist at all. The architect's job is to tell these apart, capability by capability, and to resist the pressure to treat the whole system as one decision.
This part sets out a simple model for doing that, explains how it relates to the familiar cloud migration "Rs", and shows what the series' fictional bank decided once discovery had told it what problem it was solving.
Four options, three questions
The model has four outcomes.
| Option | Use when | Watch for |
|---|---|---|
| Reuse | The capability works and can be integrated safely | Hidden operational dependencies |
| Refactor | The design limits change, but the business behaviour is still right | Scope expansion |
| Replace | The capability cannot meet the required outcome or controls | Migration and adoption risk |
| Retire | The capability is redundant or no longer creates value | Records, retention and downstream consumers |
We reach them through three questions, asked in order, of each capability rather than of the whole system.
Does the capability still create value? If not, retire it. This question comes first because it is the cheapest outcome and the one most often skipped. Teams migrate, refactor and test things nobody needs, because nobody asked.
Can it meet the outcome and controls as it is? If yes, reuse it. Reuse does not mean ignore. It means integrating with it deliberately, through a supported interface, with its operational quirks understood.
Is its business behaviour still valid? If the logic is right but the structure makes it hard to change, test or integrate, refactor. If the behaviour itself is wrong for the outcome, replace it, whether with a product, a service or new code.
Rebuilding from scratch is a form of replace, and it only appears at the bottom of the tree, after three chances to choose something cheaper.
How this differs from the migration Rs
Readers who work in cloud will recognise the family resemblance to the migration strategies the major providers publish. AWS describes seven: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. Microsoft's Cloud Adoption Framework lists eight: retire, retain, rehost, replatform, refactor, rearchitect, rebuild and replace (both checked on 14 October 2026). We used those vocabularies in our series on choosing a treatment for every workload.
They answer a different question. The migration Rs assume a workload is moving to the cloud and ask how it should travel. The four options here come earlier and ask what should happen to a capability to meet a business outcome, wherever it ends up running. A capability can be reused and never move. A replaced capability might be a software-as-a-service product, a new service in the cloud or a change to a rule on paper.
The order matters. Decide the system treatment against the problem first; decide hosting and migration path second, for the parts that are changing. Do it the other way round and the migration strategy quietly becomes the modernisation strategy.
What Klipspringer decided
Klipspringer Bank is fictional, and its systems and figures are illustrative. By this point the bank had a signed problem statement: cut decision time from five to seven working days to the same day for at least 60% of applications, and abandonment from 35% to under 15%, without weakening affordability, fraud or credit-risk controls. Each component in the loan journey went through the three questions against that statement.
The online application front end: refactor. It worked, customers completed it at a normal rate, and its business behaviour was right. Two parts needed changing: the upload step, which accepted incomplete and unreadable documents, and the absence of any progress information after submission. The board's original request, a complete rebuild, shrank to those two pieces of work.
The loan origination system: reuse. The vendor package that manages applications, decisions and loan set-up was sound, supported and already integrated with the credit bureaux. It exposed a documented interface for creating and updating applications. Replacing it would have consumed most of the budget and moved neither measure. The watch-out was operational: it ran a nightly batch that locked records for two hours, which any new component would have to respect.
The underwriting spreadsheet: replace. The rules that decided which applications needed manual review lived in a spreadsheet maintained by two underwriters, with no version history and no test cases. The behaviour was not wrong so much as unmanageable. It moved into a small, versioned decision service owned by credit risk, with each rule change tested against past applications before release.
The manual document check: replace. Underwriters were spending much of their review time confirming that documents were present and legible. That check moved to the moment of upload, so incomplete applications are caught while the customer is still on the page, not two days later.
Email and fax intake: retire. A small number of broker applications still arrived by email and, remarkably, fax. Discovery found they made up under 2% of volume and generated a disproportionate share of rework. They were moved to the broker upload route. The watch-outs were real: the bank's records-retention obligations for existing applications, and one broker system that still sent a nightly email nobody had known about.
Core banking: reuse. The Part 3 finding, that existing customers' transaction data could stand in for uploaded bank statements, was implemented by reading it through a feed that already existed. Core banking itself was not changed.
Two components replaced, one refactored, one retired, two reused. The two largest systems in the journey were left alone.
Where the cloud came back in
The original request was for a cloud migration, and it did not vanish. It became narrower and better defined. The new decision service and the document-checking pipeline were new components with no existing home, and Klipspringer already had a cloud landing zone approved by its security and risk teams. Those two components were candidates for it, subject to the same data-residency, security and outsourcing reviews any regulated workload goes through.
The loan origination system and core banking stayed where they were. Nobody argued that they should never move. They simply had no reason to move as part of this programme, because moving them would not change decision time or abandonment. If a separate business case for migrating them appears later, it can be made on its own merits.
The watch-outs are part of the plan
Every option carries a characteristic risk, and the risk should be in the plan from day one rather than discovered at go-live.
Reuse fails through hidden dependencies: the nightly batch, the undocumented file share, the report someone in finance runs every month end. Map how the system is actually operated, not only how it is integrated.
Refactor fails through scope expansion. Once the upload step is open, someone will suggest redesigning the whole form. Hold the line to what the problem statement requires.
Replace fails through migration and adoption. Data has to move, people have to change how they work, and the old and new will run side by side for longer than planned.
Retire fails through forgotten consumers and records. Something always depends on the thing you switch off, and some of what it holds must be kept.
Key points
Rebuild is one option, not the default. Most estates need a mix of answers, decided per capability.
Ask three questions in order. Does it still create value, can it meet the outcome as it is, is its business behaviour still valid?
The system treatment comes before the migration path. The cloud Rs answer how a workload travels; this answers whether and how it should change at all.
Klipspringer's largest systems were left alone. The changes that moved the measures were small and specific.
Plan for each option's characteristic risk. Dependencies, scope, adoption and forgotten consumers.
Next: Part 5, The architecture views needed to make a decision. All parts are on the series page.
How CloudNala can help
We help teams decide what to keep, change, replace and switch off, one capability at a time, against a problem statement the business has agreed. That usually shrinks the expensive parts of a modernisation programme and makes the remaining ones easier to defend, and it gives the cloud conversation a clear and limited scope rather than an open-ended one.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Architecture Discovery Sprint or write to us at consult@cloudnala.co.za