User acceptance testing, or UAT, asks business representatives to complete realistic work in the replacement and judge the results against agreed conditions. It verifies that the system supports required workflows before people leave the current product. In a SaaS replacement, UAT supplies business evidence for a cutover decision.
What UAT covers
UAT follows complete business scenarios rather than isolated technical components. A scenario can cross roles, permissions, records, reports, notifications, and connected systems. It should include common work and material exceptions that users must handle after launch.
Acceptance criteria define the expected results. Testers provide evidence by completing the scenario, recording what happened, and identifying any difference between the expected and observed outcome.
| UAT area | What testers verify | Typical evidence |
|---|---|---|
| Workflow | Required task can reach its business outcome | Completed scenario record |
| Roles | Each participant sees and performs allowed actions | Access observations |
| Data | Records are accurate and understandable in context | Compared examples |
| Exceptions | Users can recognise and resolve unusual cases | Exception results |
| Outputs | Reports, documents, and notifications support the work | Reviewed output |
| Handoffs | Connected teams and systems receive what they need | End-to-end trace |
Preparing representative scenarios
Scenarios come from workflow maps, requirements, support cases, known exceptions, and the data shapes users encounter. They need a clear starting state, named roles, test data, steps or goals, expected results, and a place to record evidence.
A useful UAT plan identifies:
- Participants: business representatives with knowledge of the workflow and authority to review it.
- Scope: the workflows, roles, integrations, and exceptions included in the test cycle.
- Environment: a stable setup that represents the relevant production configuration.
- Data: realistic, controlled records covering normal and edge cases.
- Issue handling: ownership, severity, retest rules, and allowed dispositions.
- Exit decision: the criteria and approvers required to close the cycle.
Test environment differences should be recorded because missing integrations, changed configuration, or unrealistic data can hide defects or create misleading failures.
UAT is not general exploration
Exploratory feedback can reveal useful issues, but UAT needs traceability to agreed requirements and criteria. It is also separate from unit, integration, security, performance, and recovery testing. Those activities provide other evidence that may support acceptance but do not replace business review of the complete workflow.
Testers need enough guidance to reproduce results without being coached toward a pass. A failed scenario should identify the observed difference and its impact. The delivery team can then fix it, clarify the expected behaviour, or route a scope decision to the authorised owner.
Using the results for cutover
UAT results become one input to the go-live decision. Open issues are assessed alongside migration evidence, integration status, operational readiness, support arrangements, and rollback conditions. A pass means the agreed scenarios met their criteria in the tested conditions; it is not proof that every future situation has been exercised.
The story of replacing work built across multiple SaaS products shows why testing must follow the whole task. Users experience the handoffs and outcomes, not the internal boundaries between applications.
