Acceptance criteria turn a requirement into conditions that can be checked. They state what a reviewer must observe to accept a capability, workflow, migration result, or release. During SaaS replacement, they give business owners and delivery teams a common basis for deciding whether the new system is ready.
What acceptance criteria describe
Criteria focus on outcomes rather than implementation tasks. They can describe a successful path, an exception, a permission boundary, a data change, an integration response, or a quality condition. Together, they define the evidence needed for acceptance.
| Criterion type | Example subject | Evidence |
|---|---|---|
| Workflow | User completes a required business path | Recorded scenario result |
| Data | Required fields and relationships survive migration | Reconciliation output |
| Permission | A role can perform only allowed actions | Access test result |
| Integration | A downstream system receives the correct event | Interface record or test |
| Exception | Invalid input is rejected and explained | Observed error behaviour |
| Operation | A required recovery action succeeds | Exercise and recorded result |
Criteria should use language that the responsible reviewer can interpret consistently. Terms such as “works correctly” or “user friendly” leave the decision open because they do not identify a condition or expected result.
How criteria are derived
Functional requirements supply the required behaviour. Workflow maps add roles, decision paths, and exceptions. Data mapping and integration specifications add field, relationship, and interface expectations. Non-functional requirements contribute measurable operating conditions.
A practical set covers:
- Starting state: the user, role, records, and system conditions before the action.
- Action or event: what triggers the behaviour being reviewed.
- Expected result: the visible state, output, message, or downstream change.
- Exceptions: invalid or unusual conditions that need defined handling.
- Evidence owner: the person or role authorised to accept the result.
This structure keeps a criterion connected to a real need while allowing different test techniques.
Criteria across replacement stages
Early criteria can support a prototype or pilot by defining which questions it must answer. Delivery criteria guide feature review. Migration criteria cover completeness, relationships, transformations, and exceptions. Cutover criteria combine evidence from workflows, data, integrations, security, operations, and support.
Data validation supplies evidence for migrated records, but valid data alone does not prove that a complete workflow works. Acceptance criteria connect those records to the actions and decisions they must support.
Acceptance and approval
A passing technical test does not by itself provide business acceptance. The test demonstrates a condition; the designated owner decides whether the evidence satisfies the agreed criterion. Failed criteria need a recorded disposition: fix the system, change the requirement through an approved decision, defer the capability, or stop the release.
The account of work spread across several SaaS tools shows why interface checks are not enough. Criteria must cover the business path across tools, data, roles, and handoffs, including behaviour that previously sat outside the main product.
