Digital transformation

The word covers a lot of expensive failures, so it is worth being precise about what we mean. A transformation programme here is a sequenced set of the other practices in this register, ordered so that each stage delivers something usable and funds the argument for the next. Not a two-year rebuild that goes dark. Portside Insurance ran eighteen months this way: document intake first because it was the visible pain, then the policy administration replacement behind a routing layer, then the customer portal — with the legacy system serving traffic until the last month.

• 01

  Sequenced by value and risk, so something reaches production in the first quarter rather than at the end of year two.

• 02

  The legacy system keeps running throughout. Capabilities move one at a time behind a routing layer, and rollback stays available at every step.

• 03

  Business cases per stage rather than one for the programme. A stage that stops making sense is stopped, which is only possible if the funding is staged too.

• 04

  Change management treated as delivery work. Training, process redesign and the people whose job actually changes are in the plan, not appended to it.

• 05

  Measured against the operational numbers agreed at the start — cycle time, cost to serve, error rate — not against completion of a plan.

1. 01

   Estate and opportunity survey

   Four to six weeks. Every system, integration and manual process, with its cost and its fragility. Instrumented where possible: what the systems are actually doing beats what anyone remembers.

2. 02

   Sequence and business case

   A dated sequence of stages, each with its own cost, benefit and stopping point. The first stage is chosen to be visibly useful and low risk, because the programme has to earn its second year.

3. 03

   Routing layer

   A facade in front of the legacy entry points so capability can move incrementally and traffic can be switched back. Nothing else can be delivered safely until this exists, so it is built first.

4. 04

   Stage delivery

   Each stage runs as a normal project from this register — a build, an integration, an automation — with its own increments, its own parallel run, and its own measured outcome.

5. 05

   Decommission and transfer

   Retired systems are switched off and the saving is recorded, and the client team takes ownership stage by stage rather than all at once at the end.

• Estate inventory with cost, fragility and dependency mapping.
• Sequenced programme plan with a business case and a stopping point per stage.
• Routing and facade layer in your repositories.
• Delivered stages, each with its own measured before-and-after.
• Decommissioning record: what was switched off, when, and the annual cost it removed.
• Capability transfer plan and its evidence — who now owns what, and since when.

• 01How is this different from a series of separate projects?

  Mostly it is not, and that is deliberate — the failures come from treating it as one indivisible thing. What the programme adds is a sequence, a routing layer that lets capability move incrementally, and one architecture so the projects do not each invent their own identity model. If someone is selling you an indivisible two-year transformation, ask what ships in the first quarter.

• 02Can we do this without freezing new feature work?

  Yes, and you should plan to. A feature freeze is what makes these programmes politically unsurvivable. Product work continues against the current system, and the routing layer means each migrated capability picks up interim changes during its parallel-run phase.

• 03What if we lose confidence halfway through?

  Then you stop, and you keep what has been delivered. That is the point of staging both the delivery and the funding: every stage ends with a working system and a decision point, rather than a half-finished platform that only has value if the remaining budget is approved.

• CON

  IT consulting

  Architecture, technology strategy and second opinions — fixed fee, and delivered as a document you can act on without us.

  /services/it-consulting
• AUT

  Business automation

  Removing the manual steps between systems — workflow, document handling, sales and service processes, with or without AI.

  /services/business-automation
• CSD

  Custom software development

  Business systems built for how your operation actually runs, when the off-the-shelf product would need bending until it breaks.

  /services/custom-software-development