For CEOs, CIOs and CTOs
Modernization Audit · Digital ITThe new platform went live on schedule. The cutover checklist is complete. The project is marked done.
And yet the old system is still running, two teams still check one against the other, and the savings in the business case haven't appeared. The gap is rarely the technology. It's that the plan ended at go-live, and the risk didn't.
Most modernization projects are planned and measured up to one moment: go-live. This piece is about what happens after it — the weeks when the old and new systems run side by side — and three questions that make sure that period ends before it quietly becomes permanent.
1. The Project That Finished Twice
A mid-size company moves a core platform to a new environment. The cutover weekend goes well. Users are on the new system by Monday, the project is closed, and the team is thanked.
The old system stays on “just for a bit,” as a safety net. Six months later it's still running. Its licenses are still being paid, two teams still check one system against the other, and nobody can say what would have to be true for it to be switched off.
Nobody failed. The plan had a date for go-live and no date for the end of the parallel run.
The project didn't fail. It stopped being managed.
2. Four Hidden Costs of “Just for a Bit”
Running two systems is often the right call. The cost isn't in the decision to do it. It's in leaving it open-ended.
| Double running costs | Two environments to license, host, patch and support until one of them is switched off. |
| A split version of the truth | Teams check one system against the other, so the answer depends on which one they trust that day. |
| Savings that stay on paper | The business case assumed the old system's cost and effort would go away. Until it's off, they haven't. |
| Ownership that fades | The project team moves on and the parallel run is nobody's job, so every decision about it waits. |
None of these shows up in the project's status report, because the project is closed. They show up in operating budgets, support queues and the quiet reconciliation work that fills a team's week. It's the same pattern as a KPI that stays green while the business doesn't improve: every report says finished, and the people closest to the work know it isn't.
3. Go-Live Is an Event. Done Is a Condition.
The written conditions that must be true before an old system, process or environment is switched off — agreed before cutover, with a named owner and a date.
Go-live is something that happens on a day. “Done” is something that has to be true: the old system is off, its duties have moved, and the benefits are being realized. Plans tend to schedule the first and assume the second.
Without exit criteria, switching the old system off becomes a judgment call that comes up again every month, and the cautious answer is always the same: not yet.
4. Why Your Current Project Governance Doesn't Catch This
Most project governance is built to answer questions like these: Is it on time? On budget? In scope? Signed off at go-live? These are necessary controls, but they're all measured at the event. The weeks afterwards sit in the gap between the project team and the operations team, and neither of them is accountable for ending them.
A project can pass every one of those checks and still leave an open-ended obligation behind. The questions that catch it are ownership questions, not delivery ones.
- Who owns the parallel run?
- What has to be true before the old system switches off?
- What date does it switch off, and who signs it off?
Ask these about your most recent migration, or the one on the plan for next quarter. If you can't answer all three quickly, that isn't a technology problem. It's a governance gap — and it's cheaper to close before cutover than six months after it.
5. A 30-Minute Exercise: Write the Switch-Off Plan
You don't need a new tool or a new project. Take the migration that's already live, or about to be, and do this:
- List everything the old system still does. Include the quiet things: the report someone runs monthly, the integration nobody documented, the team that still logs in “just in case.”
- Mark each item as moved, replaced or retired — and name who confirmed it. An item nobody can confirm is the one most likely to delay the switch-off.
- Write one exit test per item. One sentence each: “We switch off when this has run on the new system for [N] cycles without a manual check.”
- Set the date and name the approver. A date can move. Moving it should be a recorded decision, not a drift.
The aim isn't a perfect plan. It's that “just for a bit” gets an end.
6. What a Finished Migration Looks Like
The plan includes the switch-off
Cutover and decommissioning sit in one plan under one owner. The project isn't closed while either is open.
Exit criteria are written before cutover
They're agreed while everyone still has the context, not worked out later when the team has moved on.
Benefits are tracked after go-live
The savings in the business case are checked when the old system is actually off, not when the new one launches.
Closing the project is a decision
The project closes when the old system is off, or when someone with authority signs a dated extension.
None of this lengthens a project. It moves a decision you'd have to make anyway from later, under pressure, to earlier, with the full picture.
7. The 5-Question Self-Assessment
Run these against your most recent migration. Three or more answers that aren't a clear yes means your project is finished on paper and still running in practice.
| # | Question | Yes / No / Unsure |
|---|---|---|
| 1 | Can you name the person who owns the parallel run today? | |
| 2 | Is there a written list of everything the old system still does? | |
| 3 | Were exit criteria for switching it off agreed before cutover? | |
| 4 | Is there a switch-off date, and has any change to it been recorded with a reason? | |
| 5 | Has anyone checked whether the savings in the business case have actually started? |
8. Three Questions We Hear Most Often
Isn't a parallel run just prudent risk management?
It is, and it should stay that way. The problem isn't running both systems. It's running both with no end. A parallel run with exit criteria is a control. Without them, it's a standing cost that nobody approved.
Our vendor runs the cutover. Doesn't the parallel run fall to them?
A vendor can execute a cutover to a contract. Deciding when the old system is safe to switch off is a business decision about risk and sign-off, so it needs an owner on your side of the table, whoever carries out the work.
Does this apply to AI and automation projects?
Yes. An AI assistant or an automated workflow is often run alongside the manual process “until we trust it.” Without a written definition of trust, that period never ends. It's the same ownership question we raised in who owns the risk when AI acts: everyone can explain their part, and nobody owns the outcome.
The Question for Your Next Project Review
Pick the last project your organization marked as done and ask one thing: what is still running because of it, and who decided it should be? If the answer takes more than a minute to give, the project isn't finished.
Facing similar ServiceNow challenges?
Get a free ServiceNow assessment and understand where your platform may be losing value.
No spam. No sales pressure. Only actionable insights.