CloudM Migrate Self Hosted Architecture & Security

This article explains how a self-hosted CloudM Migrate deployment is put together and where your data goes during a migration: what crosses your network boundary, what is held while an item is in flight, what is kept afterwards, and who can reach any of it. It is written for security reviewers, compliance officers and infrastructure architects, and for the partner engineers who answer their questions.

Summary

A migration is a temporary, high-volume movement of an organisation's most sensitive data. The security question is not whether the tool is encrypted. It is whose infrastructure the data crosses, what is kept, and for how long.

A self-hosted CloudM Migrate deployment keeps migration content inside infrastructure you control. Content is held only transiently, and encrypted while an item is in flight. What persists afterwards is the metadata needed to run delta passes and produce reports. CloudM itself receives licensing metadata and nothing else. That combination is what allows the product to fit regimes where processing location and personnel access are the deciding factors, rather than encryption alone.

• Data path. Migration content moves between your servers and the source and destination platforms. It does not traverse CloudM infrastructure.
• In transit. HTTPS to platform APIs, TLS 1.2 or higher as negotiated. No inbound connections from the internet.
• During processing. One item at a time. Small items in memory, larger items in temporary files encrypted with AES-256 and deleted after transfer.
• What persists. Project configuration, user lists, run results and reports, plus item identifiers and content hashes for delta passes. Not content.
• What CloudM receives. Licensing metadata from the servers, and console usage analytics from the administrator's browser. No message bodies, file contents, file names or folder structures.
• Deployment control. The servers, the network and their lifecycle belong to you, so deletion is yours to perform and yours to verify.

Why migration security is a different problem

Steady-state security controls are designed around a stable picture: known systems, known volumes, standing access that changes slowly. A migration breaks all three at once. It moves an organisation's entire mail, file and calendar estate in a compressed window, often over a single cutover weekend, using credentials elevated enough to read every mailbox and every drive in the tenant. The controls that govern normal operation were not written for that shape of activity, which is why migration projects attract a separate review.

Reviewers who do this well converge on three questions.

1. Whose infrastructure does the data cross? Not only at rest, but every hop in between.
2. What is retained once the migration is finished? Including the records the tool needs to keep in order to work.
3. Who can access any of it? Which people, in which organisation, under which controls.

CloudM Migrate is available in two deployment models, and they answer those questions differently. The hosted service is run and maintained by CloudM. It removes the infrastructure work, keeps the platform current without customer effort, and is the right choice for the large majority of migrations. This article describes the second model, self-hosted, for the cases where the answer to question one has to be "ours, entirely", because a regulator, a contract or a data-protection team requires processing to happen on infrastructure you own and staff you employ. See Choosing your CloudM Migrate deployment: hosted vs self-hosted for the comparison.

Deployment model and trust boundary

In a self-hosted deployment, CloudM Migrate is installed software. You provide Windows servers, either on premises or in your own cloud tenant, and run the product on them. A deployment consists of a primary server, which hosts the web interface and coordinates the migration, and optionally one or more secondary servers that add parallel processing capacity. PostgreSQL and Redis support the application. Both run on the primary server by default, and both can be placed on separate servers you provide.

CloudM runs nothing in the data path. There is no CloudM-operated relay, queue or staging tier between the source and destination platforms. Migration content is read by your servers from the source platform's API and written by your servers to the destination platform's API.

That makes the trust boundary straightforward to draw. Everything the product does, the interface, the processing, the databases and the reports, sits inside your network. From the Migrate servers, two kinds of connection cross the boundary outbound: calls to the source and destination platform APIs, which carry the content being migrated, and calls to the CloudM licensing service, which carry licensing metadata. Separately, the administrator's browser loads analytics, support and font resources when the web console is open. Those connections originate from the browser, not from the servers, and are covered below. Nothing crosses the boundary inbound.

Architecture

One primary server, as many secondary servers as you need, and nothing between you and the platforms. Data is read from the source and written to the destination through each platform's own APIs, from Windows servers you own, on premises or in your cloud tenant.

What runs on the servers

The component list below is for infrastructure teams sizing and hardening the deployment. Every server runs two Windows services: CloudMigratorService, which runs the primary role, the secondary role or both in one process depending on the install, and CloudMServiceController, which carries out start, stop, restart and upgrade actions requested from the web Service Manager on the primary. The web tier runs in IIS on the primary only.

Component	Where it runs	What it does
Web console and API	Primary, in IIS on port 443	The administrator interface, live progress updates and the REST API. Installed with a self-signed certificate that you should replace with one issued by your own authority.
Migration workers	Every server with the secondary role, including the primary in a basic install	One process per user being migrated, capped per server by the Maximum Users Per Secondary Service setting (default 20). Reads from the source API and writes to the destination API.
Results and scan processes	Every server	Separate processes generate reports, run environment scans and process statistics.
PostgreSQL	Primary by default, or your own server	Project configuration, connection settings, user lists, run results and reports. Never migration content. PostgreSQL 18 is bundled with the installer; an existing PostgreSQL 17.4 or later can be used instead.
Redis	Primary by default, or your own server	Live migration state: run history, statistics, the retry queue, heartbeats and locks. Not a message queue for content.

