What is a safe way to run an old and new workspace during a staged migration?
Quick answer
Run the migration in defined phases, and name one authoritative workspace for each type of information in every phase. Before a group switches, explain where to work and how to report changes. Track changes made during the transition in a shared log, then compare the old and new workspaces at a scheduled reconciliation checkpoint. Keep the old workspace available until discrepancies are resolved or assigned, and an accountable owner approves retirement.
The question, the details, the next step.
We need to move teams from an old workspace to a new one without switching everyone at once. How do we keep both usable without creating two competing versions?
The key is not to treat both workspaces as equally authoritative for everything. Decide which one is the source of truth for each category of information during each phase, and tell people where to make changes.
A practical timeline could look like this:
- Prepare: List the information and teams in scope; name owners; set a proposed switch date and reconciliation checkpoint.
- Pilot: Move a small, defined group or set of information. State which workspace is authoritative for it and how to report errors or changes.
- Staged rollout: Switch additional groups in batches. Keep a record of who switched and when, and set authority separately for anything not yet moved.
- Reconcile: Compare agreed information in both workspaces, resolve or assign discrepancies, and record approval.
- Retire: Only after reconciliation and owner approval, follow your organization’s process for ending use of the old workspace.
For example, assume Team A moves on Monday and Team B moves the following week. Monday onward, the new workspace could be authoritative for Team A’s migrated project records, while the old workspace remains authoritative for Team B’s records. Those are planning assumptions: choose rules that fit your actual setup.
What if someone updates an item in the old workspace after their group has moved?
Give people a simple exception path instead of relying on memory or informal messages. Ask them to record the item, its location, what changed, when, who made the change, and whether the new workspace has been updated. Assign a person to review each entry and either apply the change to the authoritative workspace, explain why it should not be applied, or escalate it to the information owner.
A short transition notice might say:
“From [switch date], use [new workspace] for [information or team]. Do not make routine updates to that information in [old workspace]. If you find or make a necessary change there, log it at [approved change log location] with the item and change details. [owner or role] will review it by [review interval]. For anything outside this scope, continue using [current authoritative workspace].”
Use approved internal locations and roles in place of the brackets. Avoid putting sensitive content in a log unless your organization’s process allows it; a reference to the item may be enough.
How do we handle information that is being copied in batches, when some items have moved and others have not?
Track migration status at the same level at which people make decisions. If items move individually, mark each item’s status; if a whole project or team moves together, a group-level status may be enough. At minimum, use statuses such as not started, in progress, moved—needs checking, and checked.
For every group or item, record its current authoritative location, its move date, and an owner. Until an item is confirmed as moved and checked, keep its authority assigned to the old workspace if that is your chosen rule. Once confirmed, update the status and tell affected people that future changes belong in the new workspace. Don’t infer that an entire batch is ready just because some of its contents have been copied.
What exactly should happen at the reconciliation checkpoint before we retire the old workspace?
Schedule the checkpoint before the planned retirement date and invite the people accountable for the information, migration, and team communication. Agree in advance what will be compared—for example, the list of in-scope items, their expected owners, and any changes logged during the transition. The comparison method should fit the information and tools available; don’t assume a workspace has a built-in comparison or audit feature.
Review missing items, duplicates, conflicting updates, items still in progress, and unreviewed log entries. For each discrepancy, record a decision, an owner, and a due date. If something cannot be resolved at the checkpoint, keep the old workspace available under the agreed authority rules and set another review date rather than treating uncertainty as approval to retire it.
Close the checkpoint with a written decision: what was checked, what remains open, who accepted the outcome, and whether retirement is approved or deferred. Then send a final notice naming the authoritative workspace and the effective date.
A practical checklist
List the information and teams in scope, with an owner for each.
Name the authoritative workspace for each category in every migration phase.
Record batch status, switch dates, and who has been told to use the new workspace.
Provide a change log with an owner and a review process for transition-period updates.
Schedule reconciliation; track discrepancies to a decision, owner, and due date.
Retire the old workspace only after the agreed checks and accountable approval.
A few more useful answers
Can the old workspace remain authoritative for some information after the new one launches?
Yes, if you define that boundary clearly. Identify the information, owner, and switch condition so people know which workspace to use for each item.
What if a discrepancy is still unresolved at the checkpoint?
Record it with an owner and due date, keep using the agreed authority rule, and defer retirement if the unresolved issue prevents an accountable decision.
Who should approve retiring the old workspace?
Choose an accountable owner or role in advance, such as the person responsible for the affected information or the migration decision. The appropriate approver depends on your organization.