Skip to main content
  1. CloudM
  2. Migrate 4
  3. Migration Planning

CloudM's Recommended Migration Strategy

Updated

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. It provides the detailed insights you need.
  • Review Essential Documentation: Before initiating any migration, carefully read and understand the following, available within the CloudM Knowledge Base:

 

Understanding Migration History for Efficient Delta Migrations

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:
    • When an email message, calendar event, or contact is migrated, it is recorded in the Migration History.
    • In subsequent migration runs (deltas), CloudM Migrate will identify these already-migrated items and skip them to accelerate the process.
    • Crucial Point: These items are migrated "as-is" at the point of their initial migration (reflecting attributes like read/unread state, folder/label, and deleted state assignment at that moment). If these attributes change on the source platform after an item has been migrated, CloudM Migrate will not update the existing item at the destination during a subsequent delta run. Delta migrations for these item types focus exclusively on bringing over new items not previously migrated.
  • File Data:
    • File migrations also utilize the Migration History. Files previously migrated are typically skipped in subsequent runs unless they have been modified at the source since their last migration.
    • Default Behavior (Overwrite Updated Files): If a file at the source is updated/modified after its initial migration, re-migrating it will, by default, overwrite the version previously migrated to the destination. This "overwrite updated files" option is enabled by default within CloudM Migrate's configuration settings but can be disabled if your project requires a different approach (e.g., versioning if supported by the destination, or skipping updated/modified files).
    • Source of Truth Principle: Throughout a migration project, the source platform remains the definitive "source of truth." If a file is updated on the source platform, and users have also made changes to the already-migrated version of that file in the destination, the updated source file will take precedence upon re-migration (assuming the default overwrite option is enabled).

 

Key Migration Principles

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

  • Non-Intrusive and Non-Destructive Operation:
  • CloudM Migrate performs a copy operation, reading data from the source platform and writing it to the destination platform.
  • It does not alter, delete, or move data on the source platform. Your source data remains intact and accessible.
  • End-users can typically continue their normal work on the source platform during the initial migration phases without interruption. Whether they are aware of the background migration activity is determined by your internal communication plan.
  • Prevention of Data Duplication: CloudM Migrate is designed to prevent the creation of duplicate items if a migration process or a specific batch of users/items is re-run. The Migration History (detailed above) is key to this, ensuring items are processed appropriately based on their previous migration status.

 

Recommended Migration Timeline and Phased Approach

The following timeline offers a general guideline for structuring a migration project with CloudM Migrate. Please note that actual timelines can vary significantly based on factors such as the total volume of data, the number of users, the complexity of the source environment, network bandwidth, and specific project requirements. The example timeframes provided are illustrative and generally apply to smaller, less-complex migration scenarios.

 

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

  • Stakeholder Engagement & Change Management:
    For larger organizations, engage or form a dedicated Change Management team. This team will be responsible for managing user expectations, developing training materials, and driving user adoption of the new platform.
  • Comprehensive Environment Assessment:
    Thoroughly analyze source tenant settings, administrative configurations, and network infrastructure.
    • Identify and document the usage of any third-party applications integrated with the source platform, and plan for their migration or replacement.
    • Conduct detailed data discovery (as mentioned in the Overview section).
  • Develop a Communication Plan: 
    Outline a clear strategy for how and when users will be informed about the migration, its impact, timelines, and any actions required from them.
  • Define Migration Scope and Configuration Strategy: 
    Based on testing results and the environment assessment, finalize:
    • What specific data will be migrated (e.g., mail, specific folders, archives, files, calendars, contacts, tasks, chats).
    • The precise CloudM Migrate configuration settings to be used (e.g., date range filters, item type selections, advanced options, user batching strategy).

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

  • Company-Wide Announcement & Information Sharing: 
    Formally announce the upcoming migration project to all users via appropriate internal communication channels (e.g., email, intranet, company meetings). Clearly communicate what data is being migrated, the reasons for the migration, the anticipated benefits of the new platform, and a high-level project timeline.
  • Pre-Migration Testing (Iterative and Critical):
    Conduct thorough testing of CloudM Migrate with a representative sample of user accounts and data types. This should include different scenarios and data complexities present in your environment.
    • Use these test results to refine and finalize your migration configuration options, including decisions on item type inclusions/exclusions, date range filters, and any specific filtering logic.
    • Document test outcomes and any adjustments made to the migration plan.

Project Stage 2: Pilot Program & Bulk Historical Data Migration (Approx. 1-2 Months Before Go-Live)

  • Establish a Pilot User Group:
    Recruit a diverse group of users (e.g., from different departments, with varying technical comfort levels) to participate in a pilot migration. Pilot users provide invaluable feedback on the process, help identify unforeseen issues, can act as internal advocates for the new system, and may assist with local support and change management within their teams.

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


