Availability: Migrate isn't offered for purchase or activation at launch. It's coming later. This page explains how Migrate works so you can plan client moves ahead of time. There's no Migrate pricing yet. To hear when it's available, submit a request.
When you create a Migrate job, the source and destination connectors define where data comes from and where it goes. Each job carries configuration that controls how source data is filtered, how it is handled during transfer, and what happens to the structure at the destination. Understanding these settings lets you control the migration precisely before you run it.
Source and Destination Configuration
Each job has a source and a destination block. The source specifies:
- The connector type (for example,
onedrive,smb_share,exchange_on_prem) - The credential ID from the vault that authorizes access
The destination specifies the same: connector type and credential ID. Credentials are fetched by the agent at job start — they are never embedded in the job record itself.
Filter Configuration
Use the job's filter settings to control what gets transferred:
- Include or exclude specific paths, folders, or mailbox folders
- Set file type or size constraints (depending on the connector's capabilities)
Filters are set at job creation and apply to every run of that job. If you need different filtering for different workloads, create separate jobs.
Transfer Configuration
The job config block contains settings that affect how data moves:
| Setting | What It Controls |
|---|---|
concurrency |
Number of parallel upload threads |
chunk_size_mb |
Size of each upload chunk |
bandwidth_limit_mbps |
Cap on upload throughput |
verify_integrity |
Whether the agent checks checksums after upload |
delete_after_upload |
Whether source files are deleted after successful transfer |
flatten_structure |
Whether folder hierarchy is preserved or flattened at destination |
staging_destination |
Override the default R2 staging bucket |
The retry options in the config control how the agent handles transient failures during upload.
Handling Mismatches
Not every source maps cleanly to every destination. Some situations to plan for:
Folder structure differences. Cloud storage and file shares may use different path conventions. If flatten_structure is enabled, all files land in the root of the destination with no folders. Leave it off to preserve the original hierarchy.
Mailbox folder names. When migrating mailboxes (for example, Exchange on-prem to Exchange Online), system folder names may differ between providers. The agent uses the connector's own mapping for standard folders.
Unsupported file types. Some destinations have restrictions on file types or names. Files that fail to upload are recorded as errors in the progress report and do not halt the job.
Invalid combinations. Migrate's connector registry enforces valid source-destination-job-type pairings. If a combination is not supported, the job creation request is rejected before any data moves.
FAQ
Can I change the filter after a job has run? You can update the job's configuration between runs. Changes take effect on the next run.
What happens to files that fail the integrity check?
If verify_integrity is enabled and a checksum mismatch is detected, that file is marked as errored in the progress batch. The job continues with remaining files. Check the job's progress detail and re-run to retry errored items.
Does delete_after_upload delete from the source immediately?
Yes — it is applied per file after a successful upload. Test with a small batch, or scope the job with its source filter, before enabling this on a full migration — no scan can be run to preview it (see the correction note at the top of this page).