Agree on scope and the person who decides
Start with the approved brief, the release identifier, the destination environment and the URLs being replaced. Name the client approver, the agency release operator and a substitute for each. Agree when they will be available and which communication channel will hold the decision.
Prepare a controlled test inbox, synthetic form data, permitted test accounts and an evidence folder with restricted access. Decide which checks happen in rehearsal and which require the live destination. Set a launch-blocking threshold before testing: for example, missing enquiries, broken administrator access or unexplained data differences require refusal.
Write a small grid of observable outcomes
Use one row per test, with a stable identifier. Split rows when different people or evidence are needed. The examples below are criteria to adapt, not a completed acceptance record. Add tester, actual result, evidence reference and approver decision columns to the working copy.
Scroll horizontally for all table columns.
| Area | Expected result | Useful evidence |
|---|---|---|
| Forms | One synthetic enquiry reaches the agreed destination once; invalid input receives a usable explanation. | Submission reference and redacted receipt. |
| Redirects | Each agreed old URL reaches its intended replacement without a loop. | Source URL, status chain and final URL. |
| Access | The client editor can publish within scope; restricted administration remains unavailable. | Role-specific test notes. |
| Scheduled jobs | The intended host runs the job at the agreed time and produces its expected output. | Scheduler record and output reference. |
| Data | Agreed records, uploads and relationships survive the move. | Comparison sheet and selected functional checks. |
| Approval | The designated approver records accepted, refused or explicitly accepted exceptions. | Decision linked to the tested release. |
Follow a form beyond its success message
Test an empty submission, invalid input and a valid synthetic enquiry. Use the keyboard to reach fields, understand their labels, correct errors and submit. W3C's forms guidance explains that required inputs need clear identification and that browser validation does not replace validation on the server. Include both in the developer's test scope.
Then verify the agreed downstream result with its owner. A browser success message alone does not prove receipt in an inbox or CRM. Confirm the field values, destination and duplicate handling. Keep personal data out of screenshots. Repeat an appropriate task as a client editor and check that a restricted operation is denied.
Check the route, not just the destination page
Agree on an old-to-new URL list, including important campaign links and required query parameters. Record the HTTP status chain as well as the page reached. MDN distinguishes permanent and temporary redirects and documents differences in how redirect codes handle request methods. A redirected form submission therefore needs its own test; opening the destination with a normal page request is insufficient.
Reject loops, unexpected domains and missing destinations. Avoid placing confidential query strings in evidence.
Give background work and data their own checks
For each scheduled task, record its purpose, host, execution identity, timezone, schedule, expected output and person who receives failures. During rehearsal, redirect outbound messages to a controlled destination. Establish when the old host stops running the task and when the new host becomes responsible, so a migration does not leave two active schedulers.
Define the data cutoff and compare the agreed record totals, selected field values and uploaded files. Open representative records through the application to check relationships and permissions. Counts alone are insufficient: equal totals can contain different records. Record any deliberately excluded historical data and obtain the client's decision.
Example: a catalogue launch that should wait
In this fictional scenario, an agency is moving a workshop's catalogue and enquiry form. The client approver accepts the content and redirect checks, but a synthetic enquiry reaches an obsolete mailbox. The nightly catalogue import also remains enabled on the old host. The result is refused for launch, with both failures assigned to the release operator.
The operator corrects the recipient and scheduler ownership, then supplies fresh evidence for those rows and repeats the affected form and data checks. The approver reviews the same release identifier before changing the decision. A minor image crop can remain an explicit exception with an owner and due date if the client agrees; silence is not acceptance.
Verify the decision and keep its limits visible
Before closing, confirm every required row has a result, every failed row has a resolution or recorded exception, and the approver's decision identifies the release and time. If the build or configuration changes afterwards, reopen affected checks. Store concise evidence with an agreed retention period and keep access details in the team's secure systems.
This checklist establishes project acceptance within its stated scope. It does not establish accessibility conformance, security assurance or future availability. Arrange specialist review where the project requires it. Next, carry the accepted release, open exceptions and named operators into the ongoing responsibility record.
Sources & review
Technical references were checked on September 12, 2026. Examples are planning exercises; referenced software documentation does not establish PrivateHostLab service capabilities.