Most proposals contain a beautiful target architecture. Clean boxes, tidy arrows, every legacy system gone. It is the picture everyone wants to believe, and it is usually the least interesting diagram in the document.
The client does not live in the target. They live in the mess they have today, and they will live in a series of half-finished states for months or years before the target arrives. The question a sceptical evaluator is really asking is not “is this a good destination?” It is “how do we get there without breaking the service on the way?”
This part of the series is about answering that question. It covers the as-is (how things work today), the to-be (the destination) and, most importantly, the bridge states in between.
We are still following our running example. Rivermark Water is a fictional regional water utility with about 380,000 customer accounts, and Ridgeline Digital is the fictional delivery partner bidding for its Customer Self-Service and Case Management Platform. All figures are illustrative. The complication that shapes this whole part was found in discovery (Part 3): Rivermark’s 20-year-old billing system has no supported way for other systems to write data into it, and replacing it is a separate procurement that is not part of this contract.
Why the target is only half the answer
Imagine renovating the kitchen of a house you still live in. The drawing of the new kitchen matters, but the family still needs to eat every day of the renovation. So somebody sets up a temporary kitchen in the garage: a kettle, a microwave, a fridge on an extension lead. It has to actually work, and if the builder is delayed, the family may cook in the garage far longer than planned.
Transition architecture is the plan for the garage kitchen. It explains four things a target diagram never does:
- Coexistence: which old and new systems run side by side, and for how long.
- Sequence: what moves first, second and third, and why in that order.
- Dependencies: what has to be true before each step can happen.
- Retirement: when each old thing is switched off, and what proves that is safe.
A technically sound target is commercially useless if the organisation cannot reach it safely. Evaluators know this, even when the RFP does not ask for a transition plan in so many words.
As-is: describe only what the change touches
The as-is view is a picture of today. The temptation is to document everything the client owns, because it looks thorough. Resist it. Show only facts relevant to the change:
- the systems involved and who owns them;
- the major flows of work and data, and where data is stored;
- constraints and technical debt, meaning the shortcuts of the past that now limit the options;
- the manual workarounds that fill the gaps;
- current service levels and recurring incidents;
- licence, contract and lifecycle deadlines;
- the interfaces that must keep working during the change.
For Rivermark, that means: fault reports arriving by phone, email and a WhatsApp number that three agents monitor by hand; an ageing ticketing tool in the contact centre; field jobs allocated from a spreadsheet, although field staff already use a licensed mobile job app with a supported API; and the billing system, which offers read-only database views and a nightly batch file export but no way to write data in. Its vendor support ends in 30 months.
It does not mean Rivermark’s asset management or HR systems. This bid never touches them, so documenting them would add pages and subtract clarity.
To-be: the destination, marked honestly
The to-be view shows where the client will end up. It should cover the intended business capabilities, which application is responsible for what, who owns each kind of information, how systems will exchange data, the platform it runs on, the security controls and the operating model (who runs it day to day).
Just as important: mark the decisions that are still provisional. In the Rivermark bid, the choice of WhatsApp messaging provider was marked as provisional, because one clarification answer was still outstanding: whether that provider would process customer messages outside South Africa. Labelling it openly told evaluators that Ridgeline knew the question mattered, rather than hiding a guess inside a clean diagram.
Bridge states: the steps in between
A bridge state is a stable, working arrangement between today and the target. Each one must be something the client could live with for a while, because plans slip.
Ridgeline’s transition for Rivermark had two bridges.
Bridge 1, before the 1 July tariff change. Fault reports and their status move onto the new case management platform. The customer portal and the WhatsApp channel go live. Customers can see their account balance and last bill, read directly from the billing system’s read-only views. Nothing is written back to billing. Manual monitoring of the WhatsApp number stops. Faults come first because, as the sponsor made clear in Part 2, repeat calls chasing fault status are the bigger load on the contact centre. The bridge also separates what Rivermark needs soon from what takes longest: the billing system’s eventual replacement.
Bridge 2, after a parallel run. Billing queries, disputes and payment-arrangement requests also become cases. Because the billing system cannot accept writes, payment arrangements are placed in a back-office queue, and trained staff key them into billing, with a daily report of anything not yet posted. Once the old ticketing tool and the new platform have run side by side long enough to trust the new one, the old tool is retired.
To-be, at the end of transition. The field job app is integrated, so jobs no longer start life in a spreadsheet. Reporting sits in one place. And the connection to billing is built as a separate adapter, so that when Rivermark eventually replaces its billing system, only the adapter changes. The portal, WhatsApp channel and case management do not need to be rebuilt.
Notice the bar running underneath all four states: the old billing system is present in every one. That is not a design failure. It is the honest shape of this client’s situation, and showing it makes the rest believable.
Every bridge must be supportable. Temporary integration often survives for years. If Rivermark’s billing replacement is delayed by two years, Bridge 2 needs to be monitored, documented and owned as if it were permanent.
Choosing a transition pattern
There are a handful of well-known ways to move from old to new. Each suits some situations and carries its own main risk. The right column shows where each one appeared, or did not, in the Rivermark bid.
| Pattern | What it means in plain terms | Use when | Main risk | In the Rivermark bid |
|---|---|---|---|---|
| Big bang | Switch everything over in one go | Scope is small, coexistence is impossible, or a hard event forces cutover | All the rollback risk lands on one weekend | Not used |
| Strangler | Move capabilities across a piece at a time behind a stable front door, until the old system has nothing left to do | Capabilities can move incrementally | The old system never retires unless exit gates are set | Used, request type by request type |
| Parallel run | Run old and new side by side and compare results | Outputs must be compared before trust moves | Double the operating effort, plus reconciliation | Used before retiring the ticketing tool |
| Rehost | Move the system to new infrastructure, largely unchanged (“lift and shift”) | Leaving a data centre matters more than improvement | The debt and cost profile move with it | Not used |
| Replatform | Move with limited changes to use managed services | Real value is possible with little code change | Compatibility and operating surprises | Not used |
| Refactor | Restructure or rewrite the code | Differentiation, scale or maintainability justify it | Time, regressions and estimation uncertainty | Not used |
| Replace or SaaS | Adopt a standard product instead | A standard capability fits | Customisation, migration effort and vendor dependence | Case management replaces the ticketing tool |
| Retire | Switch a capability off | It no longer provides enough value | Unknown users and records that must be kept | The ticketing tool and the job spreadsheet |
| Encapsulate | Keep the old system but hide it behind stable interfaces | The old system must stay for now | The wrapper becomes a permanent bottleneck | The billing system behind a read-only adapter |
Real transitions combine several patterns; Rivermark’s used five. Naming them shows an evaluator that each part of the estate has a deliberate route.
The strangler pattern, explained
The strangler pattern takes its name from the strangler fig, a plant that grows around a host tree until the tree is no longer needed. In software, a routing layer (often called a facade) sits in front of the old and new systems. Requests go to the new system once their part has moved, and to the old system until then. Over time, the old system has less and less to do, until it can be switched off.
The most important decision in a strangler plan is the unit being strangled. It could be a business capability, an API operation, a product, a customer group, a region or a step in a process. For Rivermark, the unit was the request type: fault reports first, then billing queries and disputes, then payment arrangements. Customers noticed nothing except that things got faster.
This is why “we will migrate incrementally” is not a plan. Until the unit is named, nobody can say what moves first, what “done” looks like for each step, or when the old system can be retired.
Eight questions every bridge must answer
A bridge that cannot answer these questions is a hope, not a design. Here is how Ridgeline answered them for Rivermark’s Bridge 2, the harder of the two.
| Question | Rivermark Bridge 2 answer |
|---|---|
| Where is the system of record? | Billing remains the record for balances and payments. Case management is the record for each query and its history. |
| How are identifiers mapped? | The customer account number is the shared key. Old ticket numbers are mapped to new case references for the length of the parallel run. |
| How is data synchronised and reconciled? | The nightly billing export is compared with posted payment arrangements. A daily report lists anything unposted after two working days. |
| What happens if either system fails? | If the billing views are unavailable, the portal shows the last known balance with the time it was read, and queues the query. If case management is down, agents follow a documented manual procedure. |
| Who supports both environments? | Ridgeline supports the new platform, Rivermark’s IT team keeps billing, and the ticketing vendor’s support stays in place until retirement. |
| Which approval permits the next wave? | Two weeks of parallel run with no unreconciled items, sign-off from the contact centre manager and approval from the change board. |
| What proves retirement is safe? | No open tickets left in the old tool, reports rebuilt, records archived under the retention rules, and integration logs showing no remaining callers. |
| How are duplicate costs handled? | The old ticketing licence overlaps for two months. That cost is priced and shown in the commercial response, not absorbed silently. |
The last row matters more than it looks: running two systems at once costs money, and a transition that ignores it is under-priced. That is where the next part picks up.
What to take from this part
The target is only half the architecture. Evaluators judge believability by how you get there, not only by where you end up.
Describe the as-is narrowly. Only the systems, flows and constraints the change actually touches.
Design bridge states as real services. Each one must be supportable, because temporary arrangements routinely outlive their plans.
Name the unit being strangled. “Migrate incrementally” becomes a plan only when you say what moves, in what order, and what proves it is done.
Answer the eight bridge questions in writing. System of record, identifiers, reconciliation, failure, support, approval, retirement proof and duplicate costs.
Next in the series: Architecture and price must describe the same solution.
How CloudNala can help
We help bid teams turn a target architecture into a transition an evaluator can believe: a narrow as-is, bridge states that can each stand on their own, a named strangler unit and written answers to the eight bridge questions. It is usually the section of a proposal that changes the most once someone asks, out loud, what happens if the plan runs late.
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 a Bid Review or write to us at consult@cloudnala.co.za