AWS DataSync File Share Migration: Cutover Without the Weekend Outage

Title: AWS DataSync File Share Migration: Cutover Without the Weekend Outage

To migrate an on-premises NFS or SMB file share to AWS with minimal downtime, run an AWS DataSync migration in two phases: seed the full dataset with one long-running task while users keep working, then run repeated incremental syncs that copy only changed files. On cutover you freeze writes on the source, run one final incremental, verify, and repoint clients. The actual outage is the length of that last delta plus DNS, not the length of the whole transfer.

That pattern works because DataSync separates "copy everything" from "copy what changed", and because it checksums and verifies data as it goes. The rest of this article is the configuration that makes the cutover boring: where to put the agent, which task mode to pick, how to handle metadata and deletions, and what to check before you touch anything.

Check these five things before you deploy an agent

Migrations fail on the boring prerequisites, not the transfer itself. Confirm all of the following before you create a single DataSync resource.

Where the agent will run. DataSync uses a virtual appliance called an agent that reads from your on-premises storage and pushes to AWS. It runs as a VM on your hypervisor. The supported platforms are VMware ESXi 7.0 or 8.0, Linux KVM, and Microsoft Hyper-V 2012 R2, 2016, or 2019, where the agent is a generation 1 VM. On KVM, AWS tests and supports CentOS/RHEL 7 and 8 and Ubuntu 16.04 and 18.04 LTS; other distributions may work but are not guaranteed. You can also run the agent as an EC2 instance from a provided AMI, but AWS does not recommend an EC2 agent for reading on-premises storage because of the increased network latency.

Which service endpoint the agent talks to. The agent reaches the DataSync service through one endpoint type: public, FIPS, VPC, or FIPS VPC. A VPC endpoint, backed by AWS PrivateLink, keeps the transfer off the public internet and inside your VPC. An agent can only use one endpoint type, so if you need both public and VPC transfers you deploy an agent per type. Pick this before activation; it is baked into the agent.

Network paths and ports. DataSync has specific port and protocol requirements between the agent and your storage, between the agent and the service endpoint, and out to AWS storage. If a firewall sits in any of those paths, get the rules approved now, not on cutover night.

The size and shape of the dataset. Count files, not just terabytes. Millions of tiny files behave very differently from a few large ones, and the task mode you choose depends on it (next section).

Whether your link can carry the seed in time. If a full copy over your existing circuit takes weeks, DataSync over the wire may be the wrong tool and an offline transfer appliance is worth pricing. Decide that before committing.

Pick the task mode deliberately

DataSync tasks run in one of two modes, and the choice is not cosmetic. Enhanced mode is for transfers between NFS or SMB file servers, or HDFS clusters, and supported AWS storage, using an Enhanced mode agent. Basic mode covers the other supported location pairs, but Basic mode tasks are subject to quotas on the number of files, objects, and directories in a dataset, and Basic mode prepares, transfers, and verifies sequentially, which makes it slower for most workloads.

For an on-premises NFS or SMB share going to Amazon S3, Amazon EFS, or Amazon FSx, Enhanced mode is the default answer, especially if the share holds a large or unknown number of files where Basic mode quotas would bite.

Set it explicitly with --task-mode ENHANCED when you create the task. If the location pairing does not support Enhanced mode, use Basic and plan around the quotas.

Configure the task so the cutover is a delta, not a full copy

The single most important option for a low-downtime migration is transfer mode. DataSync can transfer either only the data and metadata that changed since the last run, or all data every time. Your seed run copies everything; every run after that copies only what changed. That is what shrinks the cutover window.

Handle metadata and deletions on purpose:

• Metadata. DataSync can preserve POSIX permissions, ownership, timestamps, tags, and ACLs. Keep Uid and Gid at their integer-preserving default so ownership survives the move, and leave the recommended Atime behaviour in place.
• Deletions. DataSync can either keep files in the destination that no longer exist in the source, or delete them so the destination mirrors the source exactly. During interim syncs, keeping them is safe. Before the final cutover sync, decide whether the destination should mirror the source exactly.

Set a bandwidth ceiling so DataSync does not starve production traffic. The BytesPerSecond parameter caps throughput per task execution and can be changed on a running or queued execution from the console, CLI, or API. The value is in bytes: 104857600 is 100 MiB/s.

A create-task call for the seed looks like this:

aws datasync create-task \
  --source-location-arn "arn:aws:datasync:eu-west-1:111122223333:location/loc-onprem-nfs" \
  --destination-location-arn "arn:aws:datasync:eu-west-1:111122223333:location/loc-efs" \
  --name "fileshare-seed" \
  --task-mode ENHANCED \
  --options TransferMode=ALL,VerifyMode=ONLY_FILES_TRANSFERRED,Uid=INT_VALUE,Gid=INT_VALUE,BytesPerSecond=104857600

