You cannot replace what you do not understand

Every migration business case I have read was written against the target.

The target state is described in detail. The platform is named, the licence model is understood, the 

architecture diagram is clean, the benefits are quantified to two decimal places. It is a good 

document, and most of it will turn out to be broadly right.

Almost none of it describes the starting point.

That is the wrong way round, because the target is the well-understood half. The tooling is mature. 

The migration paths are trodden. The partners have done it before, in your sector, at your scale. 

The risk does not live there. It lives in the fifteen years of accumulated change you are proposing 

to lift out of one system and set down in another.

The estate you are migrating is not the estate that was designed

Whatever your core platform is, somebody designed it once. Then it ran for a decade or two, during which the following happened.

The documentation stopped being true. Somebody wrote it, somebody else changed the system, and nobody updated the document. There is no villain in that story. It is just what happens when the 

people maintaining a system are measured on keeping it running.

Custom fields and tables accumulated. Each one made sense to somebody on the day it was added. A proportion of them are now named in abbreviations whose meaning lives in two or three heads, and those heads belong to extremely busy people.

Integrations were added quietly. Not the four in the architecture diagram — the eleven that actually 

exist, several of which are a scheduled export, a shared folder and a convention that everybody 

respects and nobody has written down.

Data quality drifted. Not catastrophically. Just enough that the fields you plan to map contain three 

different conventions from three different eras, and the business has adapted around all three 

without anybody escalating it.

None of this is unusual. It is the normal condition of a system that has been useful for a long time. 

The mistake is not having it. The mistake is planning a migration as though you do not.

The people who know are unavailable, and it is nobody's fault

This is the part that surprises people who have not run one of these programmes.

When a migration hits an undocumented structure, the fallback is to ask the person who knows. 

Typically there are two or three of them. They are not obstructive, and they are not hoarding 

knowledge. They are running the business. The finance close does not pause because there is a 

migration on, and the operations team does not stop shipping to sit in a workshop about field 

semantics.

So what happens instead is reverse-engineering. Analysts decode structures before they can map them. Two analysts reach two different conclusions about the same field. The specification reaches the engineers with gaps in it; the engineers return with questions, and the programme discovers that its critical path is not build or test — it is waiting for an answer.

That loop is where migration timelines actually go. Not the technology. The queue for the truth.

Discovery is not the paperwork before the project

Because discovery looks like documentation, it gets treated like documentation: something to be 

compressed when the timeline is tight, or done in parallel with design to save a few weeks.

It is not documentation. It is the highest-risk activity in the programme, and it is the cheapest one 

to do properly. Every hour of genuine discovery removes hours of downstream rework at a much worse exchange rate, because a wrong assumption found during discovery costs an afternoon, and the same assumption found during a cutover rehearsal costs a weekend and a lot of goodwill.

There is a commercial consequence to believing this, and I would rather state it plainly than have it 

discovered later. We will not take a fixed price against a scope a client cannot yet describe. 

Where the estate is not understood, the honest sequence is to scope and price the discovery, do it, 

and then price the delivery against what we found. A firm that fixed-prices an unknown estate has 

either padded the number heavily or intends to recover the difference through change control. Neither of those is a good start.

Security is a position in the sequence, not an adjective

Every firm says security is built in. What that should mean is specific and checkable.

It means the controls, identity model, segmentation and data protection are decided when the target is designed — at stage two of five — and not reviewed at stage five, when changing them means revisiting decisions the whole build now depends on.

Look at any modernisation plan and find where security appears. If it is a phase near the end, next 

to penetration testing and go-live readiness, then security is not built in. It is scheduled. Those 

are very different things, and the second one is how organisations end up going live with a known 

finding and a plan to fix it in the next release.

Modernising a system is the one moment when changing the security model is cheap. It is a poor moment to defer it.

And then transition, which almost nobody budgets for

The last discipline is the one that determines whether you do this again in eight years.

At the end of a programme, the new estate is at its best-documented and best-understood moment. The people who built it are still available. The decisions are still fresh. That is the window in which 

documentation, named system ownership and a real handover either happen or do not.

If they do not, the accumulation starts again on day one — undocumented fixes, a departing 

contractor, a system with no owner — and in a decade somebody will write a business case to replace what you have just built, describing the target in detail and the starting point not at all.

⸻

Three questions worth asking before the next migration paper goes to the board.

Who, by name, can explain the custom fields in the system we are replacing — and how many days of their time have we actually secured?

Does the plan contain a dry run against real production data before a cutover date is committed?

At which stage does security get decided — and if the answer is a phase near the end, what would it 

cost to move it?

⸻

Oghenetega Gharoro-Akpojotor is the founder of Toga EMEA, a boutique technology management 

consultancy working across Europe, the Middle East, Africa and APAC. Secure Digital Change is Toga's delivery practice.