This section explains how software moves from development into live use and what a business should require at each stage. The practical focus is controlled releases, representative testing, database changes, rollback and clear responsibility during go-live.
Development vs Staging vs Production Environments
When a business commissions a web application, the supplier will typically set up separate environments to keep work-in-progress code away from live users. Understanding what each environment does, and what it should contain, helps you ask the right questions during acceptance testing and go-live planning.
A development environment is where developers write and test individual features. It changes frequently, sometimes several times a day. Data here is usually synthetic or anonymised. There is no expectation of stability, and it is not the place to demonstrate progress to stakeholders.
A staging environment mirrors the production setup as closely as possible: the same server configuration, the same database engine, the same integrations pointing to test accounts rather than live ones. The purpose of staging is to run realistic acceptance tests before anything reaches real users. If your team signs off on behaviour in staging, the expectation is that production will behave identically.
A production environment serves actual users and handles real data. Access is tightly controlled. Changes arrive here only after passing through staging and being approved for release.
Common mistakes with environments
- Skipping staging entirely and testing only in development, then discovering issues that only appear on the production server configuration.
- Using production data in development or staging without proper anonymisation, creating a data-protection risk.
- Allowing developers direct access to production to fix small issues, bypassing the release process and removing audit trail.
- Configuring staging differently from production — different PHP versions, different memory limits, different caching — so that passing tests in staging give false confidence.
Questions to put to your supplier
- How closely does staging mirror production, and who verifies that parity?
- Where does test data come from, and how is it anonymised?
- Who has access to each environment, and how is that access logged?
How to Plan a Go-Live for a Web Application
Go-live is not a single moment when someone presses a button. It is a sequence of preparatory steps, each with its own verification point. Rushing any of them increases the chance of a visible failure on launch day.
Pre-launch checklist
- Acceptance sign-off: Confirm that all acceptance criteria have been met in staging and formally signed off by the business owner or product lead.
- Data migration dry run: If existing data is being moved into the new system, run the migration against a staging copy and verify record counts, relationships and formatting.
- Integration verification: Confirm that every external connection — payment provider, email service, accounting software — works with the production credentials in staging.
- Access provisioning: Set up user accounts, role assignments and any single sign-on configuration before the switch, not after.
- DNS and domain preparation: If the application will run on a new subdomain or domain, reduce the TTL on DNS records in advance so the cutover propagates quickly.
- Monitoring and alerts: Ensure that error logging and uptime monitoring are active in production before users arrive.
- Rollback plan: Agree what happens if a critical issue is discovered within the first hour. Know who makes the call and how reversion works.
During the cutover
Agree a communication window with your supplier. If the application replaces an existing system, decide the exact point at which the old system stops accepting changes and whether there will be a read-only period. Document the sequence: database migration, code deployment, DNS switch, smoke test, user notification.
Immediately after go-live
Assign someone to watch error logs and user feedback for the first few hours. Small issues — a misconfigured email template, a permission gap on one role — are common and fixable. The priority is distinguishing between cosmetic problems and functional blockers that warrant a rollback.
Blue-Green Deployments Explained
A blue-green deployment is a strategy that keeps two identical production environments running. One (blue) serves live traffic while the other (green) sits idle. When a new release is ready, it is deployed to the idle environment, tested there, and then traffic is switched over. If anything goes wrong, traffic is routed back to the original environment.
The practical benefit is near-zero downtime. Users are never waiting for a server to restart or a database to migrate because the switch happens at the routing level, typically in seconds.
When blue-green deployments are worth the overhead
Running two full production environments doubles your infrastructure cost at any given moment. For a SaaS product with paying users expecting continuous availability, that cost is usually justified. For an internal CRM used by thirty staff during office hours, the same approach is likely unnecessary — a brief maintenance window may be perfectly acceptable.
What to watch for
- Database state: Switching traffic is straightforward, but if the release includes database schema changes, you need a migration strategy that works for both environments during the transition period.
- Stateful sessions: If user sessions are stored on the server rather than in a shared store, switching environments can log users out mid-task.
- Background jobs: Queued tasks such as report generation or batch emails need to be considered. If a job starts on blue and finishes on green, data consistency may be affected.
If your supplier proposes blue-green deployments, ask them to explain how they handle database changes and background tasks during the switch. The routing part is simple; the stateful parts are where mistakes happen.
How to Handle Database Migrations During Deployment
Most web-application releases that add features will also change the database structure: a new column here, a revised relationship there. These changes need to be applied in a controlled way, ideally as part of an automated deployment process, with a clear path to reverse them if the release fails.
Principles for safe migrations
- Forward and backward scripts: Every migration should have an "up" script that applies the change and a "down" script that reverses it. The down script must be tested, not assumed to work.
- Non-destructive changes first: Adding a new column is low risk. Dropping a column that the old code still references will break the application if you need to roll back. Structure migrations so that the old code version can still run against the new schema during the transition.
- Large data changes separately: If a release requires populating a new column across millions of rows, consider running that as a separate batch job before the code deployment rather than bundling it into the migration script.
- Lock awareness: Some schema changes lock the table while they run. On a large table, that lock can make the application unresponsive. Ask your supplier whether their migration approach avoids long-held locks.
Questions for your supplier
- Are database migrations automated as part of the deployment pipeline, or run manually?
- Is there a tested rollback path for every migration?
- How are long-running or locking migrations handled for tables with significant data volume?
What Is CI/CD and Why Does It Matter?
CI/CD stands for continuous integration and continuous delivery (or continuous deployment, depending on the setup). It refers to the automated pipeline that takes code changes from a developer's machine through testing and into a staging or production environment without manual steps in between.
Continuous integration means that whenever a developer pushes code, the system automatically runs tests — unit tests, linting checks, sometimes integration tests — to catch obvious problems before the code is merged with the main branch.
Continuous delivery means that once code passes those automated checks, it is packaged and deployed to staging automatically. A human still approves the final step to production.
Continuous deployment goes one step further: if the code passes all checks, it goes to production without a manual approval gate. This is common in large-scale SaaS but unusual and often inappropriate for bespoke business systems where the business owner wants to control when changes reach users.
Why a business should care about CI/CD
Without CI/CD, deployments tend to be manual, infrequent and high-risk. Someone logs into a server, copies files, runs database scripts by hand and hopes nothing was missed. This approach makes rollbacks difficult, introduces human error and discourages small, frequent releases in favour of large, nerve-wracking ones.
With CI/CD, releases become routine. Each change is small and tested. If something breaks, the last known-good state is clearly identified and restoring it is a standard procedure rather than an emergency.
What to check with your supplier
- Is there a CI/CD pipeline in place, and can they walk you through the stages?
- What tests run automatically, and what is still done manually?
- Who approves production releases, and how is that approval recorded?
- How long does a typical deployment take from code merge to production?
How to Plan a Soft Launch vs a Hard Launch
A hard launch means making the application available to all intended users at once, on a fixed date, with full marketing or internal communication. It creates a clear moment of commitment but concentrates risk in a short window.
A soft launch means releasing the application to a limited group first — a single team, a subset of customers, one geographic region — and expanding gradually. Issues are discovered with a smaller audience, and the feedback informs fixes before the wider release.
When a soft launch makes sense
- The application replaces a system that many people depend on daily, and a failure would halt operations.
- The user base is large enough that a bug would generate overwhelming support requests all at once.
- There is genuine uncertainty about how users will interact with the system in practice, not just in staged tests.
When a hard launch is reasonable
- The application is entirely new and users are not being migrated from an existing tool.
- The user group is small and can be supported directly if issues arise.
- Staging testing has been thorough and the feature set is well-understood.
Planning a soft launch practically
Define the expansion criteria in advance. Rather than saying "we'll see how it goes", agree specific thresholds: if the soft-launch group reports fewer than a set number of critical issues over a defined period, expand to the next group. If issues exceed that threshold, pause and fix before continuing. This removes the ambiguity that often turns a soft launch into an indefinite pilot.
Rollback Planning for Web Application Releases
Every deployment should have a planned rollback path. Not every release will need it, but not having one turns a manageable problem into a crisis.
What a rollback plan should cover
- Code reversion: How is the previous version restored? In a CI/CD pipeline, this is typically a one-command operation that redeploys the last known-good build. Without automation, it means manually replacing files — slower and more error-prone.
- Database reversion: If the release included schema changes, can those be reversed without data loss? This is why backward migration scripts matter. A code rollback that leaves the database in the new schema will often cause errors.
- Configuration and environment variables: Sometimes a release changes environment settings. The rollback plan must account for reverting those as well.
- External state: If the new version sent notifications, created records in a third-party system or triggered webhooks, a rollback cannot undo those side effects. The plan should acknowledge this limitation and include any manual cleanup steps.
- Decision authority: Who decides whether to roll back? This should be named in advance, not debated in the moment. For internal systems, it is usually the business owner or operations lead. For SaaS, it may be the technical lead with a defined escalation path.
- Time window: Agree how long after deployment the rollback option remains open. After a certain point — once users have created new data that depends on the new schema — rolling back may cause more damage than pressing forward with a fix.
Testing the rollback
The most reliable way to know a rollback works is to have tested it. During the staging phase, deploy a release, then roll it back and verify that the application returns to its previous state correctly. If your supplier has never tested a rollback, the first attempt may uncover problems at exactly the wrong time.
Common rollback failures
- Assuming that reverting code is sufficient while forgetting that the database schema has changed.
- Relying on a backup that is hours old, losing data entered since the deployment.
- Having no documented procedure, so the team improvises under pressure and misses a step.
- Rolling back and then re-deploying the same broken release without investigating the root cause.
Ask your supplier to describe the last time they performed a rollback in production, what triggered it and how long it took. The answer will tell you more about their operational maturity than any documentation they can produce.