Collaboration Platform Migration

Collaboration platform migration transfers email, files, calendars, contacts, and messaging data from one platform to another while maintaining user productivity and data integrity. The migration encompasses three primary workloads: mail migration (mailboxes, archives, rules), file migration (documents, folder structures, sharing permissions), and messaging migration (chat history, channels, integrations). Each workload presents distinct technical challenges, and most migrations run all three in parallel with coordinated cutover windows.

The migration process divides into five phases: assessment, preparation, pilot migration, production migration, and decommissioning. Assessment establishes the scope and identifies data requiring special handling. Preparation configures the target platform and establishes coexistence infrastructure. Pilot migration validates procedures with a representative user group. Production migration moves the organisation in waves. Decommissioning removes source platform access and licensing after a verification period.

Prerequisites

Before beginning the migration, verify the following requirements are satisfied:

Verify source platform data volumes to estimate migration duration:

# For Microsoft 365 source - export mailbox statistics
Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics |
  Select-Object DisplayName, TotalItemSize, ItemCount |
  Export-Csv mailbox-inventory.csv

# For Google Workspace source - use Admin SDK
gam print users fields name,email,suspended |
  gam csv - gam user ~email print filecount

Calculate expected migration duration using these baseline rates:

Procedure

Phase 1: Assessment and inventory

1. Export the complete user inventory from the source platform, capturing email addresses, display names, department, and manager relationships. This inventory serves as the canonical reference for migration tracking.

   # Microsoft 365 source
   Get-MsolUser -All | Select-Object UserPrincipalName, DisplayName,
     Department, UsageLocation, IsLicensed |
     Export-Csv user-inventory.csv -NoTypeInformation

   # Google Workspace source
   gam print users fields primaryEmail,name,orgUnitPath,suspended,
     isAdmin,creationTime > user-inventory.csv

2. Generate mailbox size reports to identify large mailboxes requiring special handling. Flag any mailbox exceeding 50 GB for extended migration windows.

   Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics |
     Where-Object {$_.TotalItemSize -gt 50GB} |
     Select-Object DisplayName, TotalItemSize, ItemCount

3. Inventory shared mailboxes, distribution lists, and mail-enabled groups. Document ownership and membership for recreation on the target platform.

   # Shared mailboxes
   Get-Mailbox -RecipientTypeDetails SharedMailbox |
     Select-Object DisplayName, PrimarySmtpAddress,
     @{N='Size';E={(Get-MailboxStatistics $_).TotalItemSize}}

   # Distribution lists
   Get-DistributionGroup | Select-Object DisplayName,
     PrimarySmtpAddress, ManagedBy, MemberCount

4. Map file storage structure, identifying shared drives, team sites, and individual storage quotas. Record permission inheritance patterns and external sharing configurations.

   # Google Workspace shared drives
   gam print teamdrives fields id,name,createdTime,
     organizerCount,memberCount > shared-drives.csv

5. Document third-party integrations connected to the source platform. For each integration, record the application name, authentication method, data accessed, and business owner.

   # Microsoft 365 OAuth applications
   Get-MsolServicePrincipal | Where-Object {$_.AppPrincipalId -ne $null} |
     Select-Object DisplayName, AppPrincipalId, AccountEnabled

6. Identify mail flow rules, transport rules, and email security configurations requiring recreation. Export rule configurations for reference during target platform setup.

   Get-TransportRule | Select-Object Name, State, Priority,
     Conditions, Actions | Export-Csv transport-rules.csv

Phase 2: Target platform preparation

