The weeks after go-live decide the project. Almost nobody staffs them.

Read any implementation plan and you will notice the same shape. Enormous detail up to launch: migration steps, cutover windows, training sessions, a rollback procedure, a go/no-go meeting with named attendees.

Then, after launch day, three words. Hypercare and support.

That is the period which determines whether the project worked. It is consistently the least planned, least staffed and least funded part of the whole engagement, and the reason is structural: go-live is when the delivery team's budget ends and the client's risk begins.

We have run this period enough times to say plainly that it is where projects are won and lost, and that most of what goes wrong in it is predictable.

What is happening in those weeks

The system is live. It works. The tests passed and the data migrated. And your organization is now in the least productive state it has been in for years, for reasons that have nothing to do with software quality.

Everyone is slower, including the people who wanted this. Staff who knew the old process cold are now looking for things. A task that took four minutes takes eleven. This is normal and temporary, and to the people living it, it feels like proof the new system is worse. That impression forms in about nine days and it is very hard to reverse afterwards.

The exceptions arrive. Testing covers what people remembered to describe. Week three produces the case from a carrier who does things differently, the record with thirty years of history, the approval that has always been done by phone. None of these were hidden; nobody thought to mention them, because they are just Tuesday.

Two systems are running. In practice, not on the plan. Somebody keeps the old spreadsheet updated "just to be safe," which is entirely reasonable and also the single most dangerous thing that happens in this period.

Nobody wants to report problems. The project was expensive and sponsored by someone senior. Raising a hand in week two feels like criticising a decision already made, so people invent workarounds instead and say nothing. The information you most need is the information least likely to reach you.

The three ways it fails

The silent workaround. One team hits friction, invents a manual step, and tells no one. Six months on it is institutionalised, undocumented, and the reported numbers are being adjusted by hand somewhere between the system and the board pack.

The shadow system that never dies. The parallel spreadsheet was supposed to last two weeks. At week ten it still exists, and now it disagrees with the system. Once two records disagree, people trust the one they maintain themselves, and the new platform becomes an expensive place to re-key data that already exists elsewhere.

The rollback that gets framed as prudence. Rare, expensive, and almost always the endpoint of the first two, and rarely a response to a technical failure. The system usually worked. The adoption did not.

Notice that none of these are software defects. Every one of them is an operational failure, which is exactly why a support contract is the wrong instrument for them.

Why a support ticket cannot catch any of this

Support is reactive by design. It waits to be told.

The failures above share one property: nobody reports them. A workaround is not a bug. The person who invented it thinks they solved a problem, and they did. A parallel spreadsheet is not an incident. Slow adoption in one department does not raise a ticket; it produces a quiet opinion that gets expressed in a meeting four months later.

So an empty ticket queue in week three is not evidence that the launch went well. It is the most common signal preceding the failures that happen, and the only way to see them is to go and look.

What we do instead

We treat the post-launch period as a delivery phase with its own plan, not as a warranty. Four things, all deliberately unglamorous.

We are in the operation, not on a support line. Someone sits with the people using the system, watching real work, during the first weeks. Ninety minutes of watching an adjuster process actual cases surfaces more than a month of tickets, because you see the hesitations people would never think to report.

We kill the parallel system on a date, deliberately. Not by decree, but by making sure the new system does the job the spreadsheet was still doing, and then setting a date with a name against it. Running two systems indefinitely is not caution. It is the failure, in progress.

We watch usage rather than uptime. Which features are untouched, which records get edited immediately after creation, which team's numbers look different from everyone else's. Untouched functionality is either unnecessary or not understood, and both are worth knowing within weeks, long before renewal.

We expect to change the system, and we budget for it. Not scope creep, but contact with reality. The exception nobody documented is not a change request; it is the requirement that was always there. Treating week-four discoveries as out-of-scope is how a delivery team protects its margin and loses the client's operation.

For the claims platform we built, this is why it is still ours to operate long after handing it over would have been the easier option. More than 24,500 cases a year across 28 legal entities does not become stable because a cutover succeeded; it becomes stable because somebody kept paying attention afterwards.

What to put in the contract

If you are commissioning work, this is the practical part. Ask for four things before signing, because they are cheap to agree beforehand and impossible to add later.

1. Named people, on site or in the operation, for a defined period after launch, not an SLA, not a shared inbox. A person, a number of days, a date.
2. A decommission date for whatever the new system replaces, agreed in advance and owned by someone on your side.
3. A change budget for the first sixty days, ring-fenced, with a light approval path. Assume the requirement was incomplete, because it was.
4. Adoption reported to the sponsor, not uptime. Uptime will be fine. Uptime is not the question.

Any partner who resists all four is telling you where their engagement really ends, and it is worth knowing that while you are still negotiating, not in week five.

The bottom line

A system that goes live is not a project that succeeded. It is a project that reached the part where success gets decided.

The organizations that get the value they paid for are not the ones with the cleanest cutover. They are the ones that treated the following six weeks as real work with real staffing, and who understood that the silence in the ticket queue was not good news.

This is why staying after go-live is one of the four things we commit to, and never a service we sell separately. It is not generosity. It is the only period in which anyone can tell whether the work was any good, and we would rather be there for it.