Production Readiness Checklist: 12 Things Most Teams Skip

A system can pass user acceptance testing and still be unready for production. The screens work, the main workflows complete, and the demo looks convincing. Then the first real incident exposes everything that was not part of the acceptance criteria: failed retries, missing audit trails, weak permissions, no rollback path, and logs that explain nothing.

Production readiness is the discipline of checking whether the system can be operated safely after launch. It is less glamorous than feature delivery, but it is where many expensive failures are prevented.

This checklist is deliberately practical. It focuses on the checks that matter when software is used by real users, with real data, under real pressure.

1. Failure paths are designed, not accidental

Every important dependency should have a defined failure behaviour. What happens if the database is slow? What happens if an external API times out? What happens if a file upload fails halfway through? The answer cannot be "the exception handler catches it" because catching an exception is not the same as preserving the user's work or protecting the data.

Production-ready systems distinguish between failures that can be retried, failures that require user action, and failures that must alert the team immediately. A retryable payment callback is different from a partially written transaction. Treating both as generic errors creates operational risk.

The readiness test is simple: for each critical workflow, force the main dependencies to fail in a test environment and observe whether the system behaves deliberately.

Graceful Degradation: What Happens When Part of Your System Fails →

2. Observability answers real operational questions

Logs are useful only if they are structured, searchable, and connected to the business event that matters. A stack trace without a user ID, correlation ID, order reference, tenant ID, or workflow state is often more frustrating than helpful.

Production readiness requires metrics that describe the system's actual work: jobs processed, payments completed, documents ingested, failed integrations, queue depth, and user-facing latency. Infrastructure metrics matter, but they rarely tell the whole story.

The readiness test is whether the team can answer a question like "why did this customer's request fail?" without SSH access, database spelunking, or asking a developer to reproduce the issue locally.

Observability Is Not the Same as Logging →

3. Data integrity is protected at the transaction boundary

The most damaging production issues are often not visible crashes. They are quiet data integrity failures: duplicate records, partial updates, orphaned rows, incorrectly retried jobs, and state transitions that should never have been allowed.

Readiness means the important invariants are enforced where they belong. Some belong in application logic. Some belong in database constraints. Some belong in transactional boundaries that guarantee related changes succeed or fail together.

The readiness test is to list the states that should be impossible in the system, then verify that the application and database actively prevent them.

Audit Ready by Design: Building Software That Passes Every Review →

4. Deployment and rollback are rehearsed

A deployment process that only works when the person who built it is present is not production-ready. Neither is a process where rollback is written down but never tested.

The system should support small, repeatable deployments. Database migrations should be compatible with rollback strategy. Smoke tests should run immediately after deployment. Feature flags should separate risky release decisions from the act of deploying code.

The readiness test is to deploy to a production-like environment, run smoke checks, simulate a bad release, and prove that rollback or feature disablement works without improvisation.

Deployment Patterns for Business Critical Systems →

5. Security and support are operationally usable

Security controls need to be more than policy. Permissions should reflect real roles. Admin access should be auditable. Sensitive data should be protected in logs, exports, backups, and support tooling, not only in the primary application screen.

Support readiness matters for the same reason. When a user reports a problem, the team needs safe ways to inspect the relevant record, understand what happened, and correct recoverable issues without direct database edits. Production systems become fragile when support requires engineers to patch data manually.

The readiness test is whether a realistic support issue can be investigated and resolved through controlled tooling, with an audit trail of what was viewed and changed.

6. Ownership is clear after launch

A system is not ready for production until someone owns each operational responsibility: monitoring alerts, backups, security updates, certificate renewal, dependency updates, incident response, and user support escalation.

These responsibilities are easy to ignore before launch because they do not block a demo. They become urgent later, usually at the worst possible time. Production readiness means assigning them before the system is live and making sure the handover is not a single meeting with no durable record.

The readiness test is whether an incident outside office hours has a clear response path: who is alerted, what they can see, what they can change, and how the business is informed.

The Real Cost of Technical Debt in Operational Systems →

Production readiness is a launch constraint

The right time to ask these questions is before launch, while the cost of correction is still low. After launch, every missing readiness item becomes a production risk with users and business operations attached.

A practical readiness checklist does not slow good teams down. It prevents them from shipping systems that look complete but cannot be operated safely. That distinction is one of the clearest differences between a demo and production software.

The Difference Between a Demo and Production Software →