CloudM Continuity is a fully managed platform hosted on Google Cloud Platform (GCP). This article explains how the platform is structured, 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 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 to zero between sync cycles for cost efficiency. |
| Credential manager | Handles OAuth token management for both Microsoft 365 and Google Workspace. Tokens are refreshed automatically, and credentials are stored in Google Cloud Secret Manager with audit logging. |
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 → 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 data from M365 via the Microsoft Graph API and writes it to Google Workspace via the Gmail API
- Sync status and audit events are recorded and made available in the dashboard
No data staging
Mail data flows directly from M365 to Google Workspace during sync. CloudM Continuity does not store a copy of your email data at rest. The platform reads from the source, transforms the data for the destination format, and writes it directly. Only sync state metadata (such as which messages 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 → M365)
- After M365 is restored, an admin triggers a recovery from the dashboard
- The data sync engine identifies all mail sent and received in Google Workspace during the outage window
- That data is migrated back to M365 via the Microsoft Graph API
- Once recovery completes, normal M365 → Google sync resumes automatically
API integrations
CloudM Continuity connects to your M365 and Google Workspace environments through their official APIs. The table below shows what is used and why.
Microsoft 365
| API | Used for |
|---|---|
| Microsoft Graph API | Reading mail messages, folders, and attachments. 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). This means no individual user sign-in is required — the app accesses mailboxes on behalf of the organisation. See Connecting Microsoft 365 for the 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 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 email with domain-wide delegation and token-based auth via the CloudM token provider. This allows the service account to act on behalf of users in your Google Workspace domain without requiring individual consent or a JSON key file. 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 PFX Certificate | Encrypted at rest in Google Cloud Secret Manager. Access is restricted to the credential manager service and all access is audit-logged. |
| Google Service Account Email | Stored in the platform configuration. Access tokens are generated via the CloudM token provider using token-based authentication (no JSON key file required). Encrypted at rest in Google Cloud Secret Manager with the same access controls. |
| OAuth access tokens | Short-lived tokens cached in memory for up to 55 minutes (within the standard 60-minute expiry window). Never written to persistent storage. |
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 | All platform services run on GCP infrastructure |
| 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, audit logs, and licence data |
| Sync state | Google Cloud Datastore | Scalable NoSQL storage for sync metadata, delta tokens, and message tracking state |
| 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 |
|---|---|---|
| Email content | No | Message bodies and attachments 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 | M365 PFX certificates and Google service account credentials are stored encrypted in Secret Manager. |
Credential rotation
M365 certificates and Google service account credentials 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 model
CloudM Continuity 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 |
| 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 |