Implementation worksheet · 6 min read
How to Run a Parallel Trial Before Replacing an Existing App
Run both systems on the same real work for at least one full business cycle — a month for anything with monthly reporting, a quarter if quarterly processes exist. Pick a named set of workflows to compare, keep the old system authoritative throughout, and record every divergence rather than fixing it silently. The trial ends on a written criterion decided in advance, not on a feeling: every named workflow completed in the new system, all divergences either resolved or accepted with a reason, and one full cycle-end process run successfully in parallel. Most replacements that fail do so because the trial was shorter than the cycle that exposes the problem.
An existing application has years of undocumented behaviour: the edge case someone handled in 2023, the report a single person runs at month end, the field that means something different for one customer. None of it is in a requirements document, because nobody wrote one. A parallel trial is the only reliable way to surface it before the old system is gone.
Put it into practice
1. Name the workflows to compare, in the users' words
'Raise an invoice for a project with mixed billing', not 'invoicing'. Specific enough that someone can do it and say whether it worked. A short list of the ten workflows that actually matter beats a complete inventory nobody runs.
2. Keep the old system authoritative for the whole trial
The new system runs alongside but does not own anything yet. This is what makes a trial safe to fail, and it is the discipline that slips first — the moment something is only in the new system, you have cut over without deciding to.
3. Run for at least one full business cycle
Month-end closes, quarterly reports, renewal runs and annual processes all reveal things daily use does not. A two-week trial on a monthly business tests the easy part. If a quarterly process exists and you cannot wait a quarter, at minimum rehearse it against real data.
4. Log every divergence without fixing it immediately
Different number, different behaviour, something the old system did that the new one does not. Record it, then triage as a batch. Fixing divergences as they appear means never seeing the pattern — and the pattern is usually that one assumption is wrong in eight places.
5. Have the real users do the work, not the project owner
The person who specified the replacement knows what it should do and will unconsciously avoid the paths it handles badly. The person who does the job daily will hit them in an hour. This is the difference between a trial that finds problems and one that confirms hopes.
6. Write the exit criterion before starting
Every named workflow completed in the new system, every divergence resolved or explicitly accepted with a reason and an owner, and one cycle-end process run in parallel successfully. Written in advance, because a criterion invented at the end is whatever the person who wants to ship decides it is.
7. Decide what happens to the old system, and when
Read-only for a defined period, then archived, then deleted — with dates. 'We will keep it around for a while' becomes a system nobody maintains that someone is still quietly using in eight months.
The parallel trial plan
Copy this structure into your review document and record your observed result for each row.
| Element | Your plan | Set |
|---|---|---|
| Workflows to compare (named, in users' words) | ||
| Trial duration | at least one full business cycle | |
| Which system is authoritative | the old one, throughout | |
| Who does the work | the real users | |
| Divergence log location | ||
| Cycle-end process rehearsed | ||
| Exit criterion (written in advance) | ||
| Old system: read-only date | ||
| Old system: archive date | ||
| Rollback trigger during cutover |
A failure worth checking
The trial that ended at two weeks on a monthly business. Everything worked, everyone was satisfied, the old system was switched off. Month-end arrived and the reconciliation report — run by one person, from a view nobody else knew existed — had no equivalent. The replacement was fine for daily work and missing the process the business is measured on, and the system that could have produced it is now read-only or gone. Duration is the single most common shortcut in a parallel trial and the most expensive.
Common questions
Is running two systems not twice the work?
For the trial period, roughly yes for the workflows being compared, and that is the cost of finding out before rather than after. Limit the doubling by comparing the ten workflows that matter rather than everything, and by keeping the trial as short as the business cycle allows — not shorter.
What if the new system is better but different?
Different is fine and should be recorded as an accepted divergence with a reason, not fixed to match the old behaviour. The trap is the opposite: accepting a divergence because changing it is hard, when it is actually a missing capability someone depends on.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.