There is no separate test phase: each layer runs when its object is ready, and the rehearsal is the UAT. Because the platform is standard, testing is about the customer’s configuration, data and integrations — never about re-testing the product.
| Layer | When |
|---|---|
| Configuration checks — each setting verified with sample data in the session | T-17 → T-11 |
| Migration validation — counts, hash totals, TB and sub-ledgers per mock | T-10 → T-3 |
| Integration tests — every endpoint with test partners, error paths included | T-10 → T-4 |
| Role and permission tests — each role sees and does exactly what it should; SoD | T-9 → T-5 |
| Continuity check — a switchover drill if Live DR is contracted; a backup-restore proof | T-5 → T-3 |
| The Rehearsal = UAT — a real business day by the real users, in parallel with legacy | T-2 → T-1 |
Segregation of duties
No role may approve what it created, create a vendor and pay it, change bank details and release payments, or post to closed periods and edit posted documents. Each role must see only its own entities, data and menus, complete every step of its rehearsal tasks, see the right queue items, and use ASK for its own tasks under its own permissions.
Test with each role’s own login, never with an administrator account. A test passed as admin proves nothing about the role.
The rehearsal
Build the script from the customer’s busiest normal day, not a textbook flow: the morning queue, quote to order with the credit check, purchasing, receiving, shipping and invoicing, payables with matching and approval, payroll events, the payment run and bank file, and the day close with the trial balance — each compared with what legacy produced for the same day.
- T-2 prepare — the rehearsal tenant from the dry-run data; the day’s real documents collected; every user logged in with their queue live; observers per process.
- T-1 run — users enter their real day in TRANXACT while legacy runs it as normal; ASK and the Navigators support in the flow; issues logged with time and role.
- T-1 evening close — results compared with legacy; the fix list executed and re-checked; the gate criteria scored; the Countdown Owner decides.
The go / no-go (proposed default)
| Criterion | Threshold | Blocks go-live? |
|---|---|---|
| Rehearsal processes passed | 100% of critical; 95% or more of all steps | Yes |
| Results match legacy | Totals equal or explained | Yes |
| Dry-run reconciliation | Zero TB delta; sub-ledgers tie | Yes |
| Dry-run duration | Within the cutover window | Yes |
| Critical defects open | 0 | Yes |
| Users rehearsed in their own role | 95% or more of T+1 users | Review |
| Integrations production-ready | Endpoints and credentials confirmed | Scope out if not |
A NO-GO is not a date slip by default. The Countdown Owner can take failed scope out to T-Plus and still go live on T-0 with what passed.
Defect triage, in the standup
- Critical — stops a core process, a wrong financial result, or data loss: fix before the gate, or take the process to T-Plus with a manual interim.
- High — works with significant effort: fix the same day; retest in the rehearsal.
- Medium — a simple workaround exists: fix within two weeks of go-live.
- Low — cosmetic: a Fit Ledger line tagged T-Plus.
At Calderwood’s rehearsal every critical step passes except the payment run: the bank file is produced but the bank’s production credentials have not been issued. Integrations that are not production-ready are "scope out if not" — so the Countdown Owner takes the bank integration to T-Plus with a manual bank-file upload as the interim, and records GO.
Try it At T-1, 91% of Calderwood’s T+1 users have rehearsed in their own role. Does that block go-live?
Not automatically: users rehearsed below 95% is a "Review" criterion, not a blocker. The missing users get a scheduled catch-up on T-1 afternoon, are flagged in the adoption register, and anyone still not ready gets a named buddy for their first week.