An internal tool that works is easy to leave alone and hard to change. Every small request, such as a new field, a changed report or a different rule for discounts, carries a risk: the change may work on the developer's machine and still break something on Monday morning when twelve people are using the tool. A staging copy is the cheapest protection against that.
A staging copy is a second installation of the tool, separate from the live one, where a change can be tried, shown and corrected. Staff do not work in it. This article describes what it should contain, who uses it and how a change moves from it into live work. It is written for owners and managers of small companies that depend on a custom tool and for whoever looks after it.
Why test away from live work
Three things go wrong when changes are tried directly on the live tool:
- Mistakes touch real records. A wrong import or a badly written rule can alter orders, prices or customer notes, and cleaning up afterwards takes longer than the change itself.
- Staff see unfinished work. A button that moves, a field that disappears for an hour or an error message erodes trust in the tool, and people start keeping their own spreadsheets again.
- Nobody can compare. If the only copy is the live one, you cannot check what the change did against how things worked before.
A staging copy does not need to be elaborate. For a small tool it can be a second small server or a second site on the same hosting plan, with its own database and its own address.
What to copy and what to leave out
Copy the structure: the same version of the code, the same settings, the same user roles. If staging differs from the live tool in how it is built, a test there proves little.
Copy realistic data, because a tool with five demo records hides the problems that appear with five thousand. But treat personal data carefully. Customer names, e-mail addresses, phone numbers and notes should not sit in a second place with weaker protection. Either replace them with invented values or scramble them while copying, so the records still look and behave like real ones. Check what applies to you in the rules on personal data before you copy anything.
Leave out the connections to the outside world. Staging should not send e-mails to customers, write to the accounting system or charge a payment. Point these to a test inbox or switch them off, and check this first, because an invoice reminder sent from a test is the most common and most embarrassing mistake.
Make the copy look different
People confuse the two tools more often than you would expect. Give staging a different address, a coloured banner with the word "TEST" on every page and, if possible, a different login. Anyone who opens it should know at once where they are.
Who tests
Developers check that the change works. They do not always see whether it fits the daily work. Ask one or two people who use the tool every day to try the change with their own typical tasks, for about half an hour. Picking the first user of a new internal tool describes how to choose such a person.
Give them a short list instead of "have a look": the three things the change should do, and two things that should stay the same. A change that fixes one report and quietly alters another is a typical staging catch.
Approval
Before the change goes live, one named person says yes. In a small company this is usually the owner of the tool or the manager of the team that uses it. Write down in the change request, in one or two lines, what was tested, by whom and on what date. That note is also useful later, when someone asks why something behaves as it does. If changes arrive through a regular intake, see handling change requests after launch for how to keep them in one list.
Small and urgent fixes can be shortened, but not skipped. A typo in a label can go with a quick look. A change to a calculation, a permission or an import always goes through staging.
Releasing and going back
Choose a quiet time for the release, tell staff beforehand if anything will look different, and take a backup of the live data immediately before. Agree in advance how you would go back: restoring the previous version of the code, and, if the change touched the data, restoring the backup. If you have never restored a backup, try it once on staging. A backup and restore test for a small company explains how.
After the release, the person who approved it opens the live tool and repeats one or two of the test tasks. If something is wrong, go back first and investigate afterwards.
Keeping staging useful
A staging copy that is months out of date is worse than none, because tests on it give false comfort. Refresh the data from the live tool, with personal data masked, before testing larger changes, and keep the code version in line with the live one. Once a year, check that the e-mail and payment connections are still switched off.
Common mistakes
- Real e-mails from a test. Switch off outgoing messages before the first copy.
- Unmasked personal data. A copy of the customer table is still a customer table.
- A copy nobody updates. Refresh it before each larger change.
- Testing only by the developer. Add one daily user.
- No way back. Decide how to revert before you release.
A first step
If you have no staging copy yet, start with a conversation, not a server. Ask whoever maintains the tool: where could we try a change without staff seeing it, and how would we copy the data safely? The answer usually shows whether this is an afternoon of work or a small project, and either is cheaper than one bad Monday.
Sources
- Practical guidance based on common software maintenance practice, offered as a planning aid. The examples are invented for illustration. No client results or performance figures are claimed in this article.