Switching a core system — a new POS, CRM, billing platform, or ERP — is one of the riskiest things a small business does, and most do it without a plan beyond "flip it on Monday." This is the checklist that turns a nervous launch into a non-event. It's the same discipline large companies use for major system cutovers, distilled to what a small business actually needs.
Phase 1 — Before launch (the part everyone shortchanges)
- Test with your real data, not demo data. Load a copy of your actual records and confirm the system handles them — including the messy ones.
- Test the unhappy paths. Refunds, partial payments, cancellations, discounts, edge cases. These are what break in production.
- Verify every integration. Confirm data actually flows to and from accounting, scheduling, your website, and anything else connected — both directions.
- Validate the data migration. Spot-check that records moved correctly and nothing was dropped or mangled in transit.
- Have real users try it. The people who'll use it daily will find problems a vendor demo never will.
- Write the rollback plan. Decide in advance exactly how you'd revert to the old system if launch day goes wrong.
Phase 2 — The go/no-go decision
Before you commit to launching, make one honest call: is this actually ready? Decide your criteria in advance — which issues are blockers and which can ship — and hold the line. The most valuable outcome of this step is sometimes "not yet." A two-week delay is cheap; a failed launch in your busy season is not.
Phase 3 — Cutover day
- Work from a written runbook. A step-by-step sequence with timing and a named owner for each step — not a plan that lives in someone's head.
- Pick a low-traffic window. Launch when a hiccup costs the least — not during your busiest hours.
- Keep the old system reachable. Don't decommission anything until the new system has proven itself live.
- Have support on standby. Someone who can fix problems in real time, not file a ticket and wait.
Phase 4 — After launch
- Validate production. Confirm the system is doing what it should — data flowing, integrations holding, numbers correct — over the first days, not just the first hour.
- Watch the numbers. Reconcile early reports against what you'd expect. Quiet data problems show up here first.
- Keep the rollback option open until you're confident, then formally retire the old system.
When to bring in help
If the system touches revenue or customers and you don't have someone whose job is launch discipline, an independent set of hands is cheap insurance. Go-Live Assurance runs this entire checklist for you — testing, the go/no-go call, the managed cutover, and the rollback plan — from $6,000 per system go-live. For the why behind it, read What Is Go-Live Assurance? — or book a discovery call if you've got a switch coming.
Common questions
- What should be on a system go-live checklist?
- Four phases: preparation (test against real data and real workflows, including the edge cases), a go/no-go decision before you commit, a managed cutover with a written runbook and clear owners, and post-launch validation that data and integrations actually work. A documented rollback plan runs underneath all of it.
- How far in advance should I prepare for a go-live?
- Start preparing as soon as you have a target date — ideally several weeks out for anything that touches revenue or customers. The most expensive go-lives are the rushed ones, where testing gets cut to hit a date and the problems surface in production instead.
- What's the most common reason go-lives fail?
- Untested edge cases and broken integrations. The new system usually works fine on its own and with clean demo data — it fails on your messy real-world records, the unusual-but-real scenarios (refunds, partial payments, cancellations), and the quiet handoffs to other tools that stop passing data.