Cloud migration challenges that stall a file migration, and what removes each

Cloud migration challenges, as usually written up, are the big architectural ones: which applications need to be rebuilt, how teams retrain, whether one form of lock-in is being traded for another.

File migrations are less glamorous. They are also far more common, and surprisingly easy to underestimate.

Whether you are moving a departmental file server, a Dropbox account, a SharePoint tenant, or an object storage bucket, the same problems surface again and again: unexpected egress fees, incompatible folder structures, failed files, rate limits, and a cutover that eats an entire weekend.

None of these problems is exotic. Any one of them can stall a migration.

Here is what to plan for before the first file moves.

Start with the bill your migration tool does not control

A migration has at least two costs: the tool that moves the data, and the fee the source provider charges to read that data out.

The second charge is easy to overlook because it does not appear in the migration vendor's quote. It arrives on the source provider's invoice, often after the project has already been approved. For a large bucket in a hyperscaler, egress fees can exceed the cost of the migration itself.

Before committing to a move, inventory the source and calculate egress using the provider's published rates. That takes more than a rough estimate of storage consumption. You need an accurate byte count.

A free dry run gives you that count without transferring the data. It also gives you a chance to consider the destination's egress policy. The cost of getting data into a platform matters once; the cost of getting it out matters for years. The egress savings calculator compares the two with current list prices.

Do not recreate the source by accident

A file server, Dropbox, and SharePoint do not organize information the same way.

A departmental share uses nested folders and inherited permissions. Dropbox revolves around team folders. SharePoint divides content among sites, libraries, folders, and its own permission model.

Copying the source hierarchy exactly is rarely a migration strategy. It is a way to preserve old confusion inside a new platform. The result is a document library nobody can find anything in, thousands of unnecessary subfolders, or permissions that have to be rebuilt by hand.

Use the discovery phase to design the destination structure before moving anything. Decide which share becomes which library, which archive stays behind, and which temporary folders do not make the trip.

Explicit include and exclude rules turn those decisions into a repeatable plan rather than a checklist someone follows by hand.

Make every failed file visible

Files fail during large migrations. That is not a sign the project has gone off the rails.

A destination rejects a filename. A path exceeds a length limit. A file is locked during the copy. A provider throttles a request mid-transfer.

The real problem begins when the migration tool reports only that 127 files failed and leaves the team to search through logs or reconcile spreadsheets.

A useful run log shows the outcome of every file: what moved, what did not, and why. Transient failures retry automatically. Persistent failures are easy to isolate and rerun without repeating the entire migration.

"99.9% complete" is not a finish line if nobody knows what sits inside the missing 0.1%. The migration is complete when the exception list is empty, or when every remaining exception has been reviewed and accepted.

Replace the downtime weekend with incremental passes

The traditional migration plan is simple: lock everyone out on Friday, move everything, and hope the copy finishes before Monday morning.

That works for a small dataset. For a multi-terabyte estate, it forces a choice between extended downtime and a rushed cutover. It is also why straightforward migrations get postponed again and again.

Incremental migration changes the shape of the project.

First, move the bulk of the data while people continue working in the source. Then run difference-aware passes that copy only new or changed files. Each pass reduces the remaining delta until the final synchronization takes minutes rather than days.

At cutover, users are pointed to the destination and one last incremental pass captures the final changes. Instead of consuming a weekend, the transition happens between two meetings.

Confirm this capability before choosing a tool. If every run requires a full copy, the downtime problem is built into the product. The five kinds of migration tool differ on exactly this.

Plan for the slower side of the connection

Transfer speed is not a matter of sending data as fast as possible.

Cloud providers enforce rate limits. If a migration pushes faster than the destination accepts, requests begin to fail, retries pile up, and the overall transfer takes longer than it would have at a controlled pace.

The bottleneck can also be at the source. A high-performance cloud destination does not help if the files are coming from a NAS over an office uplink.

The migration tool has to adapt to the slower side of the pair: provider-aware rate limiting, adjustable concurrency, and multipart parallel uploads for object storage. The goal is to use the available capacity without creating a retry storm.

Some limits are physical. Others are self-inflicted. Good transfer orchestration keeps you waiting on the former.

Keep on-premises sources behind the firewall

On-premises file servers and NAS devices are, correctly, not reachable from the public internet.

Making them available to a cloud migration service becomes a project of its own. Opening an inbound port creates a security exception. Building a VPN adds infrastructure and coordination. Copying everything to an internet-facing staging server means moving the data twice.

The simpler model is an agent that runs inside the network. The agent reads from the local share and connects outbound to the migration service.

No inbound port opens. No VPN gets built. The source stays exactly as unreachable from the internet as it was before the migration began. That is how the Files.com Agent works, and it is the whole of the on-premises to cloud approach.

Inventory first, migrate second

The most important question is often the one nobody can answer: what do we actually have?

Many organizations do not know how many files a share contains, how many bytes need to move, which directories hold most of the volume, or how much stale data is buried in the source.

Without that information, cost estimates are guesses, schedules are optimistic, and destination designs rest on assumptions.

That is why the dry run matters so much. Before transferring anything, it walks the source, counts the files, totals the bytes, and shows where the data is concentrated. That inventory informs almost every other decision: egress costs, migration pricing, transfer time, destination capacity, scope, and cutover planning.

Discovery is not a preliminary formality. It is the first phase of the migration, and the cloud migration guide starts there.

Mover is built around these problems

Mover is a data migration tool designed for the practical issues that derail file moves.

A free dry run inventories the source and provides the byte count used to price the usage pack. Include and exclude rules make the scope explicit before the transfer begins. Parallel transfers and provider-aware rate limiting keep data moving without overwhelming either side, and automatic retries never consume billable usage.

Detailed run logs show the disposition of every file, and difference-aware incremental runs reduce the final cutover to a small delta. For on-premises sources, the Files.com Agent connects outbound from inside the network, so no inbound port opens.

Mover runs on the same transfer engine that powers Files.com for more than 4,000 organizations. Pricing is a single usage pack, from $0.15 per gigabyte at scale, with no subscription and no minimum.

If a migration has been sitting on the roadmap because the scope is unclear, begin with the simplest useful step: run a free dry run.

Once you know what you have, the rest of the project is much easier to plan.