Go-Live

A team can run a new booking system perfectly in a test environment and still struggle when real customers arrive, because go-live is the handoff from preparation to actual operation, bringing real users, real records and real consequences together. Microsoft's implementation guidance uses a go-live checklist covering technical readiness, business processes, data and people, and AWS cutover guidance describes a runbook for production changes.

Those are useful examples, not a universal certification that every launch must follow their exact steps. Define what is going live, whether a branch, a group of users, a product feature or the whole organisation, since a pilot and a company-wide launch are not the same milestone, and for a phased launch keep each cohort's scope and date visible because a feature can be live for one team and not for another.

A "soft launch" still uses real data or customers in some cases, so set the same basic safety and ownership rules for its stated scope. Set entry criteria before the launch date, including the business processes that must work and the defects that would block safe operation, and test critical paths using representative cases, because a demo with clean sample data cannot prove how messy live transactions will behave.

Complete data migration and reconciliation as applicable, verifying totals, ownership and access rather than relying only on a successful transfer message, and prepare users for actual tasks, not just screens, with training that covers exceptions and where to get help. Assign a go or no-go decision maker and a deadline for the decision to avoid a situation where everyone assumes someone else approved, and document open issues with owners and accepted risk, because a minor cosmetic defect and a broken payment flow should not carry equal weight.

Document sign-offs and evidence without turning the checklist into theatre, so that someone knows what was actually tested, and if a readiness criterion fails, delaying may protect customers and the business, although delays also have costs, so make the trade-off explicit. Write a cutover plan with tasks, order, owners and checkpoints, including the point when old and new systems stop accepting changes.

Consider whether rollback is possible, since some transactions or data changes cannot be reversed simply by restoring a backup, and if rollback is limited, plan a safe forward fix and communication path and explain these limits before launch. Coordinate suppliers and integration partners, because their availability can decide whether a production issue is solved in hours or days.

Check monitoring, alerts, logs and access controls so that a team can detect and diagnose a problem quickly, and test incident contacts and escalation, because a phone list that has not been checked is not a support plan. Define an acceptable service level for the first day, since different businesses have different tolerance for delay and manual work, and provide customer or staff notices saying what is changing, when, and where to seek help.

Plan for capacity spikes, because a launch announcement can bring much more traffic than a quiet test, and use a short period of close support, sometimes called hypercare, with assigned staff and clear incident review. Decide when enhanced support ends, since a fixed date alone may be too early if critical issues remain, and track defects and impact, not just the number of tickets, because one blocked checkout can matter more than twenty small display issues.

Do not confuse launch with adoption, as users may still fall back to old spreadsheets or manual work if the new process is hard, and check benefits later against the original business case, since go-live is a milestone on the way to value, not the value itself. After launch, record the first incidents and lessons and update procedures before normal operations take over, because a credible go-live decision balances readiness, remaining risk, recovery options and the ability to support real users.