Going live involves more than uploading code. Permissions, data handling, error reporting, performance, backups and recovery need checking just as much as the screens do.
The following list covers a practical release baseline for a small or medium web application. Your system's specific risks may require additional checks.
Going live is a separately verified release
An application that works in development or testing encounters different data, permissions, load and external services in production. Your release plan therefore needs verification and rollback procedures as well as deployment steps.
Open image full size 1. Check critical user journeys
- Registration, sign-in, sign-out and password reset.
- The most important form, search, save, payment or ordering flow.
- Handling invalid, incomplete and duplicate submissions.
- Mobile layout, keyboard access, focus indicators and clear field errors.
- Email, notifications and external integrations using test recipients or a sandbox.
2. Review data and access boundaries
- Test each role to verify it can only view and modify its authorised data.
- Remove test accounts, default passwords and unnecessary administrator access.
- Load production secrets from separate configuration; never include them in client-side code or logs.
- Enable secure cookie settings, HTTPS and the required request protections.
- Check upload type restrictions, size limits and permissions.
3. Make failures visible
| Area | Have these in place before launch |
|---|---|
| Error log | With searchable event IDs, without secrets or unnecessary personal data. |
| Availability | External monitoring and an alert recipient. |
| Performance | Baseline measurements for important pages and background jobs. |
| Capacity | Track storage, database and external API limits. |
| Responsibility | A named person responsible for release and incidents. |
4. Test backup and recovery
- The backup includes both the database and uploaded files.
- The backup is stored separately from production with restricted access.
- Retention, encryption and responsibility for recovery are defined.
- At least one isolated test restore confirmed that the backup is usable.
- The pre-release recovery point and rollback steps are documented.
5. Steps during the deployment window
- Tell affected users the time, expected impact and contact person.
- Create a fresh backup and check pending background jobs or orders.
- Install using documented, repeatable steps.
- Run the short production checklist on the real domain over HTTPS.
- Monitor errors and key metrics after release; close the work only once the system is verified.
