Every data migration conversation eventually arrives at the same question: "Can't we just upload it?"
Sometimes the answer is yes. Sometimes the answer is "technically yes, but you'll regret it." The trick is knowing where the line sits - the break-even point where physical transport stops being overkill and starts being the obviously correct answer.
Let's find that line.
The Variables That Matter
Four things determine whether you should upload your data or put it in a vehicle:
1. Your upload bandwidth - not your connection speed, but how much of it you can actually dedicate to a sustained transfer without crippling the rest of your business.
2. The data volume - the total amount you need to move in one go.
3. Your urgency - whether you can afford to wait days or weeks, or whether you need it done by tomorrow.
4. Your network impact tolerance - whether your organisation can function with a saturated upload pipe for an extended period.
Most people only think about the first two. The second two are what actually drive the decision.
The Break-Even Maths
Let's start with the theoretical numbers, assuming you can dedicate 100% of your bandwidth to the transfer (you almost certainly can't, but we'll get to that).
At 100 Mbps Dedicated Upload
| Data Volume | Upload Time | Physical Transfer |
|---|---|---|
| 500 GB | ~12 hours | Upload wins |
| 1 TB | ~24 hours | Borderline |
| 2 TB | ~2 days | Physical wins |
| 5 TB | ~5 days | Physical wins easily |
| 10 TB | ~10 days | Not even close |
At 100 Mbps, physical transport becomes the better option somewhere around the 2TB mark. We can collect your data, copy it locally, transport it, and have it uploading from our data centre - all within the same day. An internet upload at this speed takes two days and is only getting started.
At 1 Gbps Dedicated Upload
| Data Volume | Upload Time | Physical Transfer |
|---|---|---|
| 2 TB | ~5 hours | Upload wins |
| 5 TB | ~12 hours | Borderline |
| 10 TB | ~24 hours | Physical wins |
| 25 TB | ~2.5 days | Physical wins easily |
| 50 TB | ~5 days | Not even close |
With a gigabit connection fully dedicated to the transfer, the crossover shifts up to around 10TB. Below that, a fast internet upload is reasonable. Above that, you're looking at multi-day transfers that start to cause real problems.
At 10 Gbps Dedicated Upload
| Data Volume | Upload Time | Physical Transfer |
|---|---|---|
| 10 TB | ~2.5 hours | Upload wins |
| 25 TB | ~6 hours | Upload wins |
| 50 TB | ~12 hours | Borderline |
| 100 TB | ~24 hours | Physical wins |
If you genuinely have 10 Gbps of upload bandwidth available - and that's a big "if" - the break-even point moves to around 50TB. But there's a catch: very few organisations actually have 10 Gbps of dedicated upload capacity. And those that do are paying handsomely for it.
The Word That Changes Everything: "Dedicated"
Those tables assume you're throwing 100% of your bandwidth at the transfer. In the real world, that almost never happens. Your business still needs to function. People still need to make video calls, access SaaS applications, and use the VPN.
Here's what happens when you throttle the transfer to keep the business running:
At 1 Gbps Connection, 50% Dedicated to Transfer
| Data Volume | Upload Time | Physical Transfer |
|---|---|---|
| 2 TB | ~10 hours | Upload wins |
| 5 TB | ~24 hours | Borderline |
| 10 TB | ~2 days | Physical wins |
The break-even drops from 10TB to roughly 5TB.
At 1 Gbps Connection, 25% Dedicated to Transfer
| Data Volume | Upload Time | Physical Transfer |
|---|---|---|
| 1 TB | ~10 hours | Upload probably wins |
| 2.5 TB | ~24 hours | Borderline |
| 5 TB | ~2 days | Physical wins |
| 10 TB | ~4 days | Physical wins easily |
Now you're looking at a break-even around 2.5TB. That's a surprisingly small amount of data. Most organisations with a 1 Gbps connection can't realistically dedicate more than a quarter of it to a sustained multi-day transfer, which means physical transport starts winning much earlier than most people expect.
The Factors Most Calculations Miss
Every break-even calculation you'll find online - including the tables above - makes assumptions that don't hold up in practice. Here's what they leave out.
TCP overhead and retransmissions. You never achieve theoretical maximum throughput on a real network. Protocol overhead, packet loss, and retransmissions typically eat 10-25% of your bandwidth. That "1 Gbps" connection delivers maybe 750-800 Mbps of actual data throughput on a good day.
Network congestion during business hours. Your dedicated percentage drops further when everyone's on video calls between 9am and 5pm. That 25% allocation might effectively become 15% during peak hours.
Upload failures requiring restart. Large transfers fail. Connections drop, sessions time out, storage errors occur. If a 48-hour transfer fails at the 40-hour mark, you might be starting again from scratch - depending on your tooling and whether it supports resumable uploads.
Staff time monitoring a multi-day transfer. Someone has to watch a multi-day transfer. Check it's still running. Restart it when it stalls. Verify integrity when it finishes. That's not free - it's an engineer's time that could be spent on other work.
The risk of failure at 90%. We've seen this more times than we can count. A transfer gets to 90% complete, fails due to a network blip or a timeout, and the tool doesn't support resuming. Three days of transfer time, wasted. Start again.
When you factor all of this in, the real-world break-even point is lower than the theoretical numbers suggest. Often significantly lower.
The Never-Ending Upload Problem
Here's a pattern we see regularly: an organisation estimates a transfer will take three days. They kick it off on Monday, expecting to be done by Thursday. By Friday, it's at 60%. Over the weekend it stalls twice and nobody notices until Monday morning. By the following Wednesday - nearly two weeks later - it finally completes.
The problem isn't the bandwidth. The problem is that internet uploads are non-deterministic. You're at the mercy of network conditions, ISP throttling, cloud provider ingestion rates, and every other variable between your server room and the destination.
Physical transport is deterministic. We know exactly how long it takes to copy data to local NVMe storage (limited only by your source infrastructure's read speed). We know exactly how long it takes to drive from your site to our data centre. We know exactly how long it takes to upload from our 10 Gbit+ connection. There are no variables, no surprises, no "it should be done by Thursday but might be done by next Wednesday."
When someone asks us "how long will it take?", we give them a number we're confident in. That predictability has value, especially when the transfer is on a project's critical path.
When Internet Upload IS the Right Choice
We're not going to pretend physical transport is always the answer. There are clear scenarios where uploading over the internet is the better option:
Under 1-2TB with decent bandwidth. If you've got a gigabit connection and the data volume is small, just upload it. The transfer completes in a few hours and the network impact is minimal. There's no point in arranging a physical collection for a dataset that'll be done before lunch.
Incremental or ongoing sync. Physical transport is for one-time bulk moves. If you need continuous replication - database sync, backup mirroring, ongoing file synchronisation - that's a network transfer by definition. Tools like Azure File Sync, rsync, or robocopy with scheduling are built for exactly this.
Cloud-to-cloud transfers. If your data is already in one cloud region and needs to move to another, it's travelling over the cloud provider's backbone network, not your internet connection. The bandwidth is excellent (Microsoft's backbone runs at 25 Gbit+), though watch the egress charges.
You genuinely have weeks and no bandwidth constraints. If there's truly no urgency, your connection can handle the load, and you've got tooling that supports resumable transfers with integrity verification - upload away. Just make sure that "no urgency" assessment is honest and not optimistic.
Finding Your Break-Even
The honest answer is that the break-even point is different for every organisation. It depends on your actual upload speed (not what you're paying for - what you actually get), how much of it you can sacrifice, how urgently you need the data moved, and how much risk you're willing to accept around transfer failures.
As a rough guide:
- 100 Mbps upload: Physical wins above ~2TB
- 1 Gbps upload (realistic allocation): Physical wins above ~3-5TB
- 10 Gbps upload: Physical wins above ~50TB
- Any speed, any volume, deadline tomorrow: Physical wins
But those are generalisations. Your situation has specifics that matter.
Not Sure Where You Fall?
We'll calculate it for you. Tell us your data volume, your available bandwidth, and your timeline, and we'll tell you honestly whether physical transport makes sense or whether you should just upload it. No charge for the calculation, no obligation, and if the answer is "just upload it," we'll say so.
There's no point in paying for a service you don't need. But there's also no point in spending two weeks on a transfer that could be done in a day.
Want us to run the numbers for your data transfer? Get in touch - we'll calculate your break-even point and give you a straight answer on the fastest, most cost-effective way to move your data.