Application deployment checklist: how to prepare your cloud infrastructure for production

The application is finished. It runs on the lead developer's machine, the demo went well, and the launch date is getting close. One question tends to come up too late: what happens the day it goes down, the day it needs an update on a Friday, or the day the person who built it is no longer around?

An application is ready for production when it can be deployed reproducibly, monitored, backed up and restored, fixed without major downtime, and operated by someone other than its author. These are verifiable criteria: each one is proven by a test or a document, not by a feeling.

This article covers the twelve things to prepare, with, for each one, what a small or mid-sized business needs to put in place, the mistake to avoid and the criterion for calling it ready. It ends with a reusable pre-production checklist.

Development versus production: what actually changes

In development, a mistake costs a few minutes. In production, it affects customers, real data and sometimes revenue. Preparing for production means making the application robust to that change in the scale of consequences.

The 12 things to prepare before going to production

The order follows the logic of a project, from organising environments to handing over. Each item states what to prepare, the mistake to avoid and a readiness criterion. None of the technologies mentioned is mandatory: they are examples, to be chosen according to context.

1. Separate environments

An environment is a complete set (application, database, configuration, access) in which one version runs. A small business usually needs at least three: development, test or staging, and production.

• What to prepare: distinct environments with separate databases and credentials and, on AWS, ideally separate accounts for production. Staging should resemble production as closely as possible.
• Mistake to avoid: copying personal data from production into the test environment without pseudonymising it, or sharing one database password across environments.
• Ready when: nothing done in testing can physically change production.

2. Cloud infrastructure and architecture choices

• What to prepare: an architecture sized for real needs: where the application runs (virtual machine, containers, serverless functions), where data is stored, in which Region, with what level of availability. Managed services (database, load balancer, object storage) reduce the operations work on your side, at the cost of a stronger dependency on the provider.
• Mistake to avoid: choosing a platform because it is fashionable. An orchestrator such as Kubernetes can be oversized for a single application; a single server with no backup is undersized for a critical one. No provider or technology suits every company.
• Ready when: the architecture is described in a diagram, and its single points of failure are known and accepted. If the choice of provider itself is open, our article on migrating from AWS to a European cloud sets out the comparison criteria.

3. Automated tests and pre-deployment validation

• What to prepare: unit tests on business logic, integration tests on database and external service access, and a few end-to-end tests on critical journeys (sign-up, payment, ordering). Database schema migrations should be tested on a representative copy.
• Mistake to avoid: tests that exist but only run on the developer's machine, or flaky tests the team has learned to ignore.
• Ready when: a change that breaks a critical journey is automatically blocked before it reaches production.

4. A CI/CD pipeline

Continuous integration (CI) automatically builds and tests every change. Continuous delivery or deployment (CD) automatically ships the validated version to an environment. Together, they form the pipeline.

• What to prepare: a pipeline in a tool such as GitHub Actions, GitLab CI or AWS CodePipeline that builds an artifact once (container image, archive), then deploys that same artifact to test and then to production. A human approval can be required before production. The pipeline should reach the cloud with temporary credentials: GitHub Actions, for instance, can obtain AWS access through OpenID Connect without storing a long-lived key.
• Mistake to avoid: rebuilding the application differently for each environment, or storing an administrator access key in the pipeline settings.
• Ready when: another team member can deploy without the application's author, and every deployment is traceable (who, which version, when).

5. Secrets and environment variables

• What to prepare: strict separation of configuration from code. The Twelve-Factor App methodology offers a simple test: could the codebase be made public at any moment without compromising a single credential? Secrets (passwords, tokens, private keys) belong in a secrets manager and are injected at runtime.
• Mistake to avoid: a committed .env file, a secret baked into a container image, or a token that shows up in plain text in the logs.
• Ready when: the repository history has been scanned with no active secret found, and every secret has an owner and a rotation procedure.

6. Infrastructure as code and reproducibility

Infrastructure as code describes infrastructure in version-controlled files (Terraform, AWS CDK, CloudFormation, Pulumi) rather than through clicks in a console.

• What to prepare: infrastructure code in the repository, reviewed like application code and applied by the pipeline. With Terraform, the state must be stored remotely, locked and protected: HashiCorp points out that it can contain sensitive data such as initial database passwords.
• Mistake to avoid: changing production by hand "just this once": the code no longer reflects reality, and the next apply may undo the fix.
• Ready when: a complete environment can be recreated from the code and a written procedure.

7. HTTPS, access management and application security

• What to prepare: HTTPS everywhere, with HTTP redirection and automatic certificate renewal (on AWS, AWS Certificate Manager handles this for load balancers and CloudFront); administrative access restricted and protected by multi-factor authentication; software dependencies scanned. The OWASP Top 10:2025 is the reference for application risks: it ranks broken access control first, followed by security misconfiguration and software supply chain failures.
• Mistake to avoid: an admin console reachable from the internet with a shared account, or dependencies never updated since the project started.
• Ready when: sensitive journeys have been reviewed against these risks, and the cloud account configuration has been checked (see the 12 checks of an AWS security audit).

8. Logs, monitoring, alerting and observability

Observability is the ability to understand what is happening inside a system from what it emits: logs, metrics and traces.

