You Do Not Need a Migration to Start

In fourteen years of these conversations, the objection that stops a PMIS decision is almost never price. It is this:

We have fifteen years of history in the current system. We cannot move it. So we cannot move.

The objection is stated as a fact and treated as one. It is actually an assumption, and it rests on a comparison with a different kind of system entirely.

The objection is stated as a fact and treated as one. It is actually an assumption, and it rests on a comparison with a different kind of system entirely.

The analogy that does the damage

Most senior people forming this view have lived through an ERP implementation, and they are reasoning from it correctly.

An ERP is an organisational system. It holds the general ledger, the chart of accounts, the vendor master, payroll.

There is one instance of the truth and everything depends on it, so replacing it means a cutover — a date on which everything moves, preceded by eighteen months of migration and followed by a quarter of reconciliation. Anyone who has done that once is right to be cautious about doing it again.

A PMIS is not an organisational system. It is scoped to projects and programmes.

That single structural difference changes everything about how you adopt one, and it is routinely missed because both are large systems bought by the same committee.

What programme scope actually means

A programme starting next quarter has no history to migrate. There are no legacy commitments on it, no prior correspondence, no closed variations. It begins empty whatever system you put it in. existing system. Run both for as long as the old portfolio takes to finish, which is a defined and finite period because projects end.

There is no cutover date. There is no weekend when everything moves. There is no reconciliation quarter. The old system winds down as its projects close, and at some point it is holding nothing that anyone needs to open, at which point it becomes an archive.

An ERP has to be cut over because everything depends on it. A PMIS does not, because projects end.

The opportunity most organisations miss

Here is the part that is genuinely valuable and rarely discussed, and it argues for a fresh start on its own merits rather than as a compromise.

Every mature PMIS configuration contains decisions everyone knows are wrong. A cost code structure inherited from a system two generations back. A WBS that made sense for the first programme and has been stretched across four since. Value lists with entries nobody uses and entries everybody needs that were never added. Workflows routing approvals to a role that was reorganised out of existence in 2021, now handled by an exception everybody knows about.

None of it can be fixed while the system is live, because changing a coding structure with eleven years of history behind it means restating the history, and nobody has the appetite. So the wrong decisions are load-bearing, and they get carried forward into the next system by anyone who migrates configuration along with data.

A new programme on a new platform is the only realistic opportunity to fix them. You configure against the delivery framework you actually intend to follow — which for many organisations in this region now means a national or corporate governance framework that did not exist when the current system was set up — rather than against the accumulated compromises of the last decade.

Organisations that treat the first programme as a migration exercise import their problems. Organisations that treat it as a design exercise do not.

The parallel period, run properly

Two practical points, because a parallel run done carelessly creates its own problems.

Be explicit about which system is authoritative for what. Every record type has exactly one system of record during the parallel period, determined by which programme it belongs to. Ambiguity here is what produces the double- entry that gives parallel running a bad reputation.

And decide reporting consolidation early. During the overlap, portfolio-level reporting has to draw from both, and the organisations that handle this well decide up front whether consolidation happens by exporting from the old system into the new, or by reporting at a level of aggregation both can support. Deciding it in month seven, under pressure from a board pack, produces a manual spreadsheet that then becomes permanent.

What this does to the decision

Reframed this way, the decision in front of an organisation is not whether to undertake a migration. It is whether the next programme starts on a system that reflects how they now intend to work. anybody to sign off on moving fifteen years of history before seeing whether the platform delivers.

Which is not to say that the history is worthless or unreachable. There are good reasons to bring some of it forward, and there is now a genuinely better way to do it.

The decision in front of you is not whether to undertake a migration. It is whether the next programme starts on a system that reflects how you now intend to work.

Next week, closing this series: where AI actually reduces the cost of migrating legacy project data, and the three things it will not do for you.