Servers communicate over gRPC on ports 30061 to 30064, plus PostgreSQL on 5432 and Redis on 6379 where those are shared. The installer adds firewall exceptions for these scoped to the local subnet. The full list, including what each port carries, is in What ports need to be open to use CloudM Migrate. Hardware and operating system requirements are in CloudM Migrate system requirements. The Migrate 4.x desktop Service Manager application no longer exists. All servers are managed from the web interface on the primary.

Scaling out

The default install puts everything on one server. To run more users at once, add secondary servers. Each secondary handles a configurable number of users concurrently (default 20), so three secondaries at the default means 60 users at once. Secondaries can be added or removed during a migration and are managed from the web interface on the primary. Nothing needs installing or configuring on them beyond the installer. Running workers on the primary is optional, and turning it off for large migrations keeps the interface responsive.

For large migrations, as a guideline 25,000 or more users or 10 million or more objects, move PostgreSQL and Redis to their own servers, Windows or Linux. The installer points at an existing PostgreSQL 17.4 or later during setup. The Redis location is set in the web Service Manager after install.

Ports

Port	Between	Purpose
443	Administrator browser and primary server	Web interface (IIS, self-signed certificate replaceable with your own)
30061 to 30064	Primary and secondary servers	Migration services and service controller (gRPC)
5432	Migration servers and PostgreSQL	Shared database
6379	Migration servers and Redis	Migration state
443 outbound	Every migration server and the internet	Platform APIs, CloudM licensing, prerequisite downloads

No inbound connections from the internet are needed. The installer adds Windows Firewall rules for the service and database ports, scoped to the local subnet.

Data in transit

Migration content moves over HTTPS between your servers and the source and destination platforms, using TLS 1.2 or higher as negotiated between Windows and the platform endpoint. The product uses the operating system's TLS stack, so the negotiated version and cipher suite follow your own Windows configuration and platform policy rather than a setting inside the application.

Administrators reach the web interface over HTTPS on port 443. The installation provides a self-signed certificate so the interface is available immediately. It is intended to be replaced with a certificate issued by your own authority.

No inbound connections from the internet are required. The interface is reached from inside your network, and connections between the primary and secondary servers are internal traffic on documented ports, scoped by firewall rule to the local subnet.

Outbound destinations

Two separate allow-lists apply, and it is worth reviewing them as two. A proxy log will show both, and the distinction between them is the distinction between the data path and the administrator's session.

From the Migrate servers

• The source and destination platform API endpoints, for the migration itself
• tracker.cloudm.io and migratortracker-hrd.appspot.com, for licensing
• storage.googleapis.com, for installer prerequisites and update checks
• support.cloudm.io, for support access

From the administrator's browser, when the web console is open

• content.pendo.cloudm.io and Pendo's own hosts, for product analytics
• static.zdassets.com and *.zendesk.com, for the in-product support widget
• fonts.googleapis.com and fonts.gstatic.com, for fonts. The HTML metrics output also pulls the Google Charts loader from www.gstatic.com when it is opened

None of the browser-side endpoints sit in the migration data path. They are reached by the administrator's browser during a console session, and they see that session, not the content being migrated. The section on what leaves your environment sets out what each one receives.

Data during processing

This is the part reviewers question most closely, because it is where content is briefly at its most exposed: read out of one platform, held somewhere, written into another.

CloudM Migrate processes one user at a time, and within a user, one item at a time. There is no bulk staging area. At no point is a copy of the estate, or of a mailbox, assembled anywhere. The unit of work is a single item, and the handling depends on its size.

Items under 10 MB are handled in memory and never written to disk. Larger items are written to a temporary file, encrypted with AES-256 using a key generated for that item, and the file is deleted once the item has been written to the destination.

Alongside the items, the product keeps working state. Each user being migrated has a working cache: a SQLite database, encrypted with AES-256, holding the bookkeeping needed to move that user's data and removed when the migration completes or the environment is cleaned up. Redis, on the primary server and inside your network, holds live migration state: run history, statistics, the retry queue and server heartbeats. Migration content is never written to PostgreSQL.

Store	What goes in	Encrypted	When it is removed
Server memory	Items under 10 MB, in full	Not applicable	As soon as the item is written to the destination
Temporary files	Items of 10 MB and above, one file per item	AES-256, per-item key	Deleted once the item is written to the destination
Per-user working cache	SQLite database of per-user migration bookkeeping	AES-256	On completion, or when the environment is cleaned up
Redis	Migration history, live statistics, retry queue, heartbeats	On the primary server, firewall-scoped to the local subnet	History is exported to the project record; state clears with the run
PostgreSQL	Project configuration, connection settings, user lists, run results. No content	Connection credentials stored encrypted	When the project is archived and deleted, or the server is decommissioned

Data at rest after the migration

Reviewers are right to treat "nothing is kept" as a marketing line. Something is kept, deliberately, and it is worth being precise about what and why.