This is the initial, large-scale migration pass where the majority of historical data is migrated to the destination platform.

  • Recommended Data Types for this Phase: Primarily focus on migrating email and file data (including personal drives and shared drives/sites as applicable).
  • Data Not Typically Migrated in this Bulk Phase (Consider for Delta): Calendar/Tasks, Chats, and Contacts: Due to their dynamic and frequently changing nature (e.g., new appointments, updated contacts, ongoing chat threads), it's often more efficient and accurate to migrate the bulk of this data during the final delta/go-live phase. However, CloudM Migrate supports migrating these item types in the bulk phase if your specific strategy requires it.
  • "Working Window" Exclusion for Initial Pass (Highly Recommended for Email, Contacts, Calendars, Chats):
  • For the initial bulk migration pass of item types that change frequently (like email, contacts, calendars, chats), consider configuring CloudM Migrate to exclude very recent items (e.g., data created or modified in the last 7-30 days).
  • This recent, more volatile data is best captured fresh during the final delta migration, reducing the likelihood of migrating items that will immediately change. This "date from" or "date to" filtering is configurable within CloudM Migrate.

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

  • DNS Change Preparation & Validation:
    • Meticulously plan and prepare for all necessary DNS record changes (e.g., MX records for mail routing, Autodiscover, SPF, DKIM, CNAMEs).
    • Consult your destination platform's official documentation for required DNS records and recommended TTL (Time To Live) values. Lower TTLs on relevant records in advance of the cutover can speed up propagation.
    • Verify access to your DNS hosting provider's control panel and confirm you have the necessary permissions.
  • Final User Communication & Go-Live Schedule:
    • Send out detailed communications to all impacted users regarding:
    • The exact Go-Live date and time.
    • Any brief service outage windows (if applicable).
    • Instructions on how to access the new platform (e.g., login URLs, new credentials if any, client configuration).
    • Information on where to find internal support and training materials.

Stage 4: Go-Live Day (Cutover Execution)

  • Execute DNS Cutover:
    • At the scheduled time, update your MX records to point to the new email system.
    • Implement any other pre-planned DNS changes such as SPF, DKIM, etc.
  • Domain Switch (If Applicable): If your migration project involves moving your primary domain to the new tenant (e.g., in a tenant-to-tenant migration), perform the domain release and add procedures according to the destination platform's specific guidance. (Note: Refer to relevant CloudM Migrate Knowledge Base articles or platform-specific documentation for detailed steps on domain switch procedures, as these can be complex).
  • Initiate Final Delta Migration (Phase 2 - see below): Once DNS changes are initiated (and domain switch is complete, if applicable), begin the final delta migration pass.

Project Stage 5: 

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

  • Purpose: To capture and migrate any new or changed data that has occurred since the last bulk historical data migration pass (Phase 1) and up to the point of cutover. This ensures data completeness.
  • Data Migrated in this Phase:
    • All remaining data, which typically includes:
    • New emails received by the source system since the last pass and before MX records fully propagate.
    • The full migration of Calendar/Tasks, Chats, and Contacts (if deferred from the bulk phase, or any new/changed items if they were included in the bulk pass, subject to Migration History rules for updates).
    • Files created or modified at the source since the last pass (these will, by default, overwrite existing files at the destination if they were modified at the source).
    • Any items that fell within the "Working Window" and were intentionally excluded from the bulk pass.
  • Impact of Migration History:
    • As detailed in the "Understanding Migration History" section, email, calendar event, and contact items that were successfully migrated in the bulk phase (Phase 1) will be identified and skipped during this delta phase to prevent duplication (they will not be updated if their state changed at source after initial migration). Only new items of these types are added.
    • CloudM Migrate reports will provide comprehensive statistics for all items processed in this phase (both items newly migrated and those skipped due to Migration History).

Project Stage 6: Post-Migration Activities & Support

  • System Monitoring: Closely monitor the new platform and CloudM Migrate reports for any errors, warnings, or performance issues.
  • User Support & Troubleshooting: Provide dedicated support channels for end-users as they begin using the new system. Address any questions, access issues, or data discrepancies promptly.
  • Validation and Sign-off: Perform checks to ensure data has been migrated as expected. Consider a formal sign-off process with business units.
  • Source Platform Decommissioning (Planned Approach): Once the migration is verified, all data is accessible, and users are comfortable with the new platform, plan for the eventual decommissioning of the source systems and services. Do not rush this step.
  • Project Review & Lessons Learned: Conduct a post-migration review meeting with the project team and key stakeholders to discuss what went well, what could be improved, and document lessons learned for future migration projects.
Was this article helpful?
0 out of 0 found this helpful