The same sync engine
that runs Files.com.
Encryption, scale, failure handling, audit trails — the questions IT teams ask before committing a multi-TB migration to a vendor they haven't used before.
Multi-threaded transfers between any supported pair. File-level incremental syncs on re-runs. Glob-pattern filters with full include and exclude semantics. Retries that hold under API rate limits. Per-file audit logs that account for every byte. The engineering depth that backs 4,000+ Files.com customers powers every Mover migration too.
§ 1 · Transfer Engine
The same sync engine that powers Files.com.
Mover is engineered on Files.com's underlying sync engine — the transfer primitives that move billions of files for Files.com's 4,000+ customers, focused for one-time and operator-initiated migrations.
Multi-threaded parallel transfer.
Mover transfers files in parallel where the source and destination APIs permit. Multi-part uploads on object storage. Concurrent connections on protocol-based transfers. The throughput ceiling is whatever the slower side allows — Mover saturates it.
Direct provider-to-provider transfer.
No intermediary staging step. Bytes stream from source to destination through the Mover worker without landing on intermediate disk. For cloud-to-cloud migrations there's no staging bucket, no extra storage cost, no second copy to clean up.
Difference-aware copy.
Mover checks files for differences in size or presence before copying. Identical files at the destination aren't re-transferred. On re-runs and incremental migrations the engine moves only what's new or changed.
File-level incremental sync.
Incremental syncs detect changes at the file level — once a file has been migrated successfully, later runs skip it unless it changed at the source. Detection is file-level, not block-level: any change inside a file re-transfers the whole file. Trades the complexity of block-level diffing for predictable behavior and broad provider compatibility.
Manual reinitiation.
Mover's execution model is operator-initiated: you set up a migration, you launch it, you re-run it on demand. For scheduled / event-triggered file movement (continuous sync, automated workflows), the workload escalates to Files.com — Mover's enterprise sibling that uses the same underlying engine but is platform-orchestrated.
§ 2 · Filters & Scoping
Glob-pattern include and exclude rules.
Filters tell Mover exactly which files and folders move. Patterns are tested in the dry run, validated against real source content, and applied identically on the live transfer.
Include patterns.
Define which files and folders transfer. If no include patterns are provided, the entire source contents move. Patterns apply to paths, filenames, or both.
Exclude patterns.
Define which files and folders to skip. If a file matches both an include and an exclude pattern, the exclusion wins. Folder exclusions apply recursively.
Full glob syntax.
Single asterisk (*) matches one level. Double asterisk (**) matches recursively. Question mark (?) matches any single character. Square brackets ([]) match character sets or ranges. Curly brackets ({}) match alternatives — {Mon,Tue,Wed} matches any filename containing one of those weekdays. Escape sequences match literal special characters — [?] matches a literal question mark.
Path + filename patterns.
Patterns combine path and filename matching. `path/to/*.pdf` matches PDFs in a specific folder. `**/_202{4,5}_.pdf` matches PDFs anywhere whose name contains 2024 or 2025.
Multiple patterns per migration.
Stack as many include and exclude patterns as you need. The rules combine to express complex selection criteria without resorting to manual file-by-file selection or a custom script.
Source-side post-migration cleanup.
Optional: delete migrated files from the source after the transfer succeeds, and optionally remove empty folders. Off by default — keeping a copy at the source preserves a rollback path and supports parallel-system transitions.
§ 3 · Reliability & Retries
Transient failures get retried; persistent failures get reported.
Migrations at scale hit network blips, API throttles, and credential refreshes — that's normal. Mover treats them as recoverable until proven otherwise.
Automatic retry on transient failures.
Connectivity blips, API rate-limit responses, intermittent credential issues — Mover retries automatically. Files that eventually succeed don't appear in the failure log; files that exhaust the retry budget do.
Failures don't bill.
Failed transfer attempts don't count against your usage pack. Only bytes that arrive intact at the destination count toward usage. Connectivity errors, permission errors, and transient API failures are absorbed without charging the pack.
Run Logs — per-file disposition.
Every migration produces a detailed report listing what transferred successfully and what failed. Failures include the reason — permission, filename, source unavailability, destination rejection — so remediation is targeted, not guesswork.
Pause / resume / cancel.
Migrations can be paused, resumed, or cancelled at any time during execution. Paused jobs keep their state and resume from where they stopped — useful for managing destination-side maintenance windows or rate-limit recovery.
Re-run for partial failures.
Some failures clear on a re-run — temporary destination issues, transient permission problems, network conditions. The next run picks up only the files that didn't succeed; successful files aren't re-transferred.
§ 4 · Performance & Concurrency
Throughput tuned to the slower side of the pair.
For most migrations the bottleneck is the source API's read rate or the destination API's write rate. Mover saturates whichever side limits the transfer without manual tuning.
Provider-aware rate limiting.
Mover respects the published rate limits of every supported source and destination. For S3-compatible storage that means tuned multipart upload concurrency; for OAuth providers like Drive, Dropbox, OneDrive, and SharePoint that means staying under per-user and per-tenant API ceilings.
Multipart parallel uploads (object storage).
Large files transfer as multipart uploads with parallel parts. For S3, Azure Blob, GCS, Wasabi, B2, and other object-storage destinations this is the default behavior — no configuration required.
Concurrent file transfers.
Multiple files transfer in parallel where the API surface supports it. The platform automatically tunes concurrency to balance throughput against rate-limit ceilings.
Same-day completion for multi-TB jobs.
For typical multi-TB migrations between cloud providers, the transfer typically completes inside a single business day. The exact figure depends on provider API limits — the dry run includes a size-based estimate.
Batched large migrations.
Very large migrations can be broken into batches via filters and date ranges — useful for staged cutovers where workloads move one slice at a time, with validation between batches.
§ 5 · Security & Encryption
Encrypted in transit. Hardened by inheritance.
Mover inherits Files.com's security posture — the same encryption standards and compliance frameworks the flagship platform runs under.
TLS 1.2 / 1.3 in transit.
Every byte moves over TLS 1.2 or TLS 1.3 — both legs of the transfer, both directions. No exceptions, no opt-in toggle.
AES-256 at rest.
Connection credentials and any metadata Mover stores about your migrations are encrypted at rest with AES-256 — the same hardened standard Files.com applies across billions of files.
Credentials scoped per connection.
Source and destination credentials are stored per connection in an encrypted credential store. They're never exposed in logs, never returned through the API, and never visible after they're entered. Revoke them in your provider at any time.
Least-privilege credential support.
Where the source or destination supports scoped credentials (IAM policies on S3, scoped OAuth on Workspace and M365, restricted SAS tokens on Azure), Mover works with the minimum necessary scope. You don't hand over full-account access for a one-time migration.
SOC 2 Type II + GDPR compliance posture.
Mover inherits Files.com's SOC 2 Type II and GDPR-aligned compliance posture. For HIPAA-bound workloads, Files.com offers a HIPAA-compliant upgrade path; HIPAA-bound data should run through Files.com, not Mover.
Zero data retention by default.
Mover never retains your data longer than necessary for the active migration. Once the transfer finishes and any post-migration validation completes, the data is gone from Mover's infrastructure. You set the retention policy at the destination.
§ 6 · Audit & Visibility
Every action logged, every file accounted for.
Real-time progress tracking.
During execution Mover reports the amount of data moved, the number of files processed, and any issues — live. The dashboard updates without manual refresh; you can leave the migration running and check back to a clean status view.
Per-file Run Logs.
After every run, a detailed report lists exactly what transferred successfully and what failed, with the per-file reason for any failure. The log is the source of truth for "what happened on this migration" — accessible, searchable, exportable.
Pre-migration Dry Run report.
Before any data moves, the dry run produces a discovery report: total file count, total byte size, filter-pattern hit rate, any provider-side issues detected during the scan. The exact pack size you'd need is calculated from this report.
Usage history per pack.
Every usage pack you purchase shows up in your Purchase History with purchased date, expiration date, used amount, remaining amount, and current status (Active / Used / Expired). The accounting is auditable and matches your invoice.
Multiple-pack visibility.
Stack multiple active packs and Mover shows the aggregate balance and per-pack consumption. Useful for accounting splits — assign different packs to different cost centers or projects without losing track of which pack covered which migration.
§ 7 · Execution Model
Operator-initiated, on your timeline.
Mover is for migrations you control: configure, dry-run, launch, verify. The execution model is explicit on purpose — large migrations need a human in the loop.
Manual launch.
Configure the job, run a dry run, review the plan, then launch. No surprise auto-starts, no implicit triggers — every byte moves because you said go.
Manual reinitiation.
Re-run a previously configured job on demand. Useful for resyncing after a source change, retrying after a partial failure, or completing phased rollouts across multiple manual runs.
Connections reused across migrations.
Connections are a first-class object. Authorize a source or destination once and reuse it across every migration that needs it. Fan-out from one source to many destinations, or collect from many sources to one destination — same credentials, same configuration.
For scheduled or event-triggered runs: Files.com.
Continuous sync, scheduled jobs, event-triggered file movement — these aren't Mover's lane. They live in Files.com, which uses the same underlying sync engine but adds the orchestration layer. If your workload needs to run on a cadence or react to upstream events, the right tool is Files.com (Mover's enterprise sibling).
§ 8 · Scale
No artificial ceilings.
Mover's prepaid usage packs scale from 100 GB up to 10 TB per pack, and packs stack — so the transfer ceiling is practical, not architectural. Larger one-time migrations run on Files.com's enterprise infrastructure with the same underlying engine.
Pack sizes from 100 GB to 10 TB.
Five pack sizes cover everything from a quick proof-of-concept (100 GB) through a full multi-TB cutover (10 TB). Pricing scales down at larger packs — the more data you move, the lower the per-GB rate.
Stack packs for larger migrations.
Multiple active packs are supported and you can mix sizes — a 10 TB pack plus a 100 GB top-up for end-of-migration cleanup, for instance. Mover draws from the aggregate balance, so migrations don't need to fit precisely inside one pack.
Usage-pack durations sized for real projects.
Pack durations are 14 days for the 100 GB pack, 60 days for the 1 TB pack, 180 days for the 10 TB pack. Most projects finish well inside the window with room for re-runs and follow-on transfers.
Above 10 TB: Files.com.
For migrations beyond what stacking 10 TB packs covers — multi-hundred-TB or PB-scale moves — the workload typically belongs on Files.com's enterprise infrastructure with a contractual relationship. Same underlying sync engine; different commercial model.
§ 9 · Supported Sources & Destinations
Twenty-plus providers, every combination.
Any supported source can move data to any supported destination. The list below is the matrix of supported connections — pair any two of them as source and destination on the same migration.
Object storage.
Amazon S3, Microsoft Azure Blob Storage, Google Cloud Storage, Wasabi, Backblaze B2, Cloudflare R2, Filebase, Akamai Linode Object Storage, plus generic S3-compatible endpoints for anything else that speaks the S3 API.
Microsoft 365 + Google Workspace.
Microsoft OneDrive (personal + Business), Microsoft SharePoint sites, Microsoft Azure Files. Google Drive (personal + Workspace), with domain-wide delegation for tenant-wide migrations.
Collaboration platforms.
Dropbox (personal + Business), Box (Business + Enterprise + consumer).
File transfer protocols.
FTP, FTPS, SFTP, WebDAV — any server reachable over the public internet that speaks one of these protocols can be a source or destination.
On-premise file servers via the Files.com Agent.
For storage that isn't reachable from the internet — file servers in private data centers, NAS appliances on internal networks, personal computers — the Files.com Agent is a low-footprint application that bridges the connection without requiring inbound firewall changes.
OAuth + access-key authentication.
Each provider uses its native authentication: OAuth for Drive, Dropbox, OneDrive, SharePoint, Box. Access keys for S3 and S3-compatible storage. SSH credentials for SFTP. Account keys or SAS tokens for Azure. No middleware-translation layer.
See it work — run a free dry run.
The fastest way to validate any capability above against your specific migration is to run a free dry run. The report tells you exactly what would happen — and what would trip the migration — before a single byte moves.