For every incremental after the seed, override the transfer mode:

aws datasync update-task \
  --task-arn "arn:aws:datasync:eu-west-1:111122223333:task/task-id" \
  --options TransferMode=CHANGED,VerifyMode=ONLY_FILES_TRANSFERRED,Uid=INT_VALUE,Gid=INT_VALUE,BytesPerSecond=104857600

Choose a verification mode that matches your risk

DataSync checksums data during the transfer regardless of settings, and you choose how much extra verification runs at the end. ONLY_FILES_TRANSFERRED is the recommended setting: it verifies the checksums of what this execution actually moved, which is the right cost/safety trade-off for incremental runs. POINT_IN_TIME_CONSISTENT verifies the entire dataset at both ends, which is thorough but scans everything and takes far longer on a large share. NONE skips the end-of-transfer check entirely and relies only on the in-flight integrity checks.

A sane pattern: run interim syncs with ONLY_FILES_TRANSFERRED, and if compliance requires it, run one POINT_IN_TIME_CONSISTENT pass during a quiet period so you have a full end-to-end verification on record. Designing that evidence trail is part of a defensible security and compliance posture, not an afterthought.

Run the interim syncs on a schedule

Between seed and cutover, keep the destination warm with scheduled runs so the final delta is tiny. DataSync task scheduling supports hourly, daily, weekly, and custom cron or rate expressions. A rate expression is the simplest way to run a recurring delta:

aws datasync update-task \
  --task-arn "arn:aws:datasync:eu-west-1:111122223333:task/task-id" \
  --schedule Schedule="rate(6 hours)"

Watch the execution history. If each scheduled run copies roughly the same small volume, your cutover delta is predictable. If churn is spiking, find out why before you pick a cutover time.

The cutover, step by step

The migration up to this point has been invisible to users. The cutover is the only part with an outage, and you want it measured in minutes.

1. Announce and freeze writes on the source share. Read-only mount, drained application, or an actual maintenance window depending on the workload.
2. Run one final incremental in CHANGED transfer mode. Because interim syncs kept the destination current, this copies only what changed since the last scheduled run.
3. Verify the execution completed clean with your chosen verify mode and check the task report or CloudWatch Logs for skipped or failed files.
4. Repoint clients to the new location: update the mount targets, the DFS namespace, or the DNS name your clients resolve.
5. Keep the source read-only for a defined rollback window before you decommission it. Do not delete anything the day of cutover.

The rollback story is simple because you never mutated the source. If the new location misbehaves, clients point back at the frozen original.

The trade-off, and what it costs later

DataSync is the right tool when your network link can carry the seed in a reasonable time and the source is a live, changing share you cannot take offline for the whole copy. The cost you pay later is per-gigabyte transfer charges plus the operational habit of watching task executions; budget for both.

Where it stops being the right tool: if a full copy over your link would take weeks, you are fighting physics, and an offline data transfer appliance moves the seed while DataSync handles only the final deltas over the wire. And if you are moving block volumes or whole servers rather than file data, this is the wrong service entirely; that is server and volume replication, a different track. Sizing that decision honestly, before the first byte moves, is exactly the kind of judgement that belongs in a cloud migration plan rather than discovered mid-cutover.

Frequently asked questions

Does AWS DataSync migration require downtime?

Not for the bulk of it. The seed copy and every incremental run while users keep working. The only outage is the final incremental sync after you freeze writes on the source, plus the time to repoint clients. With scheduled interim syncs keeping the destination current, that final delta is small and the window is short.

Enhanced mode or Basic mode for on-premises file shares?

Use Enhanced mode. It is supported for NFS, SMB, and HDFS sources going to AWS storage, and it has no dataset quota on the number of files, objects, or directories. Basic mode is subject to those quotas and processes sequentially, which is slower for most migrations. Only fall back to Basic if your specific location pairing does not support Enhanced.

How do I stop DataSync from saturating my internet link?

Set the BytesPerSecond option to cap throughput per task execution. The value is in bytes, so 104857600 limits a task to 100 MiB/s. You can change it on a task or even on a running execution from the console, CLI, or API, so you can throttle during business hours and open it up overnight.

Will DataSync preserve file permissions and ownership?

Yes, if you configure it to. Keep the Uid and Gid options at their integer-preserving default so POSIX ownership survives, and DataSync can also carry timestamps, POSIX permissions, ACLs, and object tags. Decide your deletion behaviour separately: DataSync can either keep destination files that no longer exist in the source or delete them to mirror the source for the final sync.

Can I keep the on-premises share as a rollback after cutover?

Yes, and you should. Because DataSync only reads the source, the cutover never modifies it. Leave the source mounted read-only for a defined window after you repoint clients, so you can fall back instantly if the new location has a problem, then decommission it once you are confident.