ClickUp Workspace Migration Strategy

When migrating a team from one ClickUp Scrum space to a new one, a full data migration is often unnecessary. If tasks are already syncing between the old and new spaces, the migration becomes a permission and visibility switch rather than a data transfer operation.

Core Principle: Hide, Don't Delete

Rather than deleting or archiving the old space, restrict its permissions so only administrators retain access. This preserves historical context and allows oversight during the transition period while presenting the new space as the team's working environment.

Observed in practice: During Asymmetric Marketing's migration to their new Scrum space for Sprint 57, the old "Scrum Sprint" space was hidden from all team members via permission changes, while Melissa and Isalia retained access for oversight. The team simply began working in the new space without any data loss.

Pre-Launch Checklist

Before switching the team over, verify the following:

Task sync is complete — Confirm all tasks from the old space appear correctly in the new space. Discrepancies can occur when tasks were created through different paths (e.g., directly in a sprint list vs. via automation), causing some tasks to exist in only one space.
Sprint numbering continuity — If the team uses sequential sprint numbers, create the first sprint in the new space continuing from the last sprint number in the old space (e.g., if the old space ended on Sprint 56, create Sprint 57 in the new space).
Sprint template is updated — Ensure the sprint list template reflects the desired column layout, protected views, and standardized statuses before the first sprint is created.
Automations are operational — Any Make.com or native ClickUp automations that populate the new space should be tested and confirmed working before the cutover.

Migration Execution Steps

Verify task sync (assigned to ops/admin) — Cross-check task counts between old and new spaces. Investigate with developers if counts differ.
Update sprint template — Lock in the column configuration and protected view settings.
Change permissions on old space — Remove access for all team members except designated admins.
Create the first sprint in the new space — Continue the numbering sequence.
Notify the team — Inform team members before Monday (or the start of the next sprint) so they are not alarmed by the disappearance of the old space.

Timing

Align the cutover with the start of a new sprint. This provides a clean break — the team begins their new sprint in the new space — and avoids mid-sprint confusion about which space is authoritative.

Communication

Team members should be told explicitly:
- The old space will no longer be visible to them
- The new space has the same name (or a clearly communicated new name)
- All their tasks are already present in the new space

Proactive communication reduces support burden during the transition.

^[1] — Standardizing task statuses across spaces is a prerequisite for a clean migration
^[2] — Automation credits can be exhausted during large migrations; plan for a top-up
^[3] — The Done → Historical archiving workflow depends on Make.com automations that must be operational post-migration