Collaboration suite migration playbook: moving platforms without losing control

Moving from one collaboration suite to another copies years of files, chats and sharing decisions into a platform whose permission model is different, while a migration identity with read access to everything runs for weeks and the old suite keeps answering in the background. Organisations switch suites after acquisitions, on cost or sovereignty grounds, or to consolidate chat, file storage and meetings onto one platform. Security controls rarely translate one to one: external sharing defaults, guest models, retention rules, labels and third-party integrations all work differently. This vendor-neutral playbook is for IT, identity and security teams running a cross-platform move. It covers the inventory, mapping the permission and sharing model, the migration identity and integrations, retention and legal holds, a phased cutover with rollback, and decommissioning. Moves between two tenants of the same product are covered in Tenant-to-Tenant Migration Security, and mailbox moves in the Email platform (mail server) migration playbook.

Key takeaways

• Migrate the controls, not just the content. Sharing settings, guest access, retention, labels and admin roles must be redesigned for the target, because they rarely map field for field.
• Do not copy oversharing. Anonymous links, everyone-in-the-organisation groups and stale guests should be reviewed before migration, not faithfully reproduced.
• The migration identity is your most dangerous account for the duration. It can read every workspace in the source and write every workspace in the target; scope it, monitor it and delete it on a date.
• Re-authorise integrations instead of carrying them over. Bots, apps and OAuth grants are a fresh decision on the new platform, with owners and least-privilege scopes.
• Decommission deliberately. Freeze, export what retention and legal holds require, revoke tokens and integrations, then delete the old tenant with written confirmation.

What has to move, and what should not

Build the inventory by object type from the source suite's admin reports and APIs, and give each object an owner and a decision: migrate, archive or retire.

ATT&CK T1213.005 Messaging Applications and T1530 Data from Cloud Storage describe how attackers mine exactly this content, which is why a clean-up before migration reduces risk on both platforms.

Mapping the permission and sharing model

Collaboration suites differ most in how access is granted. Translate the intent of each setting, then test it, rather than relying on a migration tool's defaults.

Before go-live, sample migrated workspaces and compare effective access in the source and target for the same users, including a guest and a user from a different department. The Collaboration Tool Security Guide covers the target-side settings in more depth.

Where identity fits: migration, user and integration identities

• The migration identity: migration services need application credentials with read access to all source content and write access to all target content. Use a dedicated application or service account per side, scoped to the workspaces in the current wave where the platforms allow it, held in a secrets manager, restricted by network location where possible, and set to expire. Remove it on a scheduled date, not "after the project".
• The migration vendor: if a third-party service moves the data, it is processing your content. Confirm data location, encryption, deletion of its working copies and how its staff access are controlled, and put this in the contract.
• User provisioning: provision users and groups into the target from the identity provider using SCIM (RFC 7644) so joiners and leavers flow automatically from day one. RFC 7644 deletion returns 404 for the removed resource, which gives a testable deprovisioning check. See the SCIM Provisioning Guide.
• Administrators: the NCSC's lightweight cloud security guidance expects administrator accounts to be separate from standard users and two-factor authentication to be enforceable for all users. Enforce phishing-resistant MFA for target admins before any content arrives.
• Integrations: every bot, app and webhook is a non-human identity with tokens and scopes. Re-register each on the target with an owner, the minimum scopes and a review date, and revoke its source tokens at cutover. See the SaaS and OAuth App Governance Guide.

Integration tokens are a proven route into collaboration and SaaS data. The Salesloft Drift breach showed how OAuth tokens held by one chat integration opened data in hundreds of customer tenants, and the Slack GitHub breach involved employee tokens held by a vendor. A migration is the moment to cut integrations down to those that are owned and needed.

Retention, legal holds and evidence

• Identify holds first: ask legal for every active hold and investigation, and which custodians and spaces they cover. Content under hold must remain preserved and searchable throughout, either migrated into an equivalent hold on the target or kept in the source until the hold is released. See the eDiscovery and Legal Hold Guide.
• Retention policies: recreate them on the target before migration, otherwise content with a minimum retention period can be deleted by users immediately after it lands.
• Metadata fidelity: authors, timestamps and edit history matter for evidence. Check what the migration preserves and keep a source export where it does not.
• Audit logs: export source audit logs for the period your policy requires before the source is closed; they are not migrated with content.
• Personal data: a migration is processing under data protection law. Record it, and use it to delete content that is past its retention period rather than moving it.

The phased playbook

