The layer nobody funds until it fails

The money goes to the visible layer — new platforms, new interfaces, new vocabulary — while the operation underneath keeps working the way it always has. The technology lands and the benefit does not, because nobody changed the process the technology was supposed to serve.

Wrenwell starts from one question and keeps returning to it: what will this let the organisation do that it cannot do today? Everything else follows. If a business case cannot answer that in operational terms, the problem is with the case itself, and it’s cheaper to find that out before procurement than after go-live.

Wrenwell leads digital change from business case through to embedded operation: platform replacements, system and data migrations, and digitised ways of working. Wrenwell also acts independently where an organisation needs scrutiny of a vendor, an integrator, or its own optimism about a go-live date.

Digital delivery

  • Platform & System Replacement — Complex replacements led from selection through cutover, with the operating requirements kept in front of the technology decision. The alternative is reverse-engineering your process to fit whatever was bought, which is how organisations end up with a platform nobody wanted.
  • Migration Delivery — Data, process and operational migration managed as a first-class delivery risk, with its own plan, owner and rehearsal schedule. Migration is routinely under-resourced relative to the damage it can do.
  • Digital Ways of Working — Workflow, role and collaboration change designed alongside the technology and embedded with it. Adoption gets planned in the first sprint, while it is still cheap.

Digital assurance

  • Business Case Integrity — Benefits restated in operational terms and tracked against delivery as it proceeds. It gets said early when the case has quietly stopped being achievable, so the decision to continue is a real decision.
  • Vendor & Integrator Oversight — Independent scrutiny of partner delivery, commercial claims and change requests. The contract and the burn-down get read together, because the two usually tell different stories.
  • Cutover & Transition Readiness — Go-live decisions made against evidence defined in advance. That line gets held when the date starts driving the assessment, which it always does.

How an engagement runs

  • Interrogate — Test the business case against what the operation actually needs and can absorb.
  • Scope — Define delivery, migration and adoption as one programme with a single owner.
  • Deliver — Build, migrate and rehearse, with readiness assessed continuously and not only at the end.
  • Cut over — Go live against pre-agreed criteria, then stabilise before the team is stood down.
A cutover weekend, hour by hourTen steps across a cutover weekend. Five are go or no go decisions, each with its own evidence test. After Sunday afternoon the fallback window has closed.FRI 18:00Business freeze beginsFRI 20:00Final readiness call, go or no goevidence: criteria signed by each named ownerFRI 23:00Source systems locked, backup verifiedSAT 02:00Data migration run beginsSAT 06:00Reconciliation, counts and control totalsevidence: variance inside agreed toleranceSAT 12:00Integration and interface verificationSUN 08:00Business verification by operational ownersevidence: scripts passed, not opinions offeredSUN 16:00Open to users, or invoke fallbackevidence: all three above, or fall backMON 06:00First business day under supervisionMON 09:00Stabilisation review, stand down or holdevidence: defect rate and volumes inside tolerancePOINT OF NO RETURN
Reconciliation opens the gate, not the clock. After Sunday afternoon there is no fallback, which is why the decision is taken on Saturday morning.

What prompts the call

  • A platform replacement is underway and the operating model has not been touched.
  • A go-live date is fixed and readiness is being asserted without evidence.
  • An integrator is behind and the commercial position is unclear.

Where this has been done. A legal technology consultancy delivered document platform implementations as lift-and-shift or as transformation, matched to what each client was actually buying, to ISO 27001 and ISO 27005. Read the case studies

Related practice areas

Standards and obligations

What a platform replacement is measured against

The Digital Service Standard and the DTA assurance framework, Victoria’s Gateway, ISO/IEC 25010 and the ISO/IEC/IEEE 29119 test series, ISO/IEC 42001 and 42006 where AI is involved, and CPS 230 for APRA-regulated clients are what a platform replacement gets measured against. No published standard covers the migration reconciliation method itself.

All five areas are set out in one place, with sources and dates, on the standards and obligations page. It was last checked in September 2026.