Large Cloud Transfers: When a Desktop App Is the Right Tool
· 5 min read · Updated
Moving a few files is easy anywhere. Moving terabytes depends on where the work runs. For most transfers, a desktop app on your own machine beats a browser-based or hosted tool. For a single bulk move of a very large dataset into one provider, that provider's own migration service can be faster.
A browser-based transfer happens inside a tab, and a tab is a small, supervised space. It has a memory budget, it can be paused or discarded when you switch away, and it usually holds only a handful of connections. A dozen photos fit easily. A media library runs into those limits: the tab slows, the laptop heats up, and a job that should run for an hour cannot stay awake long enough to finish.
Hosted services move the work onto their own machines. The data travels from the source into their infrastructure and then back out to the destination, you wait for both legs, and the company pays for the bandwidth in the middle. That cost comes back to you as a subscription, a per-GB charge or a monthly transfer cap.
Server functions also run on a clock. AWS Lambda, for example, documents a maximum function timeout of 900 seconds, or 15 minutes[1]. Many serverless jobs are designed to finish in seconds or minutes, while a large migration needs hours. When the clock runs out mid-file, the job has to be broken into pieces and stitched back together, and if that orchestration is wrong, the result is gaps and duplicates.
A desktop app can use the memory and processor your machine has, open many transfers in parallel, and keep running for as long as the work takes. If the connection drops, Blober can retry failed files, and an interrupted task can be resumed so completed files are not sent again.
Blober also streams files. It passes the data through to the destination without saving a full copy of every file to your disk first, so disk space stops being the limit. Server-to-Server vs Download-and-Reupload explains why that matters once a job reaches thousands of files.
Because the transfer runs from your machine, it uses your own connection and your own IP address. A slow link means a slow transfer. There is also no shared relay address for a provider to throttle or block for every user of the tool at once. A hosted service reaches every provider from the same pool of company servers, which is the traffic pattern most likely to attract shared-service limits. Your own account and API limits still apply either way.
For a single move of a very large dataset (tens of terabytes or tens of millions of files) into one destination, the fastest path often skips your machine. Some providers run datacenter-to-datacenter migration, where the data never makes the round trip through your home or office connection. Backblaze, for example, lists assisted data migration as available for B2 Cloud Storage[2], and what can take weeks streaming through your own link can take far less over a datacenter one. If you are doing one big move into one provider and you can grant that service access, start there. There is a worked 25 TB example in Migrating 100M+ Files from DigitalOcean Spaces to Backblaze B2.
Any client-side transfer, from a desktop app or a command-line tool, has to pull the data down to your machine and push it back up, which is two trips through your connection. For the very largest one-time moves, a provider's migration is faster because it skips those trips.
A provider migration helps in a narrow case: one big move, into one provider that offers it, when you can hand that provider access. Outside that case, a desktop app like Blober is usually the better fit, and for some teams it is the only acceptable one.
- You cannot share credentials with anyone. Assisted migration means granting a third party access to your storage. For regulated data, client data under NDA, or anything inside a SOC 2 or ISO 27001 boundary, that is often ruled out. A team in that position cannot hand its keys to a destination provider's migration service any more than it could hand them to a relay. Blober keeps your credentials on your own machine and adds no third party to the path, so the transfer stays inside the controls you already have. See How Blober Works.
- The move repeats. Migration services are built for a single bulk lift. New uploads, folder moves and periodic refreshes, done by re-running a saved job whenever you choose, are what a desktop tool is for.
- No assisted path exists. Provider migration almost always moves data into that one provider. Moving between two arbitrary providers, or pulling a library out of a consumer cloud like GoPro Cloud or Google Photos, has no assisted option, so a desktop app that connects to each provider directly is the practical route.
- The scale is moderate. For gigabytes or a few terabytes, arranging an assisted migration is more trouble than it is worth, and a desktop app can start right away.
- You want to watch it happen. A desktop transfer stays visible and under your control, so you can pause, resume and verify on your own machine.
Is a desktop app the fastest way to move a very large dataset? Not always. For a one-time move of tens of terabytes into a single provider that offers datacenter migration, that route is usually faster, because it skips the trip through your connection. A desktop app is better for control, privacy, ongoing use, and moves between providers that have no assisted option.
What if I cannot give a third party access to my storage? Then a desktop app is the right choice. Blober uses your credentials on your own machine and adds no outside party to the transfer, so it fits inside compliance boundaries that rule out both hosted relays and assisted migration services.
Does a large transfer use my own internet connection? Yes, when you move data between providers. A desktop tool streams it through your machine, so the bytes travel down and back up over your connection, and a slow link is still slow. It does not save a full copy to your disk along the way.
What happens if my transfer is interrupted? Blober retries failed files during a run. If you stop, resume the task and it continues at file level instead of starting the whole migration again.