In this guide 6 sections
Launch opens a stabilisation period. Real volume and messy data expose bugs that testing never found, and the vendor triages them under a warranty window written into the contract. Paid maintenance then takes over, with a named owner for monitoring, backups and administrative access, and a review a few months in confirms the original problem was solved.
Stabilisation in the first weeks after launch
The first weeks are different. Issues that appear only under real volume and real, messy data surface for the first time, because no test environment fully reproduces production. During stabilisation, usually a window named in the contract, the vendor watches closely and triages each report within an agreed number of hours.
Not every issue is a defect. Some are workflow mismatches that surface only once staff use the system daily, such as a missing status or a report that needs one more column. Agree the severity labels before launch, such as stops work, slows work and cosmetic, so the first Monday after go-live is spent fixing problems, not debating labels. Expect this, and log each report.
Where warranty ends and paid maintenance begins
Warranty covers defects only. A defect means the software fails to do what the signed specification described, and the fix is free for a fixed window after launch. New features, workflow changes and adaptations to a process that evolved after the specification was written are separate paid work, even when they feel like small extensions.
Settle the boundary before launch. Disputes over whether something is a bug or a change request arise when the definition stays vague, and one written sentence resolves most of them. Define a defect as spec failure. Ask for a rate card for change requests while goodwill is high rather than negotiating it in the middle of an urgent request. Price lists calm tempers.
Who owns monitoring, backups and access after handover
Three jobs need named owners. Assign each in writing rather than assuming it sits with whoever built the system, because assumptions leave the job undone until the first outage exposes it.
Consider a mid-sized private school that has just launched admissions, fee tracking and attendance ahead of a new term, with parents paying fees online from the first morning. Backups matter enormously here. A fee receipt or an attendance log lost to an unrecovered failure is an operational and reputational problem, and it lands on the principal’s desk, not the vendor’s. Confirm in writing who owns backups and how often a restore is tested, and do it before go-live rather than after the incident.
- Uptime monitoring: someone is alerted when the system goes down, before a customer phones to report it.
- Backups: someone takes them on a schedule and, just as important, tests that a backup can be restored.
- Hosting access: someone holds the administrator login and knows who else has a copy.
Training, documentation and the enhancement backlog
Training does not end at launch. New staff will join after go-live and need the same grounding the first group received, which means written documentation must exist and stay current as the system changes. Memory alone is fragile.
Enhancement requests belong in a backlog. Capture each request for new functionality with a date, a requester and a reason, then review the list monthly and prioritise deliberately instead of handling requests ad hoc. Name one person on the business side to accept or reject each backlog item, because a request nobody can approve stays on the list for a year. Planned change keeps the system maintainable.
Reviewing support performance and product outcomes
Book a review after launch. Bring the support log, the open backlog and three examples of work that staff now finish faster or slower than before, so the conversation rests on evidence. Compare the software against the success measures agreed during discovery, and ask whether response times, fix quality and communication under the support arrangement are working for the business. Reviews get skipped when nothing hurts. Yet it is the only reliable way to learn whether the investment delivered, instead of assuming so because nobody has complained loudly.
Name the gap in writing. A slower response time than agreed, or a missed success measure, should be raised directly with dates and examples attached, not left to harden into background frustration. Early naming keeps relationships healthy.
Post-launch responsibility matrix
A RACI-style matrix lists five post-launch areas: bug triage, monitoring, backups, access administration and enhancement requests, each set against who is responsible during warranty and who afterwards. Nothing stays unassigned by default. Fill every cell before go-live.
Open a blank worksheet to printQuestions owners ask
Are all fixes included after launch?
No, only defects are covered. A defect is software failing the agreed specification, fixed at no cost during the warranty window, whereas new features and workflow changes count as separate paid work.
Who maintains the hosting environment?
Whoever the agreement names. It is not automatically the vendor unless your contract says so, and uptime monitoring, backup testing and access administration each need a named owner in writing.
How long does stabilisation last?
The contract sets the length. Ask for a regular list of open reports during those weeks, each marked defect, change request or unclear, so nothing sits unowned while everyone is busy settling in.