How can I verify a workspace migration before inviting everyone to switch?

Treat the migration as a small acceptance test, not just a visual check that the new workspace opens. First, name the people who can judge each area: a data owner for records, a process or team owner for relationships and settings, and an administrator or access owner for permissions. One person may hold more than one role, but write down who is signing off on what.

Agree on a few important workflows and records to test. Include ordinary examples and cases the team depends on, such as a record with linked items or a less common status. Use only records you are authorized to inspect. Decide in advance what counts as acceptable and what must be fixed before the switch.

Choose a manageable sample that reflects how the workspace is actually used, rather than picking only the easiest records. For example, include records from different teams or work stages, plus a few important exceptions. If a particular record type or workflow is essential, test it directly even if it is uncommon.

For each sample, compare the source and destination using the same agreed fields: a stable identifier, owner, status, key dates or values, and any other information the team relies on. Keep a simple result log. A sample can reveal issues, but it cannot establish that every untested record is correct; decide whether additional checks are needed based on the importance of the data and what the test finds.

Open linked items from both directions where the workflow uses them: for instance, check that a project shows its expected tasks and that a task points back to the intended project. Confirm that labels, ownership, statuses, and other meaningful links still make sense in the destination. Do not assume a relationship is intact just because both separate records exist.

For settings, make a short list of the choices that affect daily work, such as required fields, naming conventions, notifications, or workflow steps, if your workspace uses them. Compare those choices with the agreed source or team requirements. The process owner signs off on whether the destination supports the intended work; the data owner signs off on the sampled content. If a setting has no clear owner or expected value, record that as an open decision rather than guessing.

Ask the access owner to review the intended roles, then test representative accounts or roles where your organization permits it. Check that a person who should use a workspace can reach the relevant area, and that a role intended to have narrower access does not appear to have broader access than expected. Avoid testing with real users in ways that expose information or change records without approval.

The administrator can confirm the configured access, while a team or resource owner should confirm whether those access levels match the work. Record the role tested, the expected access, the observed result, and who reviewed it. This review is not a substitute for your organization’s access policies; if the intended boundary is unclear, pause and ask the responsible owner to define it.

Use a short acceptance record that makes exceptions visible. For example:

Area: Relationships Sample or workflow: [project and linked task] Expected: [relationship and values] Observed: [what the destination shows] Result: [pass / issue / not checked] Issue owner and next step: [name or role / action] Sign-off: [process owner / date]

Repeat it for records, settings, and permissions. Ask each named owner to sign off only on the area they reviewed, and note any limits to their review. Hold the team-wide invitation if a critical workflow, required information, or intended access boundary has an unresolved issue. For lower-priority gaps, name an owner and due date, explain the temporary workaround if there is one, and get the appropriate decision-maker’s approval before proceeding. Then invite a small pilot group first if that fits your rollout plan, collect issues, and review them before broad adoption.