Two platforms do almost the same job.

One is older and carries the customers. The other is newer and carries the hope. Data moves between them through an integration layer nobody particularly likes, but everybody is afraid to remove.

Sooner or later someone says the cleansing sentence: “Let’s rewrite it properly.”

I understand the appeal. A blank page has no duplicated tables, accidental ownership, or ten-year-old decisions hiding inside a service called misc. It also has no customers, revenue, operating knowledge, or proof that the new boundaries are better.

Do not underestimate how much the old system knows.

The architecture diagram is not the current state

In a platform audit, I want at least four maps:

  • the systems and integrations;
  • the data and where authority actually lives;
  • the customer and operational workflows;
  • the people, vendors, and decisions that keep it running.

The fourth map is usually the surprising one.

A service may appear independent while every meaningful change requires one person’s approval. A database may be labelled “legacy” while three critical reports read it directly. A team may own a component on paper while a vendor handles every production incident.

This is why a technical transformation is rarely only technical. The dependencies have human shapes.

Ask what the second platform was meant to fix

Before deciding which system wins, reconstruct why both exist.

Was the second platform created for a new customer segment? A faster team? A vendor replacement? A regulatory deadline? A rebrand? Was the plan always to migrate, or did coexistence become the strategy by accident?

Then ask what has genuinely improved.

Perhaps the new product model is better but the data model is not ready. Perhaps the user experience is cleaner while operations still complete half the work in the old system. Perhaps both platforms contain capabilities the other cannot safely absorb.

“New” and “target” are not synonyms.

A rewrite concentrates risk

A large rewrite combines product discovery, architecture, migration, operational change, and customer transition into one promise.

Meanwhile the old product keeps changing because the business cannot wait. The finish line moves. The migration logic grows. People become tired of maintaining two futures.

Martin Fowler’s Strangler Fig metaphor describes a gradual alternative: build around the edges of the existing system, replace capabilities in smaller parts, and let the new structure earn its place. The important word is gradual—not because slow is always good, but because smaller transitions produce evidence earlier.

This is not an automatic answer either. An incremental route can create a complicated in-between state. Every temporary bridge needs an owner and an expiry condition. Without that, “temporary” becomes the next legacy architecture.

The staged route I prefer

The exact sequence changes, but the logic is usually:

  1. Stabilise the facts. Name systems of record, critical workflows, owners, service levels, and non-negotiable constraints.
  2. Choose a boundary. Select one capability that can move with contained customer and data risk.
  3. Protect the interface. Define how old and new communicate without spreading both models everywhere.
  4. Move real work. Put the new path in production for a controlled group and measure operational consequences.
  5. Remove something. A transition is not progress if nothing old can be retired.
  6. Reassess. Use what the first move taught you before approving the whole roadmap.

I also want stop conditions. If migration errors exceed a threshold, if manual work grows rather than falls, or if the business case changes, the team should know when to pause.

What should leadership receive from an audit?

Not a red-yellow-green spreadsheet with 140 rows.

Leadership needs the current-state picture, the expensive dependencies, credible target options, explicit trade-offs, and the first sequence of decisions. Engineering needs boundaries, risks, and an implementation route. Product and operations need to see what changes for customers and staff during the transition.

One document will not solve the platform problem. A shared picture can stop the company solving three different versions of it.

The cleanest architecture is not always the most responsible next move.

First make the system understandable. Then make one part better. Then earn the rewrite—or discover that you no longer need one.

Sources and further reading