• What to prepare: structured, centralised logs with no secrets or unnecessary personal data and a defined retention period; an external availability check; dashboards and alerts. Google's Site Reliability Engineering book recommends focusing first on four golden signals: latency, traffic, errors and saturation.
• Mistake to avoid: dozens of alerts nobody reads, or alerts on CPU usage while users are hitting errors.
• Ready when: the team learns about an outage before its customers do, and every alert has a recipient who knows what to do.

9. Backups and restore testing

• What to prepare: automated backups of the database (managed services often offer point-in-time recovery), of file storage, and of the configuration needed to rebuild. For each application, two targets: acceptable data loss (RPO) and acceptable downtime (RTO).
• Mistake to avoid: confirming that a backup exists without ever restoring it, or discovering during an incident that it does not include files uploaded by users.
• Ready when: a full restore has been carried out in a separate environment, timed and documented.

10. Rollback strategy and incident management

A rollback is a return to the previous version after a deployment goes wrong.

• What to prepare: a suitable deployment strategy (rolling update, blue/green, canary) and a way back. On Amazon ECS, for example, rolling updates can use a deployment circuit breaker that automatically rolls back a failed deployment. Database migrations must stay compatible with the previous version of the code, because rolling back code does not roll back the schema.
• Mistake to avoid: discovering mid-incident that rollback is impossible because a column was dropped. Our migration guide also points out that rollback is not just a DNS change once data has been written.
• Ready when: a rollback has been run deliberately at least once, and an incident procedure states who decides and who communicates.

11. Performance, availability and costs

• What to prepare: a load test in staging on expected traffic and its peaks; timeouts and limits on external calls; bounds on auto scaling; a realistic availability target; a budget and cost alerts.
• Mistake to avoid: auto scaling with no ceiling, which turns a traffic spike or an attack into an unexpected bill.
• Ready when: the application's limits are known and quantified, and an alert warns of cost drift. For what comes next, our guide to reducing AWS costs without risking production covers the levers.

12. Documentation, knowledge transfer and ownership

• What to prepare: an up-to-date architecture diagram; procedures to deploy, roll back, restore and rotate a secret; a list of access rights and their owners; a named owner for operations and an on-call arrangement suited to the team's size.
• Mistake to avoid: knowledge that exists only in the head of one person or one contractor.
• Ready when: someone other than the author has deployed and restored the application using only the documentation.

Pre-production checklist

• Development, test and production environments are separated, with distinct credentials.
• Staging is close to production, with no unprotected real personal data.
• The architecture is described in a diagram, with its known points of failure.
• Automated tests cover critical journeys and run in the pipeline.
• The same artifact is deployed to test and then to production.
• The pipeline reaches the cloud with temporary credentials.
• No secret is present in code, images or logs.
• Infrastructure is described in version-controlled code, and its state is protected.
• HTTPS is active everywhere, with automatic certificate renewal.
• Administrative access is restricted and protected by MFA.
• Logs are centralised, with a defined retention period.
• Latency, traffic, errors and saturation are tracked, and alerts have a recipient.
• A full restore has been tested and timed.
• A rollback has been run at least once.
• A load test has been run on expected traffic.
• A budget and cost alerts are in place.
• Deployment, rollback and restore procedures are written down.
• An operations owner is named.

What a production deployment engagement should deliver

A production deployment engagement is judged by what the team can do on its own once the contractor has left: deploy, monitor, restore and roll back.

CERVOX Services works on AWS through scoped engagements that match these deliverables. Going live with an AWS application deploys your application on your own account, with its domain, the services it needs and the backup of its data, followed by documentation and handover. Automated deployments set up a pipeline in your repository with the planned checks; the rollback is run once with you, and the engagement is complete when a member of your team has re-run the pipeline. The alerts and backups and AWS infrastructure as code engagements complete this foundation depending on your situation.

Frequently asked questions

What does production-ready mean for an application?

A production-ready application can be deployed reproducibly, monitored, backed up and restored, fixed or rolled back to its previous version without major downtime, and operated by someone other than its author, with up-to-date documentation.

What is the difference between continuous integration and continuous deployment?

Continuous integration automatically builds and tests every code change. Continuous deployment automatically ships a validated version to an environment. A small business can adopt continuous integration without deploying automatically to production, keeping a human approval step.

Do you need a staging environment?

For an application with real users, it is strongly recommended. Staging lets you test deployments, database migrations and rollbacks in conditions close to production, with no risk to customers.

Do you need Kubernetes to run an application in production?

Not necessarily. Kubernetes addresses the orchestration of many services. For a single application or a handful of services, a managed container service, an application platform or serverless functions may be enough, with less operational work. The choice depends on the application, the team and the constraints.

How long does it take to prepare an application for production?

It depends on the starting point: an application that is already tested, containerised and configured through environment variables needs far less work than one installed by hand. Reviewing these twelve items is the way to estimate the effort realistically.

Conclusion: prove every item before launch

Putting an application into production is not just making it reachable. It means being able to deploy it, monitor it, restore it, fix it and hand it over to someone else. Each of the twelve items is validated by concrete evidence: a traceable deployment, a timed restore, a rollback that was actually run, a procedure followed by another person.

If your application is ready but not yet in production, or if your deployments are still manual and depend on a single person, describe your situation in a few lines: we will tell you whether we can help, and how. You receive a written estimate within 24 business hours after a first 20-minute conversation.