Häufig gestellte Fragen
What is the difference between a sandbox and a test or development system?
In a typical ERP system landscape with the tiers development (DEV), quality assurance/test (QAS) and production (PRD), the sandbox is the most experimental, approval-free tier for open experimentation, prototyping and training. A development system, by contrast, focuses on structured programming and customising, whose results move to the next tier via a controlled transport path. The test or QAS system serves integration and acceptance testing (user acceptance testing) as close as possible to the production state before changes are released. In practice the terms overlap depending on the vendor, but technically they all share isolation from live operations.
Does personal data in an ERP sandbox have to be anonymised?
As soon as a sandbox contains a copy of real production data with personal references – such as names, addresses, IBANs or salary data of employees, customers or suppliers – this constitutes processing of personal data under the GDPR and is subject to the principles of data minimisation and purpose limitation. Production data is therefore usually masked, pseudonymised or anonymised before being transferred into test environments, and referential integrity (identical masking across all tables) should be preserved in the process. Specialised tools exist for this task, such as SAP TDMS, Oracle Data Masking and Subsetting, Libelle DataMasking or EPI-USE Labs Data Secure. Alternatively, synthetic test data can be generated, which largely avoids the data protection effort.
How often should a sandbox be refreshed from the production system?
A fixed refresh cycle ensures that the sandbox reflects the current state of the production system and that test results remain meaningful. Common recommendations call for rebuilding development and sandbox environments monthly, while test/QAS systems are often refreshed monthly or per release cycle – in intensive release phases even weekly. Pure sandbox environments for open experimentation are in practice often also reset on demand. The specific rhythm depends on data volume, frequency of change and the respective data protection and masking effort.
Do sandbox environments cost extra or are they included in the ERP licence?
This depends heavily on the vendor and licensing model. With Microsoft Dynamics 365 Finance and Operations, for example, exactly one Tier 2 Standard Acceptance Testing tenant is included alongside the production system; additional sandbox or staging instances (Tier 2 to Tier 5) can be booked as paid add-ons. With SAP S/4HANA Cloud Public Edition, the three-tier system landscape of development, test and production is standard, but an additional optional sandbox system is available at extra cost. Specific terms should be clarified directly with the vendor or account management, as designation, scope and price vary by contract.
What is a sandbox used for in ERP updates and migrations?
Before a release upgrade or an ERP migration, the sandbox serves as a rehearsal stage on which update effects, data consistency and the interplay of extensions and interfaces are checked in advance without endangering live operations. In SAP practice, it is standard procedure to first run through a planned system upgrade in a sandbox before rolling it out to the production landscape. This makes it possible to detect and fix errors, incompatibilities and performance problems while they remain without consequences. Documented test cases from the sandbox are at the same time a valuable basis for the subsequent release decision.
How many sandbox or non-production environments does an ERP project need?
During an ERP implementation, planning frequently assumes three non-production environments – development, test/QAS and a training sandbox – so that development, acceptance and training run cleanly separated. After go-live, the landscape can often be consolidated to development and test once the ongoing need for change declines. How many environments make sense depends on project size, the parallelism of the work, regulatory requirements and the licence and infrastructure costs. Besides the number, it is also important to clearly define who maintains the environments and which role concept keeps test authorisations separate from the production system.