PostgreSQL holds the project record: configuration, connection settings with credentials stored encrypted, the user lists in scope, run results and generated reports. It also holds migration history, meaning item identifiers and content hashes, not content. That history is the mechanism behind delta and incremental passes. When a project runs again, it compares what the source now holds against what it has already moved, and transfers only the difference. Without it, a cutover-weekend delta would mean re-reading and re-writing the entire estate. Migration reports and failed-item lists are retained as files on the server for you to download.

Removing all of it is a customer action. Migration history can be cleared from a project. The project itself can be archived and then deleted, which removes its record and results. The servers, being your own, can be decommissioned and wiped under your normal asset process. No part of that sequence depends on CloudM performing a deletion on your behalf, which also means you can evidence it directly in an audit.

On integrity, the product verifies transferred items using hashes where the destination platform exposes them, retries transient failures, and records anything that could not be moved in a failed-item list you can act on and re-run. See How does CloudM help ensure data integrity? for the detail.

What leaves your environment

Only one destination ever sees your content: the platforms you are migrating between. The rest divide into calls made by the Migrate servers and calls made by the administrator's browser during a console session.

Destination	What is sent	What is never sent
Source and destination platforms	The migrated content itself, via their APIs	Not applicable
CloudM licensing service	Licensing metadata: the identifier of each migrated account, the source and destination platform, the product version and licence consumption	Message bodies, file contents, file names, folder structures
storage.googleapis.com	Requests for installer prerequisites and update checks	Anything about your data
Pendo, product analytics, from the administrator's browser	Administrator email address, display name, role, product version, Migrate user id, console page URLs and clicks	Migration content, platform credentials, end-user identities
Zendesk, support widget, from the administrator's browser	The widget load, and whatever the administrator types into a support conversation	Anything unless the administrator sends it
Google Fonts and Google Charts, from the administrator's browser	Font and script requests	Anything about your data

Pendo and Zendesk are usage analytics and support tooling on the administrator console. They are not part of the migration data path. There is currently no in-product switch to turn either of them off. If you need to block them, do so at the firewall or proxy, and the console continues to work when they are blocked.

Access control and administration

Access to a self-hosted deployment has two layers, and both belong to you.

Inside the application, administrators sign in to the web interface with named accounts, and what they can do is governed by their assigned role. Sign-in and administrative activity are recorded in an audit log you can review.

Below the application, access to the servers is ordinary Windows administration under your existing controls: domain policy, privileged access management, whatever you already run. CloudM has no access to those servers. Support engagements happen through you, on your terms, with you in control of what is shared.

The credentials the product uses to reach the platforms are provisioned by you in your own tenants. On Google, a service account with domain-wide delegation restricted to the scopes the migration requires. On Microsoft, an app registration with the documented permissions. Because platform scopes and permissions change with the platforms, the current lists live in the connection setup articles for each platform and should be read from there at review time.

For multi-server deployments, Service Manager lets an administrator control the Migrate services on every server from the primary. Day-to-day operation therefore does not require interactive logins to the secondaries, which keeps the number of interactive sessions on those machines low.

Fitting regulated environments

Residency and sovereignty. Processing happens wherever you place the servers. If the servers are in a particular country, region or cloud tenant, the processing is there too. No part of the migration is routed to a CloudM region, and there is no CloudM-side region to select, because there is no CloudM-side infrastructure in the data path.

ITAR-style regimes. Where export-control rules apply, encryption is not the qualifying control. Location and personnel are: where the data is processed, and who is able to access it. A self-hosted deployment lets you restrict both, because the infrastructure and the people who administer it are yours. CloudM is not ITAR registered, and the compliance determination for any specific programme belongs to you and your counsel.

Microsoft government clouds. CloudM Migrate supports the government cloud endpoints natively, including USGovernmentL4 (GCC High) and USGovernmentL5 (DoD), so a migration into those environments does not depend on custom endpoint configuration.

Where this comes up. Most commonly in government and the defence supply chain, in financial services under regulator-directed data handling, and in healthcare. The pattern is the same in each: the deciding factor is not the strength of the encryption but the location of the processing and the identity of the people with access.

Shared responsibilities

Self-hosting moves real work to you. Reviewers should see that clearly before a deployment is agreed.

CloudM	Customer
Maintains the application, issues releases and fixes, documents requirements and configuration	Provides, patches and hardens the servers and operating systems
Provides product support and migration guidance	Owns network controls, firewall rules and the outbound allow-list
Documents the platform scopes and permissions the product requires	Provisions and rotates platform credentials in its own tenants
Records administrative activity in the product's audit log	Monitors, backs up and decommissions the servers, and reviews the audit log

Certification, data protection and testing

CloudM is an ISO 27001 and Cyber Essentials certified organisation.

There is a dedicated Data Protection Manager in place. The business has the relevant systems to comply with its obligations as a data controller and processor and the requirements around data processing principles, rights of the data subject and security of processing.

Regular third-party penetration testing is conducted on the product. Testing takes place every 12 to 18 months by a CREST-accredited provider.

Next steps

For installation, ports, prerequisites and platform configuration, use the articles under Migrate in this knowledge base, starting with system requirements and ports. For a formal security review, a completed questionnaire or a supplier assurance pack, contact your CloudM account team, who will bring in the product and engineering reviewers the questions need.