CloudM's Recommended Migration Strategy

Overview

CloudM Migrate offers extensive flexibility when migrating to Google Workspace and Microsoft 365. To ensure a smooth, efficient, and successful migration project, thorough planning and a comprehensive understanding of CloudM Migrate's capabilities are essential. This guide outlines our recommended migration strategy, including crucial preparation steps and a phased migration timeline.

Key Preparation Steps

Successful migrations begin with meticulous preparation. Consider the following fundamental steps:

• Thorough Testing: Always conduct pre-migration testing using a representative sample of your data and user accounts. This allows you to familiarize yourself with the available options in CloudM Migrate and confirm the optimal configuration for your specific environment before the main migration event.
• Comprehensive Data Discovery: Perform a detailed data discovery exercise on your source platform. This crucial step helps you understand the total volume of data to be migrated, the distribution of data across users or item types (e.g., mail, files, calendars), and identify any potentially problematic data.
  • Environment Scan is designed to help you effectively plan and prepare for your migration by analysing your source file and mail environment.
• Review Essential Documentation: Before initiating any migration, carefully read and understand the following:
  • All prerequisites for your specific source and destination platforms.
  • Supported platforms entities and data types.
  • Supported features.
  • Platform-specific batch configuration options.
  • Important watchpoints and considerations relevant to your migration scenario.

Understanding Migration History

CloudM Migrate maintains a Migration History database to track items that have been successfully migrated. This feature is fundamental to the efficiency of delta migrations, preventing the re-migration of unchanged data.

How Migration History Affects Different Data Types

• Email, Calendar, and Contacts:
  • Successfully migrated items are recorded in the history and skipped in subsequent runs (deltas) to accelerate the process.
  • Crucial Point: These items are migrated "as-is" at the point of initial migration. CloudM Migrate will not update the existing item at the destination if attributes (like read/unread state or folder location) change at the source after the initial pass. Deltas focus exclusively on bringing over new items.
• File Data:
  • Files previously migrated are typically skipped unless they have been modified at the source since their last migration.
  • Default Behavior (Overwrite): If a source file is updated after migration, re-migrating it will, by default, overwrite the previous version at the destination. This can be disabled in the configuration if versioning or skipping is preferred.
  • Source of Truth Principle: The source platform remains the definitive "source of truth." If changes are made to both the source and the migrated destination version, the updated source file will take precedence upon re-migration.

Key Migration Principles

CloudM Migrate operates based on fundamental principles to ensure data integrity and minimize user impact:

• Non-Intrusive and Non-Destructive: CloudM Migrate performs a copy operation. It does not alter, delete, or move data on the source platform.
• Business Continuity: End-users can typically continue working on the source platform during initial migration phases without interruption.
• Prevention of Data Duplication: Designed to prevent duplicate items even if a process or user batch is re-run, provided the Migration History database is maintained.

Recommended Migration Timeline

The following timeline offers a general guideline for structuring a migration project. Actual timelines vary based on data volume, user count, environment complexity, and bandwidth.

Stage 0: Strategic Planning and Preparation (Well Before Go-Live)

• Stakeholder Engagement: Engage Change Management to manage user expectations and adoption.
• Environment Assessment: Analyze tenant settings, integrated third-party apps, and network infrastructure.
• Communication Plan: Outline when and how users will be informed of the impact and timelines.
• Define Scope: Finalize exactly which data types (Mail, Files, etc.) and configuration settings will be used.

Stage 1: Initial Communications & Critical Testing (1-3 Months Before Go-Live)

• Company-Wide Announcement: Formally announce the migration, anticipated benefits, and high-level timeline.
• Pre-Migration Testing: Conduct iterative testing with a representative sample of data to finalize configuration and filtering logic.

Stage 2: Pilot Program & Bulk Migration (1-2 Months Before Go-Live)

• Establish a Pilot User Group: Recruit a diverse group of users to provide feedback and act as internal advocates.

Migration Phase 1: Bulk/Historical Data Migration (Primary Migration Pass)

This is the large-scale migration pass of the majority of historical data.

• Recommended Data Types: Focus primarily on Email and File data.
• Data Typically Deferred: Calendar, Tasks, and Contacts are often best saved for the final delta due to their dynamic nature.
• "Working Window" Exclusion: We highly recommend excluding very recent items (e.g., last 7-30 days) from the bulk pass. This volatile data is best captured fresh during the final delta.

Stage 3: Final Preparations & User Readiness (1 Week Before Go-Live)

• DNS Change Preparation: Plan MX, SPF, DKIM, and Autodiscover changes. Lower TTL values in advance to speed up propagation.
• Final User Communication: Send exact Go-Live times, instructions for accessing the new platform, and internal support links.

Stage 4: Go-Live Day (Cutover Execution)

• Execute DNS Cutover: Update MX records and other planned DNS entries.
• Domain Switch: If applicable, perform domain release and add procedures (refer to Knowledge Base for specific platform guidance).
• Initiate Final Delta Migration: Begin Phase 2 immediately once DNS changes are initiated.

Migration Phase 2: Delta/Go-Live Migration (Immediately Post-Cutover)

• Purpose: Capture and migrate any new or changed data that occurred since the Bulk pass (Phase 1).
• Data Migrated: New emails received before MX propagation, full Calendar/Contacts sync, updated files, and items previously excluded by the "Working Window."

Stage 5: Post-Migration Activities & Support

• System Monitoring: Monitor for performance issues and review migration reports.
• Validation and Sign-off: Perform business-unit checks to ensure data completeness.
• Decommissioning: Plan the eventual decommissioning of the source system. Do not rush this step.

Migration Phase 3: Backfill Migration (Optional - Post Go-Live)

Backfill migrations are an optional, asynchronous strategy used to move a subset of legacy data after users have already begun working in the destination platform.

• Purpose: To reduce the time pressure of the Go-Live window by deferring the migration of very old or low-priority historical data until after the cutover is successful.
• Sample Scenario: This is often used when a project requires users to go live with only the last 1-2 years of data, with the remaining 10+ years of history "backfilled" into their accounts over the following weeks.
• Consideration: Ensure users are aware that older data will appear gradually in their accounts post-migration.

Stage 6: Review & Lessons Learned

• Project Review: Discuss project successes and improvements with stakeholders to document lessons for future migration events.