Business software · 4 min read
Launch day isn't "make the web address live" — it's an operational change
A custom software launch checklist covering readiness, access, data, rollback, training and support.
The short answer
A custom software launch checklist should confirm the core workflow is accepted, data checks pass, access has been tested and the business knows who handles problems. Prepare training, monitoring, support and a fallback before switching users over. A launch is an operational change, not just making a web address available.
By Raja Wahab, Co-founder, Fixby Studios · Published · Updated · 4 min read
Confirm the release is actually ready
Review acceptance tests and unresolved defects with the business owner. Separate inconveniences with documented workarounds from failures that prevent safe operation. Permission errors, lost records and broken essential workflows should not be waved through because a deadline has arrived.
Check the live configuration, not only the test version. Connected services, email delivery and account permissions can differ between environments.
What a launch decision sheet should cover
| Check | Evidence required |
|---|---|
| Core tasks | Agreed acceptance scenarios pass |
| Access | Staff and customer roles have been tested |
| Data | Migration checks and sample records are signed off |
| Recovery | Backup and rollback steps have been rehearsed |
| Support | Named contacts and coverage are confirmed |
| Users | Training and an accessible help route are ready |
| Measurement | Baseline and early success measures are recorded |
Login counts
- — Proves access only
- — Doesn't show if it's used well
Real measures
- — Failed tasks and support requests
- — Time to complete the main workflow
Train around jobs, not menus
Show a staff member how to complete their normal task and recover from a common mistake. Provide short instructions at the point they're needed. A long tour of every setting rarely helps someone trying to serve a customer under pressure.
Include colleagues who weren't involved in the project. Their questions can reveal assumptions the delivery team no longer notices.
“Launch only when acceptance tests pass and the live configuration has been checked, not just the test version.”
Choose a controlled rollout
A pilot group or phased move can limit disruption, provided the old and new processes don't create conflicting records. Decide which system is authoritative at each stage and who resolves discrepancies. Avoid running both indefinitely without clear rules, or staff may enter data twice and lose trust in both versions.
Define rollback triggers before launch
- Write down the events that require pausing or reverting.
- Name who makes the rollback decision and how quickly.
- Agree how changes made since launch are kept or recovered.
- Avoid a rollback that discards new work without a recovery plan.
Watch the first period of use
Track failed tasks, integration errors, support requests and the time needed to complete the main workflow. Speak to users who aren't adopting the tool rather than looking only at login counts; a login proves access, not value.
Compare outcomes with the original baseline and prioritise fixes that block the core task. Keep feature requests in a separate backlog, and use observed needs to decide what comes next rather than treating launch as the start of an unrestricted wishlist.
Sources
Your questions
- What should a custom software launch checklist include?
- Confirmed acceptance tests, tested access and roles, signed-off data migration, rehearsed backup and rollback, named support contacts, and training ready before go-live.
- Should we launch to everyone at once or in phases?
- A pilot group or phased rollout usually limits disruption, as long as you decide which system is authoritative at each stage so records don't conflict between old and new tools.
- What triggers a rollback after launch?
- Agree this beforehand: events like broken core workflows, lost records or failed permissions. Name who decides and how changes made since launch are kept, so a rollback doesn't discard real work.
- How do we know a software launch has gone well?
- Track failed tasks, support requests and time to complete the main workflow against a baseline, and ask non-adopting users why. A rising login count alone doesn't confirm the launch worked.
Raja Wahab is co-founder of Fixby Studios, a Huddersfield studio building websites, SEO, social media and business software for small, owner-managed businesses across West Yorkshire.
Next step
Let's get your business seen.
A free plan to replace spreadsheets and WhatsApp with one system.
Tell us which task takes too much time and we'll assess a focused software or automation project. Business automation and software
Prefer to talk it through? Contact Fixby Studios, email info@fixbystudios.co.uk or call 07737 067552.
