All tools

Migration Cost and Time Estimator

Model how long a media migration will take based on data volume, upload speed, utilization, and schedule.

Why this tool is useful

Migration timelines fail on a predictable mistake: someone divides total data by the connection speed and reports the result as the schedule. That calculation describes a transfer running flat out, uninterrupted, at the full rated line speed. Real migrations do not run that way. They share bandwidth with production traffic, pause during business hours, and rarely achieve the number on the contract.

This estimator models the migration as it actually runs. You set the data volume, the connection speed, the share of bandwidth the transfer is allowed to use, how many hours per day it runs, and a start date. It returns an elapsed calendar duration and a projected completion date, plus sensitivity views showing how the finish date moves as speed and daily transfer window change.

1. Your data

Total volume

2. Your connection

3. Transfer window

Start date

Estimated completion

October 7, 2026

~5.8 days elapsed at 1.0 Gbps, 40% utilization, and 24 active hrs/day.

Speed sensitivity

SpeedCompletionElapsed
500 MbpsOctober 13, 202612 days
1.0 GbpsOctober 7, 20265.8 days
1.5 GbpsOctober 5, 20263.9 days

Schedule sensitivity

ScheduleCompletionElapsed
8 hrs/dayOctober 19, 202617 days
16 hrs/dayOctober 10, 20268.7 days
24 hrs/dayOctober 7, 20265.8 days

Example use cases

  • Planning a move off a LucidLink or on-premises NAS

    Work out whether a library can move over the existing connection inside the contract window, or whether the schedule requires physical seeding.

  • Deciding between overnight and around-the-clock transfer

    Compare a migration limited to nights and weekends against one running continuously, and see what the restriction costs in calendar weeks.

  • Setting expectations with stakeholders

    Give a client or an internal team a completion date built on stated assumptions rather than a best-case number that will slip.

  • Justifying a bandwidth upgrade

    Show the finish date at the current line speed against the finish date at a higher tier to support the case for the upgrade.

FAQ

The dominant factors are data volume, usable upload bandwidth, and how many hours per day the transfer is allowed to run. As a reference point, 100 TB over a 1 Gbps connection running continuously at full rate takes roughly nine days. The same 100 TB at 50 percent bandwidth utilization, restricted to a twelve-hour overnight window, takes closer to five weeks. The connection speed on the contract is usually the least important of the three variables, which is why estimates based on speed alone are consistently optimistic.
Assume well under 100 percent. A migration sharing a link with production traffic realistically sustains 50 to 70 percent of the rated speed, and that is before protocol overhead, per-file latency on libraries with many small files, and throttling at either end. Transfers running overnight on an otherwise idle link can reach 80 to 90 percent. If you have no measurement to work from, model at 60 percent, then re-run the estimate against observed throughput after the first day of real transfer.
Physical transfer becomes the better option when the network estimate runs past a few weeks. Most large cloud providers offer a shippable appliance or accept customer-supplied drives, and the turnaround is typically one to two weeks door to door regardless of how much data is on the device. As a rough threshold, if you are moving more than about 100 TB on a connection under 1 Gbps, price the physical option. A common approach is to seed the bulk archive physically and transfer only active projects and post-seed changes over the network.
Yes, if the migration is sequenced rather than run as a single cutover. The standard approach is to move dormant and archived material first while active projects stay in place, then move projects individually as they wrap, and switch new work to the destination from an agreed date. A final delta pass catches anything that changed after its initial copy. This takes longer in total elapsed time than a single bulk move, but it avoids the freeze window, which is usually the more expensive constraint.