What should be checked before a business system goes live?
A system opening in a browser does not mean it is ready for launch. A reliable release also depends on business flows, data, security, deployment and incident handling.
LAUNCH
Validate real business paths
Testing should follow actual workflows, including roles, permissions, state changes and exceptions. High-risk flows should be accepted with business stakeholders, not only judged by developers.
Check empty states, duplicate submissions, timeouts, network failures and permission errors. Each should produce a clear response rather than an unexplained error page.
Rehearse data and third-party dependencies
Confirm production schemas, initial data, backups and restore procedures. Migrations should be rehearsed with realistic data volume, including duration, failure handling and rollback steps.
Payment, messaging, storage, maps and enterprise APIs need production credentials, quota checks, callback URLs and a defined behavior when a provider is unavailable.
Make deployment and monitoring operable
Before launch, verify domains, HTTPS, environment variables, build artifacts and deployment order. Critical services need health checks, structured logs and basic alerts.
A rollback plan should also cover database changes, cache state and third-party configuration, not only the previous application build.
Keep an observation window after release
Monitor error rates, response times, critical business data and user feedback after deployment. Keep a technical owner available and agree how incidents will be prioritised.
A launch is successful only when the core workflow is stable in the real environment and the team knows how to detect, resolve and reverse problems.