How do you know a rewrite still works? Test the rules, not the screens
Short answerWrite your rules down as plain sentences before the rebuild starts, then check the new system against those sentences one at a time. Clicking around and deciding it looks right is not a check. The rules are the part you actually own, and they are the part most likely to be lost quietly.
Sooner or later someone proposes replacing a system you depend on. A new CRM. A database instead of the spreadsheet. A rebuilt website, or the same website on different software. The pitch is nearly always the same: everything works as it does now, only better.
That sentence is a claim, and it is a bigger claim than it sounds. It says every rule your organization has accumulated — including the ones nobody has written down — will behave the same way afterwards. The question worth asking, before any of it starts, is simple: how will we know?
“It looks right” is not evidence
The usual check is that a few people open the new system, click around, and say it seems fine. This finds obvious breakage. It reliably misses the expensive kind.
The expensive kind is a rule that changed silently. A lapsed donor is now counted at twelve months instead of thirteen. An attendee who registers twice is counted twice. A gift that used to trigger an acknowledgement no longer does, at one specific amount. Nothing looks broken, because nothing looks like anything — the screens are fine. You find out a quarter later, in a report you have already sent to a funder.
Write the rules down as sentences
Before a migration begins, get the rules out of people's heads and into a list. Each one is a short sentence that is either true or false about the system, written in your own language rather than the software's:
- A donor with no gift in the last thirteen months is lapsed.
- Someone who registers twice for the same event counts once.
- A gift over $250 generates an acknowledgement letter.
- A volunteer who never attended is not in the volunteer count.
- Deleting a household does not delete its individual people.
This list is worth more than it looks. It is the part of your operation that lives in the software but does not belong to it, and writing it down is the only way it survives a change of system — or a change of staff. Most of the value shows up while you make it, because two people will disagree about a rule everyone assumed was settled. Better to find that in a meeting than in a year-end report.
A worked example, from a game
I recently rebuilt something with no stakeholders at all: a maze game I wrote in college in 2016, ported to run in a browser ten years later. Low stakes, same problem. The port is a claim that the rules still behave the same way, and I had no memory I trusted about what those rules were.
So they got written down and checked automatically, twenty-nine of them, each one a sentence: a donut is always eaten, even at full health. The portal refuses you without the quota. Orbs alone are not enough. Kills alone are not enough. Health never exceeds one hundred. Running out of time ends the run.
None of those are about how the game looks. They are about what it does, which is the part a rewrite quietly changes. The checks run against the real game code in a few seconds, so the answer to “does it still work?” is a list of sentences with a pass or fail beside each one, rather than an opinion formed after playing for a minute. The project and the test list are on the Work page.
A nonprofit database is not a game, and you will not usually get automated checks written for your CRM. You can still get the useful half: the sentences, and someone going through them deliberately after the switch.
What to ask before you approve the work
When someone proposes rebuilding or migrating a system, three questions do most of the work:
- How will you show me the rules still hold? A good answer describes a check. A weak answer describes a demo.
- Which rules are you aware of? If the list is shorter than yours, the difference is what gets lost.
- What happens to the records that do not fit? Every migration has rows that will not map cleanly. Ask where they go, because the default is silently nowhere.
None of this requires technical knowledge on your side. It requires knowing your own rules, which you already do — they are just not written down yet.
Do it before, not after
The list is only useful if it exists before the change. Written afterwards, it gets written from the new system, which means it records whatever the new system happens to do and quietly blesses any rule that shifted. Written first, it is a standard the new system has to meet.
That is the whole method: decide what must stay true, in sentences anyone can read, and check them one at a time. It is not sophisticated. It is just the difference between knowing a rebuild worked and assuming it did.
Ask about a migration or rebuild you are planning, or read how a CRM rollout went in practice.