1. Prepare the target: identity provider integration, SCIM provisioning, admin roles, MFA, restrictive sharing defaults, guest policy, retention, labels and logging, all before any content arrives.
2. Clean up the source: remove leavers, expire stale guests and anonymous links, retire unowned integrations, and agree the archive list.
3. Pilot: migrate the IT and security teams' own spaces first. Compare effective permissions, label and retention behaviour, and check that the audit trail shows the migration identity's actions.
4. Waves: migrate by department or business unit, with a delta sync close to each wave's cutover so late changes are not lost. Freeze sharing changes in the source for spaces in the current wave.
5. Coexistence: during dual running, decide which platform is the system of record for each space and make the other read-only, so sensitive files are not edited and re-shared in two places.
6. Rollback: keep source spaces intact and read-only, not deleted, until the wave has been stable for an agreed period. Rollback is re-enabling write access on the source and pausing sync, which should be rehearsed during the pilot.
7. Cutover: revoke the source integrations and the migration identity's write access to the target, then disable source logins except for a named archive role.

Decommissioning the old suite

NIST CSF 2.0 outcome GV.SC-10 expects supply chain plans to cover activities after a partnership or service ends, which for a SaaS suite means data return and deletion.

• Watch residual activity: alert on any login, API call or sync to the old suite after cutover; it reveals forgotten integrations and users.
• Revoke everything: OAuth grants, API tokens, bots, webhooks, SSO federation and delegated partner access.
• Export for retention: content and audit logs that must be retained but were not migrated, stored encrypted with access controlled.
• Delete and confirm: request deletion of the tenant and written confirmation from the provider. Destroy local exports and migration working copies when no longer needed, following NIST SP 800-88 Rev. 2 for any media you control.
• Remove DNS and verification records: domain verification and mail records pointing at the old suite should be removed so the domain cannot be claimed elsewhere.

Decision guidance

Small organisations: a short, well-rehearsed cutover avoids months of dual running that nobody monitors; spend the effort on sharing clean-up and admin MFA. Large organisations: run waves by business unit with a migration control board, a published cutover calendar and a named owner for every integration and shared drive.

Detection and measurement

Ship audit logs from both suites to the SIEM for the whole project. Alert on the migration identity being used from unexpected locations or outside wave windows, on bulk downloads or exports by users during the freeze, on new external sharing or guest invitations in migrated spaces, on new OAuth grants with broad scopes (ATT&CK T1528 Steal Application Access Token) and on new credentials added to applications (T1098.001 Additional Cloud Credentials).

• Permission parity: percentage of sampled workspaces where effective access in the target matches the approved design.
• External exposure: count of anonymous links and guest accounts before and after migration (target: lower after).
• Integration reduction: integrations re-approved on the target versus those found in the source, and percentage with a named owner.
• Hold integrity: custodians and spaces under hold verified as preserved after each wave (target 100 percent).
• Migration identity lifetime: days the migration credentials existed and whether they were removed on the scheduled date.
• Residual source activity: logins and API calls to the old suite after cutover (target zero).

Common failure patterns

• Oversharing carried over: anonymous and organisation-wide links are reproduced faithfully, or worse, widened because the target has no equivalent restriction.
• Private becomes public: restricted channels are migrated into spaces with broader membership because the model did not map.
• The migration account that never dies: application credentials with tenant-wide read access remain valid for months after the project ends.
• Integrations copied blindly: every bot and app is recreated with the same broad scopes, including ones nobody owns.
• Holds broken in transit: content under legal hold is deleted from the source or lands on the target without a hold.
• Old suite left running: a "read-only" source still accepts logins, API tokens and sync, unmonitored and outside licence-funded support.

Framework mapping

Practitioner checklist

• Inventory users, groups, spaces, files, links, guests, integrations, holds and admin roles, each with an owner and a decision.
• Configure the target first: SSO, SCIM, admin MFA, restrictive sharing defaults, guest policy, retention, labels and logging.
• Clean up leavers, stale guests, anonymous links and unowned integrations in the source before migrating.
• Scope the migration identity per wave, store its credentials in a secrets manager and schedule its removal.
• Put data handling and deletion terms in any migration vendor contract.
• Confirm every legal hold and retention policy is preserved through each wave.
• Pilot with IT and security spaces and compare effective permissions in source and target.
• Keep source spaces read-only, not deleted, until each wave is stable, and rehearse rollback.
• Re-register only owned, needed integrations with minimum scopes; revoke source tokens at cutover.
• Decommission: monitor residual activity, export required records, revoke all access and obtain deletion confirmation.

Standards and references

• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: SP 800-88 Rev. 2, Guidelines for Media Sanitization
• IETF: RFC 7644, System for Cross-domain Identity Management: Protocol
• NCSC: Lightweight approach to cloud security
• MITRE ATT&CK: T1213.005 Messaging Applications
• MITRE ATT&CK: T1528 Steal Application Access Token

Related NHI Mgmt Group resources: Securing the collaboration suite itself · Collaboration suite health check · Tenant-to-Tenant Migration Security · Slack Legacy Bots and Classic Apps Retirement · SSPM rollout playbook