1. Configure the target tenant with organisational branding, security defaults, and administrative access. Establish the administrative account structure before user provisioning.

   For Microsoft 365 targets, configure the following baseline settings:

   # Enable modern authentication
   Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

   # Configure default sharing policy
   Set-SharingPolicy -Identity "Default Sharing Policy" `
     -Domains "Anonymous:CalendarSharingFreeBusySimple"

2. Verify domain ownership on the target platform by adding the required DNS TXT records. Domain verification must complete before mail flow configuration.

   # Example DNS TXT record for Microsoft 365
   Type: TXT
   Host: @
   Value: MS=ms12345678
   TTL: 3600

3. Configure identity synchronisation or federation between source and target platforms for the coexistence period. Users must authenticate to both platforms during migration.

   +------------------+     +------------------+     +------------------+
   |                  |     |                  |     |                  |
   |  Source IdP      +---->+  Federation      +---->+  Target Platform |
   |  (existing)      |     |  Trust           |     |  (new)           |
   |                  |     |                  |     |                  |
   +------------------+     +------------------+     +------------------+

4. Create the target organisational unit structure mirroring source platform hierarchy. Consistent structure simplifies permission migration and policy application.

5. Provision user accounts on the target platform in a disabled state. Account creation must precede data migration to establish target mailboxes and storage locations.

   # Bulk user creation from inventory
   Import-Csv user-inventory.csv | ForEach-Object {
     New-MsolUser -UserPrincipalName $_.UserPrincipalName `
       -DisplayName $_.DisplayName `
       -Department $_.Department `
       -UsageLocation $_.UsageLocation `
       -BlockCredential $true
   }

6. Recreate distribution lists and shared mailboxes on the target platform. Preserve the same email addresses as aliases to maintain mail flow during coexistence.

7. Configure mail flow for the coexistence period. The source platform remains authoritative for MX records while the target platform receives forwarded mail for migrated users.

   +----------------+     MX Record      +----------------+
   |                |<------------------+|                |
   |  Source        |                    |  Internet      |
   |  Platform      |                    |  Mail          |
   |                +----+               |                |
   +-------+--------+    |               +----------------+
           |             |
           | Forward     | Direct (post-cutover)
           v             v
   +-------+--------+----+
   |                     |
   |  Target Platform    |
   |  (migrated users)   |
   |                     |
   +---------------------+

Phase 3: Pilot migration

1. Select 10-20 pilot users representing diverse roles, departments, and data volumes. Include at least one user with a mailbox exceeding 25 GB, one user with extensive file sharing, and one user from each major department.

2. Communicate pilot timeline and expectations to selected users 5 business days before migration. Provide the support contact and set expectations for temporary disruption.

3. Execute mail migration for pilot users during off-hours. Monitor migration throughput and error rates throughout the process.

   # Example using BitTitan MigrationWiz
   $mailboxes = Import-Csv pilot-users.csv
   foreach ($mbx in $mailboxes) {
     Add-MW_Mailbox -Ticket $mwTicket `
       -ConnectorId $connectorId `
       -ImportEmailAddress $mbx.TargetEmail `
       -ExportEmailAddress $mbx.SourceEmail
   }
   Start-MW_MailboxMigration -Ticket $mwTicket -ConnectorId $connectorId

4. Execute file migration for pilot users, preserving folder structure and sharing permissions. Verify permission mapping completed correctly by testing access from shared recipients.

5. Verify calendar items migrated with correct time zones and recurrence patterns. Check that meeting invitations from the source platform still function for migrated users.

6. Collect pilot user feedback through structured interviews. Document issues encountered, workarounds required, and suggestions for production migration.

7. Analyse pilot metrics against success criteria:

   Metric	Target	Action if missed
   Mail migration completeness	99.5% of items	Investigate failed items, adjust batch size
   File migration completeness	99% of files	Check permission errors, retry with elevated access
   User-reported issues	Fewer than 2 per user	Enhance documentation, adjust training
   Migration throughput	Within 20% of estimate	Adjust parallelism, check network capacity

8. Remediate pilot issues before production migration. Update procedures, communication templates, and support documentation based on pilot learnings.

Phase 4: Production migration

1. Segment users into migration waves of 50-100 users each. Group users by department or location to simplify support coordination. Schedule waves to complete within 48-72 hours each.

   +---------------------------------------------------------------------+
   |                    PRODUCTION MIGRATION TIMELINE                    |
   +---------------------------------------------------------------------+
   |                                                                     |
   |  Wave 1        Wave 2        Wave 3        Wave 4        Wave 5     |
   |  (IT + HR)     (Finance)     (Ops)         (Field)       (Exec)     |
   |                                                                     |
   |  Day 1-3       Day 4-6       Day 7-9       Day 10-12     Day 13-15  |
   |  50 users      75 users      100 users     80 users      25 users   |
   |                                                                     |
   +---------------------------------------------------------------------+
   |                                                                     |
   |  Delta sync                  Delta sync                 Final       |
   |  after each wave             continues                  cutover     |
   |                                                                     |
   +---------------------------------------------------------------------+

2. Send wave-specific communication 3 business days before each wave begins. Include the migration window, expected impact, and post-migration instructions.

