Getting Started › Overview
How CloudM Continuity Works
CloudM Continuity follows a three-phase process — Sync, Failover, and Recover — that together form the Resilience Loop. This page walks through each phase, explaining what happens technically and what your users experience.
The three phases
Once you create a sync policy and connect both platforms, CloudM Continuity begins synchronising your Microsoft 365 mail data to Google Workspace.
Initial sync: The first time a user is synced, the last 30 days of mail data is migrated from M365 to Google Workspace. This is a bulk operation that runs on dedicated infrastructure to handle large volumes of data efficiently.
Delta sync: After the initial sync completes, only new or changed items are synchronised on your chosen schedule. This keeps your Google Workspace environment up to date with minimal resource usage.
The sync preserves:
- Email messages and attachments
- Folder and label hierarchies
- Read/unread states
When Microsoft 365 experiences an outage, your users simply log into Google Workspace and continue working. Because the sync has been running continuously, the Google Workspace environment contains a recent copy of each user's mail.
There is no "failover button" to press — the Google Workspace environment is always ready. Users can:
- Read their synced email
- Send and receive new email
- Continue working without interruption
How recent the data is depends on your sync frequency tier. With the Premium (Hourly) tier, the maximum data gap is one hour.
In a future release, the Reverse Recovery Sync will run after Microsoft 365 is restored. This process will:
- Identify all emails sent and received in Google Workspace during the outage period
- Migrate those items back to Microsoft 365
- Resume normal M365 → Google Workspace sync automatically
This phase is not available at launch and is planned for a future release.
How sync policies work
You control which users are synced and how frequently through sync policies. A policy defines:
| Setting | Description |
|---|---|
| User query | A rule that selects which M365 users to include (e.g. by department, group, or specific user list) |
| Sync frequency | How often delta syncs run, set as a value and unit (e.g. 1 Hour, 6 Hours, 2 Days). The minimum interval is determined by your licence tier. |
| Data types | Which data to sync (mail at launch; Drive, Calendar, and Contacts planned for future releases) |
Only one policy can be active at a time. Each policy has its own sync frequency, set as a value and unit (e.g. 1 Hour, 6 Hours) within the limits of your licence tier.
The sync lifecycle for a user
Each user matched by a sync policy moves through three stages:
- Waiting — The user has been matched by a policy rule but sync has not yet started. The system is queued to begin.
- Initial Sync — The last 30 days of mail data is being migrated from M365 to Google Workspace.
- Synced — The initial migration is complete and incremental delta syncs are running on the configured schedule, keeping the Google Workspace mailbox up to date. Delta indicators show when the most recent sync ran.
The Continuity Dashboard shows aggregate counts at each pipeline stage, giving you an overview of how your sync is progressing. To see sync status on a per-user level, use the Sync Status page.
Monitoring your sync
The Continuity Dashboard provides visibility into your sync operations:
- Sync pipeline — See how many users are at each stage of the sync lifecycle
- Sync freshness — Check when the last successful sync ran and identify any users with stale data
- Success and failure metrics — Monitor total syncs, data volume, and any failures
- Audit logs — Review a full history of system and user actions
Automatic user provisioning
When a policy matches M365 users who don't yet have Google Workspace accounts, CloudM Continuity can automatically create those accounts. If user creation fails, the event is logged in your audit trail so you can investigate and resolve the issue.