In most SMEs, ERP changes go where they can — straight on the production database, on Friday after 4pm, "because nobody is working then". Until Monday morning, when nobody can issue an invoice. A test environment is a boring topic, but it usually pays back after the first outage it prevents.
A scenario we see regularly. The company has been running Comarch Optima, enova365 or Subiekt for years. Along the way it grew its own add-on for document workflow, a WMS integration, a piece of bank data exchange and half a dozen SQL reports. Everything works — until someone clicks "update" or changes the chart of accounts. Then it turns out that one of the add-ons stopped working with the new version, and the cost-invoice workflow has quietly stopped generating accounting entries.
A test environment does not protect against all of these things. But it catches most of them before they block 30 people's work on a Monday morning.
What a "test environment" actually means in an SME
Skip the corporate jargon. In practice it's a second, separate instance of the ERP that you are allowed to break. It can be a separate Optima installation on another server (or a VM), a database copy from the weekend, or even a separate machine with Subiekt and a transferred database. Two things matter:
- The data looks real — real enough to test real scenarios (same chart of accounts, same warehouses, similar document volumes).
- Nothing you do there reaches real accounting, the real warehouse or the real bank.
This does not have to be expensive. For most SMEs it's enough to refresh a database copy once a week or once a month, run it on the same server under a different name, with production SMTP and the bank API cut off. Cost: one evening of admin work plus a bit of disk space.
What is actually worth testing before it hits production
The list is longer than most companies assume. The most common "customers" of a sandbox are:
- ERP upgrades (e.g. yearly upgrade of Optima to a new version, quarterly enova365 patches). This is where you find clashes with add-ons written for older versions.
- Changes to the chart of accounts, accounting schemes, document definitions. It is easy to block invoice issuing or cost posting with one badly-ticked option.
- New add-ons, integrations, reports. Every add-on from an external vendor must be verified on your own data — the vendor's demo always works.
- Imports of large data sets (e.g. a price list from a supplier, a 5,000-product batch from a wholesaler). It is easy to wipe out the product master with a wrongly-mapped import.
- Permission changes — who sees what, who can approve. An innocent role tweak can cut sales reps off from the price list.
- Emergency procedures — restoring from backup, switching the database. If you are running the procedure for the first time during a real outage, you do not have a procedure.
The rule is simple: if the change touches anything with "accounting" in its name or affects invoicing — test it in the sandbox. Period.
What it usually looks like without a sandbox
At one of our clients — a 30-person furniture manufacturer running Comarch Optima with a custom WMS — changes were rolled out the traditional way: on Friday after 4pm, "because nobody is working then". Within six months there were three Mondays on which invoices could not be issued because something had broken. Each one cost on average 4 hours of invoicing downtime (the bookkeeper hunting for the cause, two sales staff waiting, the customer waiting), plus the stress. Total: 12 hours of productive work wasted, plus reputation with a handful of customers who got their invoices late.
After introducing a sandbox (database copy refreshed every Wednesday, identical chart of accounts, SMTP cut off) the rule became simple: every change first on the test environment, only then production, and only between 4pm and 5pm on Friday. Over the next 12 months: zero blocked Mondays caused by changes. The average time needed to test one change grew by 30–45 minutes. You can do the ROI math yourself.
The "savings" that cost the most
The most common arguments against a sandbox in an SME — and what usually turns out to be true:
- "We have backups, we'll roll back if needed." Correct. Except that restoring the database at 9am on Monday means losing every document issued since Saturday morning and blocking work for 1–3 hours. Backup is the last resort, not a testing tool.
- "It's a small change, no point testing." Most serious outages start with a "small change". In Optima, one wrongly-ticked field in a document definition can cause two weeks of goods-issued notes to skip their cost postings — and you find out at month-end close.
- "The vendor tested it on their side." The vendor tested on their environment, with their chart of accounts and their add-ons. Yours are different. The fact that it works for them guarantees nothing.
- "A sandbox is expensive." It isn't. The simplest version is an extra Optima instance on the same server, a database copy refreshed by a script every week, and external connections cut off. Real cost: a few hours of work once, plus a bit of discipline.
How we usually roll it out in 2 weeks
In practice the project is simpler than it sounds:
- A second instance of the system. Most often on the same server, under a different database name. In Optima / enova / Subiekt it's a matter of one installation and attaching the database copy.
- Cutting external integrations. The sandbox SMTP doesn't send mail to real customers. The sandbox bank API doesn't execute transfers. The sandbox WMS doesn't touch the real warehouse. It sounds obvious — which is exactly why people forget about it.
- A refresh script. Once a week (usually overnight Friday to Saturday) the test database is overwritten with a fresh copy of production. So you test on real data, not on a museum exhibit from six months ago.
- A short procedure on paper. Three sentences: every ERP change first on the sandbox, documented in one file, only then production. Without this procedure, the sandbox grows dust within two months.
Total: 5–10 hours of admin work in the first week, then 1–2 hours a month to maintain.
Common traps
- Sandbox too old. If the copy is six months old, the tests are worthless — the production chart of accounts already looks different. Refresh it.
- Sandbox with real customer data sent outside. If a vendor asks for "a database copy for analysis", think about GDPR before you zip it up. Best practice: anonymise names and tax IDs before sending.
- Sandbox with no owner. If nobody is responsible for it being current and cut off from the outside world, after a year it turns out someone wired it to the real SMTP and sent test invoices to 200 customers. Assign one person.
Where to start
The simplest first step is answering this question: where did we test the last ERP change? If the answer is "on production, on Friday after 4pm", you have your answer on whether you need a sandbox.
If you are running Comarch Optima, enova365 or Subiekt and want to stop playing roulette with invoicing, talk to someone who has set up sandboxes for these systems and knows what to cut off first. The first call is free and takes half an hour.
A test environment is not a corporate luxury. It is the cheapest insurance policy you can put on an ERP — provided someone actually uses it.