The plan said go-live weekend. The outcome was decided months earlier.

I have sat on a lot of cutover bridge calls over the years, usually on a weekend, usually with bad coffee. What I have noticed is that by the time the call starts, most of the outcome is already set. The work that decides it happened weeks or months before.

A few years back, I worked on a utility program that replaced an old customer system with SAP. The new system had to connect to about 45 other applications. Some of those were being upgraded by other projects at the same time, and everyone needed the same test environments. We did not lose time because the software failed. We lost time because two projects wanted the same environment in the same week, and nobody had sorted that out ahead of time. A big part of my job became keeping a calendar of who had which environment and when, and working out agreements so both projects could keep testing.

More recently, I was the cutover captain for 14 technical teams going through mock cutovers and a dress rehearsal. Different program, same pattern.

So what actually decides go-live? In my experience, a few basic things.

The first is someone owning the environment calendar. If your program shares test environments with other projects, that calendar needs an owner. Otherwise testing slips a week at a time, and nobody can quite explain why.

The second is being honest about whether you are ready to rehearse. Before a dress rehearsal starts, every task should have an owner and a realistic duration. The problems from the last mock should be fixed or have a workaround, and everyone on the roster should actually have access to the systems they need. You also want everyone to agree up front on what a good result looks like, including the timing and how you will check the data. Skip that, and the rehearsal tells you very little.

The third is deciding ahead of time when to raise a hand. If a data conversion step is running late, you want to know when it is an hour behind, not four. We put those trigger points in the runbook so the right people get pulled in early. After each mock, the real durations go back into the plan, so the next run is more accurate.

Most experienced teams know all of this. The trouble is that cutover planning always feels like something you can get to later, and there is always a defect or a status meeting that seems more urgent. Then later shows up.

If your go-live is a few months away and you are not sure who owns the environment calendar, or your last mock ended without a clear list of fixes, it is worth talking about now, while it is still easy to change. You can start with the Project Health Self-Assessment, or book a 30-minute call. No pressure either way.