What testing should be completed before moving a small business to the cloud?

Before approving a small business cloud migration, complete a documented test plan that proves the proposed design works for real users, data and business processes. Testing should be based on agreed acceptance criteria, use a representative pilot group, and produce evidence that any material faults have been resolved or formally accepted.

The testing process should begin with a clear definition of what “ready to migrate” means. A business may require users to access particular systems, work files to retain their structure and permissions, key processes to complete without manual workarounds, and records to remain available for the required retention period. These requirements should be written down before testing starts so that the result is measured against business needs rather than general impressions.

1. Establish a test baseline

Record how the current environment operates before making changes. This baseline can include normal login steps, typical document workflows, report generation, printing, file access, remote working processes and the time required for important tasks. The purpose is not to prove that the cloud environment is identical, but to identify any meaningful change that users or administrators will need to understand.

Also document the systems that each business process depends on. For example, an invoicing process may involve a line-of-business application, shared files, email notifications, user permissions and an external service. Testing the application alone would not confirm that the complete process works.

2. Test a representative pilot

A pilot should include realistic users, devices, permissions and working practices. Selecting only an IT administrator or a technically confident employee can hide problems that affect ordinary users. Include different roles, locations and access requirements, together with less frequently used functions that could be overlooked during routine testing.

Use a controlled sample of business data rather than relying solely on empty test accounts. The sample should include different file types, folder structures, naming conventions, permissions and records with dates or links to other systems. Sensitive information should be handled according to the organisation’s data protection requirements, with test copies anonymised where appropriate.

3. Carry out a migration rehearsal

A rehearsal should follow the planned migration procedure in a non-production environment or with an agreed test set. It should cover preparation, data transfer, account creation, configuration, validation and the handover to users. Record how long each stage takes in the organisation’s own circumstances, where manual intervention is required, and which steps are most likely to cause an error.

The rehearsal should also test the cutover instructions. These need to state who performs each task, in what order, what users must do, and how completion is confirmed. If a step relies on one person’s undocumented knowledge, it is not yet sufficiently controlled for a production migration.

4. Validate user journeys, not just individual features

Ask users to complete end-to-end scenarios that reflect their actual responsibilities. Examples might include creating and approving a document, processing an order, raising an invoice, locating an older record, collaborating on a shared file, or completing a management report. The test should include the expected result, the account used, the data involved and any relevant dependencies.

Capture issues in a test log with a description, severity, owner, corrective action and retest result. A failed test should not be marked complete simply because a workaround exists. Decide whether the workaround is acceptable, whether training is needed, or whether the migration design must be changed.

5. Check administration and support procedures

Administrators should test the tasks they will perform after migration, including creating and disabling accounts, changing roles, applying policy changes, investigating access problems and retrieving audit information. These procedures should be tested using least-privilege administrative accounts rather than a highly privileged account that ordinary administrators will not use.

Documented support procedures should explain how common faults are identified and escalated. Confirm that relevant logs, alerts and administrative records can be accessed by authorised personnel and that the business knows who owns each operational task.

6. Test failure conditions deliberately

Testing should include controlled fault scenarios rather than only successful journeys. Examples include an incorrect password, a disabled user, an unavailable dependency, an interrupted transfer, a damaged file, an expired session or an attempt to access information without the required permission. The objective is to confirm that the system fails safely and that users receive a clear, actionable outcome.

Where the migration depends on third-party applications or integrations, test what happens when an exchange is delayed, rejected or duplicated. Confirm how failed transactions are identified and whether they can be corrected without creating duplicate records.

7. Define approval criteria and evidence

Before the production move, classify findings by risk. A critical issue affecting data integrity, access control, a core business process or the ability to recover should normally block approval until resolved. Lower-risk issues may be accepted with a named owner and a target date, provided they do not undermine the migration’s essential controls.

Keep the test plan, scenarios, screenshots or logs, issue register, retest results and approval record together. The final sign-off should come from both a technical owner and an appropriate business representative. This confirms that the environment is not merely configured correctly, but is suitable for the organisation’s actual work.

Testing is complete when the agreed scenarios have passed, known exceptions have been assessed, administrators understand their responsibilities, and decision-makers have approved the evidence. Any significant change after testing—such as a different data set, application version, permission model or migration method—should trigger a targeted retest before the move proceeds.