Staging

What it means

Staging mirrors production as closely as possible: same versions, same configuration, comparable data. It exists to prove a change before customers see it.

It is not the same as a developer’s laptop. Faults that only appear in the real configuration can be found only where that configuration is reproduced.

Staging is neither a backup nor a fallback environment for a disaster. It exists to check changes before release, not to run the business when production goes down. That is what a disaster recovery plan with its own infrastructure and a rehearsed procedure is for; relying on the test environment in a crisis means putting something in front of customers that nobody prepared for real load.

How it works in practice

In practice every change passes through it via CI/CD before production. Database migrations and restores from backup are tested there too, not just screens.

For accounting and payroll systems it is where new statutory calculation versions are tried. The first payroll run under new rates should not happen live.

On an e-shop’s staging site the payment gateway must run in test mode, and emails to customers must be switched off or redirected. Otherwise a test order really charges a card, or a real customer receives confirmation of an order they never placed, and the books end up with payments that later have to be refunded.

What to watch out for

Copying real personal data into staging unprotected breaches GDPR. Data must be anonymised or pseudonymised, or the test environment becomes another place to leak from.

A staging site reachable from the internet without a password will sooner or later be indexed by search engines. It then competes with the live site in SEO with the same content, visitors land on unfinished pages and may fill in a form nobody reads. Password protection and a no-index rule take a few minutes to set up.