Cloud migration strategy for the data, in four decisions

Most cloud migration strategy work focuses on infrastructure: which applications move first, what gets rehosted or rebuilt, and how the network will change.

Then someone asks about the files.

That question often arrives late. Sometimes late enough that years of shared drives, cloud folders, and object storage are handed to a script and a long weekend.

The data deserves its own strategy.

Whether you are moving from Dropbox to OneDrive, Google Drive to SharePoint, Amazon S3 to Azure or Wasabi, or a file server in a closet to the cloud, a successful migration depends on four decisions. Make them early, and the move is manageable. Make them during cutover, and they get expensive.

Decide what is worth moving

The safest answer seems to be everything. It is rarely the best one.

A 15-year-old departmental share probably contains valuable records. It also contains abandoned exports, obsolete project folders, duplicate media files, and archives no one has opened since the last reorganization.

Every unnecessary byte costs three times. It incurs egress fees when read from a cloud source. It consumes time and bandwidth during the migration. And it keeps generating storage costs at the destination for as long as it sits there.

Before copying anything, inventory the source.

A free dry run walks the full directory tree, counts files, totals the bytes, and shows where the largest concentrations of data are. In most environments, a small number of folders account for a surprisingly large share of the total volume. Those are the places to review first.

This is also the right time to turn cleanup intentions into migration rules. Define explicit include and exclude filters for obsolete folders, temporary files, duplicate exports, or data outside an agreed retention period.

"Clean it up later" is not a strategy. Once old data arrives at the new destination, it stays there.

Not everything excluded from the migration needs to be deleted. Some data belongs in low-cost archive storage rather than in a working document library or a high-performance storage tier. A migration is a rare chance to review the entire data estate at once, which makes it the moment to separate active information from material kept only for historical, legal, or compliance reasons.

Design the destination before copying the data

A migration does more than change where files are stored. It sets the structure people work with for years.

A team folder becomes a SharePoint site or document library. An object storage bucket becomes a container with a new prefix convention. A departmental file share keeps its existing hierarchy, or finally gets the organization employees have wanted for years.

Make those choices during the dry run, while mappings are easy to change. Do not wait until files have landed, links have been shared, and users have created bookmarks.

More importantly, design around the destination's operating model rather than reproducing the source exactly.

Consider permissions. On a traditional file server, access is controlled through folder-level access-control lists, often with years of exceptions layered on top. SharePoint is organized around sites, libraries, and Microsoft 365 groups.

Recreating every source permission entry in SharePoint produces a complicated environment that no one wants to administer. Mapping each department to a library with the correct group already assigned is simpler, safer, and easier to maintain. SharePoint migration has its own page for exactly this reason.

The goal is not to preserve every historical quirk. It is to preserve access and business function in a structure suited to the new platform.

Make cutover a short event, not a long outage

The traditional migration model is familiar: lock everyone out on Friday, copy data all weekend, and hope the process finishes before Monday morning.

That approach is avoidable.

Start with a bulk migration while employees continue working in the source. Once the initial copy is complete, run an incremental pass that transfers only files that are new or have changed.

Then run another.

Each pass shrinks the remaining difference between source and destination, and the final cutover gets smaller and more predictable. When the outstanding delta represents a few minutes of activity, direct users to the destination and run one final incremental sync.

The bulk of the work happens in the background. The transition itself is brief enough that most users barely notice it.

This makes incremental migration one of the first capabilities to check in any migration tool. A tool that can only perform a full copy forces a long downtime window. A tool that compares source and destination and transfers only the difference gives you the schedule back. The five kinds of migration tool split on exactly this question.

Calculate what the source will charge you to leave

Migration budgets focus on labor and tooling. For cloud-to-cloud moves, the larger expense is often egress: the fee the source provider charges when data is read out of its platform.

At scale, those charges are substantial. They also appear on the source provider's invoice, not the migration tool's, which makes them easy to overlook during planning.

Estimate egress before selecting the destination or approving the move. The calculation needs the total amount of data that will be read, the source provider's published egress rates, API or transaction charges where they apply, any data that will be read more than once, and the destination's own egress policy.

That last item matters. A destination with high exit costs creates the same problem the next time you need to move.

On-premises file servers carry no per-gigabyte egress fee, which is why moving from on-premises storage to the cloud is the cheapest migration to run. Moving from a hyperscaler to a flat-rate object storage provider often pays for itself within the year on egress alone; the egress savings calculator runs that math with current list prices.

Model the full cost before the first byte moves.

The data migration strategy on one page

Inventory the source: count files, total the bytes, find the large folders, and estimate transfer costs. Define what moves with explicit filters rather than a future cleanup project. Separate active data from archive data, and stop paying premium storage rates for information nobody reads.

Design the destination before copying files: folder, library, container, and permission mappings, all decided on the dry run. Run the bulk migration in advance while users keep working in the source. Use incremental passes to catch up until cutover is a short, controlled event.

Validate the result with a record of every file copied, skipped, or failed. And account for egress in the project budget from the start. The cloud migration guide walks each of those steps in order.

Start with the dry run

Mover is built for this part of the cloud migration.

It transfers files between any two of 20+ cloud platforms and on-premises shares. A free dry run inventories the source and calculates the required usage pack before any data moves. Mover then runs the bulk transfer in parallel while users continue working, follows it with incremental passes, and records the disposition of every file.

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

Before planning a weekend cutover, or choosing a destination on assumptions, run a free dry run.

A good data migration strategy starts with one fact: knowing exactly how much data you have.