The short answer
PMS migration acceptance criteria state, before cutover, which populations and workflows must be tested, the evidence and tolerance for each, who decides, and what happens on failure. Cover identity and relationships, balances and open items, permissions, integrations, documents, reports, and critical workflows. Record conditional passes as owned exceptions, never as silent success.
Operational checklist
Mark your progress, then save a working copy. Selections reset when you leave this page. A checked box is not an approval or evidence of completion.
☐
Source and destination snapshots identified
☐
Domain populations defined
☐
Test method and tolerance written before results
☐
Relationships and workflows included
☐
Not-tested state preserved
☐
Conditional passes bounded and owned
☐
Final approver and release decision recorded
0 of 7 marked
Key takeaways
- Define criteria before reviewing results.
- Test relationships and workflows, not just row counts.
- Conditional acceptance needs limits, owner, deadline, and release impact.
Write criteria as reproducible questions
“Data looks good” cannot be independently checked. Name the source population, destination evidence, sampling or full-population method, tolerance, tester, and approver. Freeze source and destination versions used for the decision.
Separate migration completeness from software suitability and staff readiness. A pass in one domain must not erase failure in another.
Use a domain acceptance gate
Every domain receives pass, conditional pass, fail, or not tested. Not tested is not a pass.
| Domain | Acceptance evidence | Failure example |
|---|---|---|
| Identity and relationships | Counts plus parent/child and cross-reference tests | Lease exists but points to wrong unit |
| Balances and open items | Control totals, item lineage, cutoff proof | Totals net to zero across properties |
| Documents | Inventory, association, open/read sample, exceptions | Files counted but unreadable |
| Permissions | Role tests using representative users | Former user retains access |
| Integrations | Source event through external outcome and receipt | Connection exists but callback fails |
| Critical workflows | Scenario tests with acceptance evidence | Payment posts without intended ledger result |
| Reports | Defined reports reconcile to accepted records | Owner statement uses wrong cutoff |
Bound conditional acceptance
A conditional pass states the exact exception population, business impact, compensating process, owner, deadline, and re-test criterion. If those fields cannot be stated, the condition is not controlled.
Keep the decision authority explicit. A migration vendor can supply evidence; the accountable operating owner accepts the result under the organization’s governance.
Prove what changed after the tested snapshot
Acceptance evidence expires when source records continue changing without a controlled delta process. Link the baseline extraction to the final delta register and show how creates, updates, deletes, provider events, and documents reached one supported target disposition.
Include effective-access tests and report-definition comparability. Matching row counts cannot show that permissions deny the right actions or that a familiar report label retained its historical meaning.
Define post-cutover stabilization and source retirement separately
Acceptance should name how post-cutover defects are captured, contained, assigned by domain, corrected through versioned releases, and reconciled across the affected population. A quiet support queue is not evidence that target records are correct.
Retain the source in its approved read-only or rollback role until archive retrieval, audit history, residual integrations, scheduled jobs, access, and first-cycle evidence meet explicit retirement gates. Go-live and decommissioning are different decisions.
Reserve a separate gate for the first live close
Pre-cutover testing cannot prove that migrated openings plus a full period of live receipts, charges, invoices, corrections, bank activity, reports, and integrations will close together. Define the first post-cutover close as a separate acceptance event with its own population, cutoff, difference bridge, approvers, and release impact.
Classify differences as opening, live transaction, configuration or mapping, timing, presentation, or unknown. Keep recurring-charge expectations and scheduled-job execution evidence linked but distinct: a job can run once and still produce the wrong business charge.
Edge cases
- Source data changes during testing: identify the delta or refreeze instead of comparing moving populations.
- A test environment differs from production: record the limitation and production verification step.
- A legacy field has no destination: approve its disposition and retrieval path rather than silently dropping it.
Sources and references
Follow each source to check the underlying claim. Access checks and professional review are different steps.
1. Primary source · National Institute of Standards and Technology
Contingency Planning Guide for Federal Information SystemsContingency planning connects recovery priorities, backup, alternate processing, testing, and recovery procedures. Applied here as a limited migration-planning analogy.
Source checked 2026-09-18
Automated source-access check: 2026-09-18.
Continue the workflow
pms migration reconciliationPMS post-cutover defect triageSource-system decommission acceptance after PMS migrationPMS migration delta capture after the source freezePMS user-role migration verificationHistorical report comparability after a PMS migrationFirst post-cutover close acceptanceRecurring-charge reconciliation after PMS cutoverRevision history
2026-09-18
Initial Phase 2 operational article with an original decision artifact, explicit failure states, primary-source scope notes, and AI-assisted technical review.