A staging environment is a copy of your live system on which updates, plugins and new features can be tested safely. For online shops with ongoing revenue it usually makes sense, because failed updates in the live system can disrupt the checkout process and thus directly affect sales.
A test environment – also called a staging environment – is a copy of your live system on separate infrastructure that is as faithful to the original as possible. It allows changes to be verified under realistic conditions before they reach visitors and customers. The basic idea: errors should surface where they cause no harm. With professional hosting, a staging environment is therefore often part of the setup – either permanently or provisioned on demand.
How important staging is depends on the project. An online shop continuously processes orders and payments – a failed update on the live system can block the checkout and immediately cost revenue and trust. For a small static website without complex functionality, the risk is more manageable; depending on the setup, a local development environment may suffice. As a rule of thumb: the more business-critical the system and the more components interact, the more important a dedicated test environment becomes.
What gets tested on a staging environment
- Shop system or CMS updates – including compatibility with the theme and plugins
- Plugin and extension updates – traceable one by one instead of bundled on the live system
- New features and custom development – under realistic conditions before go-live
- Integration changes – such as connections to ERP, payment providers or shipping services
- Design adjustments – templates and CSS changes across different devices
- Critical flows – registration, cart and checkout after every major change
What makes a good staging environment
For tests to be meaningful, the staging environment should resemble the live system as closely as possible: same PHP version, same database version, same plugin versions. Two points deserve particular attention. First, data protection: if the test environment contains copies of real customer data, GDPR requirements apply – in practice, personal data is therefore often anonymised or replaced with test data. Second, isolation: staging systems should be protected by access controls and blocked for search engines, so that no duplicate content issues arise and no unauthorised parties gain access.
In professional development workflows, staging is one stage in a clear chain: development happens locally or on a development environment, testing on staging, delivery to the live system – ideally via automated deployment that makes changes traceable and reversible when needed. This is also how we work in software development; our project process shows how a project moves from requirements to go-live with us.
A practical note on data handling: while testing takes place on the staging environment, the live system keeps running – new orders and customer accounts are created there continuously. The test environment therefore ages by the day. Before major tests it should be rebuilt with a fresh data snapshot, and changes generally travel in one direction only: code from staging to live – unverified data, however, not the other way round. A defined process prevents test data from accidentally ending up in the live shop or real orders from being lost during synchronisation.
The cost of a staging environment depends on its scope – from a simple copy on the same server to fully mirrored infrastructure. Measured against the risk of a failed shop, the effort is usually well invested: a single prevented live outage can already justify the running costs of the test environment.
In our maintenance packages – such as Shopware maintenance – we test updates on a staging environment before applying them. Changes only reach your live system after they have been tested in a controlled way.