CloudM Continuity is a fully managed platform hosted on Google Cloud Platform (GCP). This article explains how the platform is structured, where it runs, how your data flows between Microsoft 365 and Google Workspace, and how your credentials and data are secured.
Platform overview
CloudM Continuity is built as a set of specialised services that work together to sync your M365 mail and calendar data to Google Workspace, keep it up to date, and reverse the flow during recovery. All services run on Google Cloud infrastructure.
| Component | What it does |
|---|---|
| Dashboard and API | The web interface you use to manage tenants, configure sync policies, monitor sync status, view audit logs, and trigger recovery operations. |
| Orchestration service | Manages the sync lifecycle: queries M365 for users matching your policy rules, checks whether corresponding Google Workspace accounts exist, provisions new accounts when needed, and schedules sync jobs based on your tier (weekly, daily, or hourly). |
| Data sync engine | Performs all data movement. Initial syncs run on dedicated compute infrastructure (GKE) to handle bulk migration. Ongoing delta syncs run on auto-scaling infrastructure (Cloud Run) that scales down between sync cycles for cost efficiency. |
| Credential manager | Handles credential and token management for both Microsoft 365 and Google Workspace. Tokens are issued on demand and refreshed automatically, and long-lived credentials are stored in Google Cloud Secret Manager with access audit logging. |
Where the platform runs
The hosted service runs in Google Cloud's us-central1 region, in the United States. Everything the platform stores, including tenant configuration, sync state, audit logs and your connection credentials, is held in that region.
Your mailbox and calendar data itself stays in your own Microsoft 365 and Google Workspace tenants. The platform reads from one and writes to the other, and does not keep a copy. See What CloudM Continuity stores below.
If you have a data residency requirement that this does not meet, Continuity can also be deployed into a Google Cloud project that you own, in a region you choose. See Deployment models below.
How data flows
There are two primary data flows: the normal sync (M365 to Google) that runs continuously, and the recovery sync (Google to M365) that is triggered after an outage.
Normal sync flow (M365 to Google Workspace)
- The scheduler triggers a sync cycle based on your policy's frequency (weekly, daily, or hourly)
- The orchestration service queries your M365 tenant via the Microsoft Graph API to identify users matching your policy rules
- For any new users, the orchestration service checks Google Workspace and provisions accounts if needed via the Google Admin SDK
- Sync jobs are dispatched to the data sync engine
- The data sync engine reads mail and calendar data from M365 via the Microsoft Graph API and writes it to Google Workspace via the Gmail API and the Google Calendar API
- Sync status and audit events are recorded and made available in the dashboard
No data staging. Your data flows directly from M365 to Google Workspace during sync, and CloudM Continuity does not keep a copy of it. During ongoing delta syncs, items stream straight from the source to the destination. During the initial sync, content may be briefly buffered in encrypted form on the sync infrastructure while it is processed, and each item is deleted as soon as it has been written to Google Workspace. Nothing is retained once sync completes. Only sync state metadata, such as which items have been synced and delta tokens for change tracking, is stored by the platform.
Failover (no data flow required)
During an M365 outage, there is no data flow to initiate. Because your Google Workspace environment has been kept up to date by ongoing sync, your users simply access their Google Workspace accounts and continue working. The data is already there.
Recovery sync flow (Google Workspace to M365)
- After M365 is restored, an admin triggers a recovery from the Recovery page
- The data sync engine identifies all mail sent and received in Google Workspace during the outage window
- That data is migrated back to M365
- When the recovery finishes, the administrator reviews the outcome and finishes the recovery
Recovery Sync covers mail only. Calendar data synced to Google Calendar is not returned to Microsoft 365, and changes your users make in Google Calendar during an outage are not synced back.
API integrations
CloudM Continuity connects to your M365 and Google Workspace environments through their official APIs. The tables below show what is used and why.
Microsoft 365
| API | Used for |
|---|---|
| Microsoft Graph API | Reading mail messages, folders, and attachments. Reading calendars and events. Querying users that match policy rules. Detecting changes via delta queries for incremental sync. Writing mail back during recovery. |
Authentication uses an Azure AD app registration with application-level permissions (client credentials flow), so no individual user sign-in is required. The app accesses mailboxes on behalf of the organisation. Calendar sync additionally requires the Calendars.Read application permission. See Connecting Microsoft 365 for the full list of required permissions.
Google Workspace
| API | Used for |
|---|---|
| Gmail API | Importing mail messages into user mailboxes, managing labels (for folder and category mapping), updating message metadata (read status, stars). Reading mail during recovery sync. |
| Google Calendar API | Creating and updating calendars and events, and applying the sharing permissions translated from Microsoft 365. |
| Google Admin SDK (Directory API) | Checking whether Google Workspace user accounts exist and creating new accounts when provisioning is needed. |
Authentication uses a GCP service account with domain-wide delegation. This allows the service account to act on behalf of users in your Google Workspace domain without requiring individual consent. See Connecting Google Workspace for the setup process.
Security
Data in transit
All communication between CloudM Continuity and your M365 and Google Workspace environments uses TLS 1.2+ encryption. This includes:
- API calls to Microsoft Graph (
graph.microsoft.com) - API calls to Google APIs (
googleapis.com) - All traffic between internal platform services
- Browser connections to the CloudM Continuity dashboard
Credential storage
| Credential | How it is stored |
|---|---|
| M365 app credential | Your app registration authenticates with either a certificate or a client secret. Whichever you use is encrypted at rest in Google Cloud Secret Manager, and every access is audit-logged. |
| Google service account | No key file is stored, and none is needed. The platform requests short-lived tokens for the service account you delegated, using Google's own service account impersonation. There is no long-lived Google key held by CloudM. |
| Access tokens | Short-lived tokens held in memory for up to 55 minutes, within the standard 60-minute expiry window. Never written to persistent storage. |
Stored credentials are readable by one internal service, the token provider, which issues tokens to the rest of the platform and has no public endpoint. Each platform service runs under its own identity with access limited to the resources it needs.
Authentication
Access to the CloudM Continuity dashboard is secured with Firebase Authentication. All users must authenticate before accessing any tenant data. Role-based access control (Super Admin, Admin, Viewer) restricts what actions each user can perform. See Roles and Permissions for the full breakdown.
Tenant isolation
Each customer operates within an isolated tenant. Tenant data is logically separated at the database level, and all API requests are scoped to the authenticated user's tenant. There is no cross-tenant data access.
Infrastructure
| Area | Technology | Purpose |
|---|---|---|
| Hosting | Google Cloud Platform, us-central1
|
All platform services run on GCP infrastructure in the United States |
| Application services | Google Cloud Run | Auto-scaling serverless containers for the dashboard, orchestration, credential management, and delta syncs |
| Initial sync compute | Google Kubernetes Engine (GKE) | Dedicated compute for bulk historical data migration, which requires sustained processing |
| Scheduling | Google Cloud Scheduler + Cloud Tasks | Triggers sync cycles on the configured frequency and manages task queues for async operations |
| Messaging | Google Cloud Pub/Sub | Asynchronous communication between services, ensuring reliable job dispatch and event delivery |
| Relational data | Google Cloud SQL (PostgreSQL) | Tenant configuration, user records, policies, and licence data, on a private IP with no public access |
| Sync state | Google Cloud Datastore | Scalable NoSQL storage for sync metadata, delta tokens, and message tracking state |
| Audit and reporting data | Google BigQuery | Audit log entries and sync activity records, which is what the dashboard and audit log pages read |
| Secrets | Google Cloud Secret Manager | Encrypted storage for M365 and Google credentials with access audit logging |
What CloudM Continuity stores
It is important to understand the distinction between data that flows through the platform and data that is stored by the platform.
| Data | Stored? | Details |
|---|---|---|
| Mail and calendar content | No | Message bodies, attachments and calendar events flow through the platform during sync but are not stored at rest. Data is read from M365 and written directly to Google Workspace. |
| Sync metadata | Yes | Message IDs, delta tokens, folder mappings, and sync state are stored to enable incremental sync and change tracking. |
| Tenant configuration | Yes | Policies, connections, user records, invitations, and licence data. |
| Audit logs | Yes | All system and user actions are logged for compliance and troubleshooting. |
| Credentials | Yes | Your M365 app credential is stored encrypted in Secret Manager. No Google key file is stored. See Credential storage above. |
Credential rotation. M365 certificates and client secrets have expiry dates. You are responsible for rotating these before they expire to prevent sync interruptions. See Rotating Microsoft 365 Credentials and Rotating Google Workspace Credentials for instructions.
Deployment models
Continuity is available in two deployment models. Both run the same platform, the same version, and the same sync engine. What changes is whose Google Cloud project it runs in.
Hosted by CloudM
The default, and how most customers run Continuity. It is delivered as a fully managed SaaS platform. There is nothing to install, no infrastructure to manage, and no agents to deploy on your M365 or Google Workspace environments. All connectivity is via standard cloud APIs over HTTPS.
| Aspect | Detail |
|---|---|
| Hosting | Fully hosted and managed by CloudM on Google Cloud Platform, in us-central1
|
| Multi-tenancy | Shared infrastructure with logical tenant isolation at the data layer |
| On-premises requirements | None. Only outbound HTTPS access to graph.microsoft.com and googleapis.com is required. |
| Updates | Platform updates are deployed by CloudM with no action required from customers |
Private cloud
The same platform deployed into a Google Cloud project that your organisation owns. You choose the region, the project is billed to you, and everything the platform stores stays inside your own organisation. CloudM deploys the platform and keeps it up to date.
This model is arranged with CloudM rather than set up self-service. Talk to CloudM or your partner about scoping a private cloud deployment.
| Aspect | Detail |
|---|---|
| Hosting | Your own Google Cloud project, in the region you choose |
| Multi-tenancy | Single tenant. The infrastructure is yours and is not shared with other customers. |
| Stored data | Tenant configuration, sync state, audit logs and your connection credentials are all held in your project |
| Network | Platform services run in a private network with no public IP addresses, apart from the sign-in page. Outbound traffic to Microsoft and Google leaves through a managed gateway. |
| Updates | Deployed by CloudM, using the same tested release that runs on the hosted service |
A small number of CloudM services remain centrally hosted in both models, because they are shared by every deployment:
- Licensing. The platform checks your licence against the CloudM licensing service. In a private cloud deployment this runs over a private Google Cloud connection rather than the public internet.
- Notification email. Invitations and alerts are sent by the CloudM messaging service.
- Software. Container images and the dashboard bundle are published by CloudM and pulled by your deployment.
Your mail and calendar data is never part of that traffic. It moves directly between your Microsoft 365 and Google Workspace tenants, in both models.