What Happens After Go-Live
Launch is a milestone for the project team and an ordinary Tuesday for everyone else. The next six months decide whether the platform survives its first year.
Most delivery plans are detailed up to go-live and vague immediately after it. There is a launch date, a cutover runbook, a hypercare period of two or three weeks, and then a sentence about transitioning to business as usual. That sentence is usually where the trouble starts.
The project team disbands. The people who knew why a particular integration retries three times move on to the next programme. What remains is a system nobody owns, working well enough that nothing forces the question.
The handover that never quite happened
A handover is not a document. It is a set of answers to questions that only get asked under pressure: who can approve a change to the payment logic, what the recovery procedure is when the overnight job fails, which alerts are worth waking someone for.
If those answers live in the heads of contractors, the handover did not happen — it was scheduled and then quietly skipped because the launch consumed the time allocated to it.
Three things worth settling before launch
A named owner with real authority. Not a steering group. One person who can decide that a defect gets fixed this week and a request waits until next quarter. Shared ownership reliably becomes no ownership by month three.
A support model with numbers in it. What is covered, in what hours, at what response time, and what happens outside them. “We will support it” is not a support model; it is an intention that collapses the first time something breaks on a Friday evening.
A funded change budget. Every platform that gets used generates requests. Organisations that treat all of them as unplanned work end up with a backlog and a frustrated business. The ones that reserve capacity for change spend the same money and get credit for it.
What good looks like at month six
Usage is climbing rather than flat. Defects are trending down rather than accumulating in a spreadsheet. Someone can say what the platform costs to run, and the number is not a surprise.
None of that happens because of the launch. It happens because the operating model was designed with the same care as the architecture — which is the part that rarely makes it into the business case, and always makes it into the outcome.
Launch is a milestone for the project team and an ordinary Tuesday for everyone else.
The six months after go-live decide whether the platform survives its first year. That period is worth designing, and worth staffing.
Bring us the problem behind the project.
If any of this maps onto something you are working through, a short conversation is usually enough to tell whether we can help.