3. Initiate mail migration for the current wave. Configure delta synchronisation to continue capturing new mail until final cutover.

   # Start migration with delta sync enabled
   Start-MW_MailboxMigration -Ticket $mwTicket `
     -ConnectorId $connectorId `
     -Type Full `
     -UpdateNextRunTime (Get-Date).AddHours(4)  # Delta sync every 4 hours

4. Execute file migration in parallel with mail migration. Large shared drives require dedicated migration slots running outside user migration windows.

   +------------------------+
   |  File Migration Queue  |
   +------------------------+
   |                        |
   |  User files: Parallel  |
   |  with mail migration   |
   |                        |
   |  Shared drives: Serial |
   |  during off-hours only |
   |                        |
   +------------------------+

5. Migrate calendar and contacts after mail migration completes. Free/busy lookup requires both source and target calendars to be synchronised during coexistence.

6. Enable target platform access for migrated users. Communicate login instructions and credential reset procedures.

   # Enable user accounts post-migration
   $migratedUsers = Import-Csv wave1-complete.csv
   foreach ($user in $migratedUsers) {
     Set-MsolUser -UserPrincipalName $user.UPN -BlockCredential $false
   }

7. Configure mail forwarding from source to target for migrated users. This ensures mail sent to source addresses reaches users on the target platform.

   # Source platform forwarding (Microsoft 365)
   Set-Mailbox -Identity user@source.org `
     -ForwardingSmtpAddress user@target.org `
     -DeliverToMailboxAndForward $false

8. Execute delta synchronisation for mail and files 24 hours before wave cutover. This minimises the final sync window and reduces data loss risk.

9. Perform final cutover synchronisation during the designated maintenance window. Disable source platform access immediately after final sync completes.

10. Verify wave completion against success criteria before proceeding to the next wave. Document any issues requiring remediation.

Phase 5: Cutover and decommissioning

1. Execute final delta synchronisation for all users 4 hours before DNS cutover. Monitor for completion before proceeding.

2. Update DNS records to point to the target platform. MX record changes propagate within TTL period, typically 1-4 hours.

   # Pre-cutover DNS
   MX 10 source-platform-mx.example.com.

   # Post-cutover DNS
   MX 10 target-platform-mx.example.com.

   # Autodiscover update
   CNAME autodiscover -> autodiscover.target.com.

3. Disable mail forwarding rules after DNS propagation completes. Verify mail flow by sending test messages from external addresses.

4. Reconfigure third-party integrations to connect to the target platform. Test each integration and verify data flow resumed correctly.

5. Disable source platform user access after 7-day verification period. Retain administrative access for 30 days to address data recovery requests.

   # Disable all non-admin source accounts
   Get-MsolUser -All | Where-Object {$_.IsAdmin -eq $false} |
     Set-MsolUser -BlockCredential $true

6. Export source platform audit logs before licence termination. Retain logs for compliance requirements, typically 7 years.

7. Terminate source platform licensing after 30-day retention period. Document licence termination date for compliance records.

8. Update documentation to reflect new platform configuration. Archive source platform documentation with dated notation.

Mail migration specifics

Mail migration transfers mailbox contents including messages, folders, rules, and signatures. The migration tool connects to both source and target platforms simultaneously, extracting items from source and injecting into target.

Message fidelity depends on format compatibility between platforms. Messages migrating between Microsoft 365 tenants preserve full fidelity including rich formatting, embedded images, and attachments. Messages migrating from Google Workspace to Microsoft 365 undergo format conversion that occasionally affects complex HTML formatting.

Calendar migration requires special attention to recurring meetings and shared calendars. Recurring meeting patterns must map to equivalent patterns on the target platform. The migration tool recalculates recurrence after migration; verify that meeting series end dates and exception dates transferred correctly.

+------------------+     +------------------+     +------------------+
|                  |     |                  |     |                  |
|  Source Mailbox  +---->+  Migration Tool  +---->+  Target Mailbox  |
|                  |     |                  |     |                  |
|  - Messages      |     |  - Extract       |     |  - Messages      |
|  - Folders       |     |  - Transform     |     |  - Folders       |
|  - Rules         |     |  - Load          |     |  - Rules         |
|  - Calendar      |     |  - Delta sync    |     |  - Calendar      |
|                  |     |                  |     |                  |
+------------------+     +------------------+     +------------------+

Public folder migration requires separate handling from mailbox migration. Export public folder hierarchy and permissions before migrating content. Public folders exceeding 25 GB should migrate to shared mailboxes or SharePoint team sites rather than target platform public folders.

File migration specifics

File migration transfers documents, folder structures, and sharing permissions. The migration preserves file metadata including created date, modified date, and author where target platform supports these attributes.

Permission mapping translates source sharing settings to target equivalents. Direct user permissions map straightforwardly when users exist on both platforms. Group-based permissions require groups to exist on the target before migration. External sharing permissions require policy configuration on the target to permit external sharing.

Large file handling varies by platform. Files exceeding 15 GB cannot migrate to SharePoint Online in a single operation. Split large files or use alternative storage for files exceeding platform limits.

Version history migration depends on tool capability and licensing. Most migration tools support version history but limit the number of versions transferred. Configure version limits before migration to avoid unexpected truncation.

  SOURCE FILE STORAGE                             TARGET FILE STORAGE

  +------------------------+                      +------------------------+
  | My Drive               |                      | OneDrive               |
  | +-- Documents          |--------------------->| +-- Documents          |
  | |   +-- File1.docx     |      Preserve        | |   +-- File1.docx     |
  | |   +-- File2.xlsx     |      metadata        | |   +-- File2.xlsx     |
  | +-- Projects           |--------------------->| +-- Projects           |
  |     +-- 2024           |        Map           |     +-- 2024           |
  |         +-- ...        |    permissions       |         +-- ...        |
  +------------------------+                      +------------------------+


  +------------------------+                      +------------------------+
  | Shared Drives          |                      | SharePoint Sites       |
  | +-- Finance            |--------------------->| +-- Finance            |
  | +-- Operations         |      Convert to      | +-- Operations         |
  | +-- HR                 |       document       | +-- HR                 |
  +------------------------+      libraries       +------------------------+

Coexistence configuration

The coexistence period spans from first user migration to final DNS cutover. During coexistence, both platforms operate simultaneously with mail routing, calendar free/busy lookup, and directory synchronisation maintaining user connectivity across platforms.

Mail routing during coexistence uses forwarding rules to deliver mail to migrated users on the target platform. The source platform remains the primary mail exchanger until final cutover, receiving all inbound mail and forwarding migrated users’ mail to target addresses.

Free/busy federation enables calendar lookup across platforms. Configure federation trust between source and target to display availability for meeting scheduling. Without federation, users cannot see availability of colleagues on the other platform.

+-----------------+     Federation     +-----------------+
|                 |<------------------>|                 |
|  Source         |     Free/busy      |  Target         |
|  Calendar       |     lookup         |  Calendar       |
|                 |                    |                 |
+-----------------+                    +-----------------+
        ^                                      ^
        |                                      |
        |  Unmigrated users                    |  Migrated users
        |  schedule meetings                   |  schedule meetings
        |                                      |
        +------------------+-------------------+
                           |
                           v
                  Meeting invitations
                  work across platforms

Address book synchronisation keeps contact information current on both platforms. Configure directory synchronisation to replicate user attributes bidirectionally. The Global Address List on each platform should display all organisation users regardless of migration status.

Verification

After completing each migration wave, execute the following verification procedures:

1. Confirm mailbox item counts match between source and target within 1% tolerance. Export statistics from both platforms and compare totals.

   # Target platform item count
   Get-Mailbox user@target.org | Get-MailboxStatistics |
     Select-Object ItemCount, TotalItemSize

2. Verify sent and received mail flow by sending test messages. Send from external address, from source platform, and from target platform. Confirm delivery to target mailbox.

3. Test calendar functionality by creating meetings with attendees on both platforms. Verify free/busy lookup functions correctly during coexistence.

4. Confirm file access by opening 5 randomly selected files per user. Verify file content displays correctly and sharing permissions allow expected access.

5. Validate shared drive permissions by testing access from multiple users with different permission levels. Verify view-only users cannot edit, editors can modify, and owners can share.

6. Test third-party integrations by executing representative workflows. Verify data flows correctly between integrated applications and the target platform.

Expected verification results:

Troubleshooting

Rollback procedures

If critical issues require returning to the source platform, execute rollback within 72 hours of wave cutover before users accumulate significant new data on the target.

1. Disable target platform access for affected users immediately. Prevent further data creation on target during rollback assessment.

   Set-MsolUser -UserPrincipalName user@target.org -BlockCredential $true

2. Remove mail forwarding rules from source platform. Mail will resume delivery to source mailboxes.

3. Re-enable source platform access for affected users. Communicate rollback status and revised timeline.

4. Export any new data created on target platform during the failed migration window. Manually migrate critical items to source.

5. Analyse failure cause before re-attempting migration. Document root cause and remediation in migration log.

See also

• Collaboration Platform Strategy
• Document Management
• Email and Calendar
• Collaboration Platforms
• [Identity Platform Migration