← All thinking

How do you modernise a platform without disrupting the business running on it?

Migration as architecture, not lift-and-shift, except when lift-and-shift is genuinely the right call. AI accelerates the discovery; a human validates every decision.

Modernisation By a Senior Solution Architect

A sprawling estate is consolidated onto one governed platform: AI drafts the inventory, dependency map and field mapping, a human validates every call, and the cutover runs in reversible steps.SPRAWL34 sites, 4 CMSes, 2 DAMsduplicates and orphansDISCOVERYAI draftscontent inventorydependency + field mapHUMAN VALIDATION GATEkeep · cut · remap, before it shipsCONSOLIDATEDONE GOVERNED PLATFORMone CMS, one content modelone governance modelpredictable performanceREVERSIBLE CUTOVERcanaryverifypromoteor roll back at any step, CI/CD keeps each small.
Modernising means consolidating the sprawl onto one governed platform. AI accelerates discovery, a human validates every call, and the cutover stays reversible at every step.

A replatform is usually the riskiest project a business runs, and the one it prepares for the least. The software is the easy part. Moving a live business onto it, without losing what already works, is where modernisation actually succeeds or quietly fails.

Lift-and-shift has its place, but it isn’t modernisation

Sometimes moving as-is is the right call. A data-residency rule that forces a platform to run inside a particular region (a content platform that has to sit in China, say), a hard budget, or a deadline that won’t move: lift-and-shift is a legitimate answer to those, and pretending otherwise helps no one. What it isn’t is modernisation. Moving the boxes, same content and processes on new infrastructure, carries every old problem across intact, so the mistake is doing the lift-and-shift and expecting the benefits of a rebuild. Decide which one you’re doing, and why. Real modernisation is usually consolidation: most estates that need it aren’t one system but a sprawl of dozens of properties where three or four would do, and the win is collapsing that into one governed platform the team can actually maintain.

Where AI accelerates a migration, and where it doesn’t

AI earns its place in discovery and mapping, not the decisions that carry risk. It can crawl a legacy estate and produce a first-pass inventory and dependency map faster than a team can by hand, and draft field-mapping suggestions between an old schema and a new one. What it doesn’t get to do is decide, unsupervised, what’s safe to cut: every AI-drafted mapping goes through a human validation gate before it touches production, because a wrong guess here fails quietly, months later, as something that silently stopped working.

The hard constraint underneath all of it is that the business can’t stop while the ground moves. That’s why we map the estate before we move it and stage the cutover in reversible steps behind a rollback path, rather than one high-stakes go-live. AI makes the discovery faster. It’s still the architecture, and the human sign-off, that make it safe.

More thinking

See the work
01

Your platforms can talk, but does your business actually work as one?

Integration vs connectivity: why "the systems talk" is the wrong test, and what a governed event contract actually proves.
02

How do you build a connected core without a leap of faith?

What a connected core changes for your business, and the staged path that gets you there without a blind commitment.

Let’s start something that lasts.

Bring the problem you’re weighing: a migration, a re-platform, a build that has to hold. You’ll talk to the people who’d do the work, not a sales desk.

Book a meeting

Let’s talk

Book a meeting

A 30-minute video call with the people who’d actually do the work. Pick a time, tell us what you’re weighing, and we’ll bring the right minds, not a sales desk.

  1. Date
  2. Time
  3. Reason
  4. You

Which day works?

Times shown in your timezone.

Pick a time

What’s it about?

Last thing — who are you?