Use S3 as the loading dock for your next server migration

Moving 14 GB and 42,000 files off an aging Windows server did not need a VPN, an open firewall port, or a new product. It needed a private S3 bucket and two small jobs.

Every hosting migration has the same awkward middle. The code lives in Git, so it moves easily. The runtime data does not: uploads, generated reports, signature images, FTP drop folders, years of documents. That data sits on the old server, it has to land on the new one, and the two machines usually have no good way to talk to each other.

On a recent client move we solved this by putting an S3 bucket between them. The old server pushes into the bucket. The new server pulls out of it. Neither server ever connects to the other. This post explains how that works, where it is strong, where it hurts, and how it compares with the other ways people move files.

The pattern in one picture

The old server runs one command, aws s3 sync, which uploads over HTTPS. The new server runs a small script on a systemd timer that downloads whatever is new. S3 sits in the middle as a holding area.

Two hops, no direct connection

What we actually moved

The data was spread across five source locations. Three small folders belonged inside the web root. Two large trees stayed outside it and went to a staging area on the new server until the application's file paths were sorted out. Sizes were measured on the old server before we started.

Data volume by source folder

large archive tree

10.3 GB19,861 files

document store

3.7 GB15,430 files

import drop folder

276 MB709 files

result files

30 MB5,737 files

image folders

4 MB592 files

Why it works well

The strongest argument is what you do not have to set up. The rest follows from the fact that S3 is a durable, always-on middleman that both servers can reach on their own schedule.

The two hops overlap

The biggest objection is the double handling. In practice most of that cost disappears, because the pull job does not wait for the push to finish. The destination timer wakes every ten minutes, grabs whatever has arrived, and goes back to sleep. By the time the last file is uploaded, the new server is only one pull behind.

Upload and pull run side by side

The scheduled pull job

The pull side is a short shell script and a systemd timer on the new server. You install it once and it runs on its own, so nobody has to log in and start a download. The timer starts five minutes after boot and then fires every ten minutes. Each run syncs a handful of bucket prefixes into their final folders, fixes ownership, and writes one line to a log.

#!/bin/bash
# Runs from a systemd timer every 10 minutes. Never deletes local files.
set -uo pipefail
B=s3://example-migration-bucket
W=/data/www/example.com
export AWS_DEFAULT_REGION=us-west-1
rc=0
pull() { aws s3 sync "$1" "$2" --only-show-errors || rc=1; }

pull $B/webroot/data/folder-a/  $W/data/folder-a/
pull $B/archive/                /data/migration/archive/

chown -R 999 $W/data/folder-a      # 999 = the app's service user
echo "$(date '+%F %T') rc=$rc folder-a=$(find $W/data/folder-a -type f | wc -l)" \
  >> /var/log/migration-pull.log
exit $rc

# migration-pull.timer
[Timer]
OnBootSec=5min
OnUnitActiveSec=10min
[Install]
WantedBy=timers.target

Three habits are worth copying. The script remembers a failure in rc but keeps going, so one bad prefix does not block the others. It logs a file count for every run, which lets you watch progress and compare against your source numbers at cutover. And both unit descriptions say TEMPORARY, so nobody finds a stray timer on a production server a year later and wonders what it is.

S3 only lists an object after its upload has fully finished, so a pull that fires in the middle of a large upload cannot grab half a file. It simply picks up what has arrived since the last pass.

When you want it to delete too

Sometimes you want the new server to be an exact mirror of the old one. Add --delete and sync removes anything at the destination that no longer exists at the source.

What --delete changes

Why you would want that

• Counts that match. At cutover you compare file counts against what you measured on the source. Leftover files make that check fail, and then you have to explain every difference by hand.
• No ghost files. Applications that list a folder will show a renamed or removed file as if it were current. A report that was replaced on the old server can reappear on the new one.
• Retention and privacy. If records were purged at the source on purpose, such as expired documents, they should not live on in the new environment.
• Disk and backups. A copy that only grows keeps paying for data nobody wants, and every snapshot carries it forward.

How to do it

A deletion has to travel through both hops, so there are two switches. On the old server, --delete on the push removes bucket objects that no longer exist locally. On the new server, --delete on the pull removes local files that are no longer in the bucket. The upload-only IAM user cannot delete objects, so the push side also needs a temporary s3:DeleteObject grant for that one run. Preview each step first with --dryrun, which lists every deletion without performing it.

# 1. Old server: preview, then mirror removals into the bucket
aws s3 sync C:\data\archive s3://example-migration-bucket/archive/ --delete --dryrun --profile migrate

# 2. New server: preview, then mirror the bucket to disk
aws s3 sync s3://example-migration-bucket/archive/ /data/migration/archive/ --delete --dryrun
aws s3 sync s3://example-migration-bucket/archive/ /data/migration/archive/ --delete

A safe routine is short. Take a snapshot of the volume first. Run the dry run and read the list of deletions. Use --exclude to protect any folder the new server writes to. Then run the real pass once, as part of the final cutover sync, and compare counts afterward.

How it compares with the usual options

None of these methods is wrong. They suit different situations, and the table shows where each one is strong and where it costs you something.

Direct rsync or SFTP

One hop is faster than two, and rsync preserves permissions and timestamps. If both servers are Linux and can already reach each other, use it. Our source was Windows, rsync is not native there, and the owner of that box did not want an inbound path opened to it. Staging removed that conversation entirely.

Robocopy over a VPN

Robocopy is built in and handles interrupted copies well. It also wants a network path to the destination, which means a VPN or an SMB share reachable across the internet. That is real setup on both ends for a one-time job, and SMB exposed to the internet is a bad idea.

AWS DataSync

DataSync is the managed answer, with scheduling, verification and bandwidth controls built in. It also needs an agent running as a virtual machine close to the source, and it charges per gigabyte. For terabytes, or for a transfer that runs for months, that trade makes sense. For 14 GB and a Windows 2016 host with no hypervisor to spare, it was more machinery than the job deserved.

Guardrails we put around it

The pattern is only as safe as its permissions. These are the controls we apply, and they are cheap enough to copy every time.

• A dedicated IAM user with upload and list on one bucket, and nothing else.
• A condition that limits that user to the old server's outbound IP address.
• Public access blocked, server-side encryption on, and a bucket policy that rejects non-HTTPS requests.
• A lifecycle rule that expires objects 30 days after upload, so forgotten data cleans itself up.
• A read-only role on the destination, so the pull job cannot change the bucket.
• A pull script that never deletes locally and sets the correct owner on what it writes.

When I would pick something else

• Both servers are Linux and already share a network. Use rsync.
• You are moving terabytes, or need managed verification and reporting. Look at DataSync.
• Permissions and timestamps must be exact. Use rsync, or archive the tree first and move the archive.
• The data is a database. Use that database's own backup and restore tools, not a file copy.

The cutover checklist

The part people skip is the exit. A staging bucket should have a known end, and the same goes for the credentials around it.

1. Freeze writes on the old server, then run the final sync.
2. Wait for one more pull on the new server.
3. If you need an exact mirror, run the supervised --delete pass now, after a snapshot and a dry run.
4. Compare file counts per folder against the numbers you measured at the start.
5. Disable the pull timer and remove the service, timer and script.
6. Delete the upload IAM user and its key, the read policy on the instance role, and the bucket.
7. Remove the CLI profile and the AWS CLI from the old server.

The short version

S3 staging is not the fastest way to move files, and it does not copy permissions for you. What it gives you is a transfer that needs no new network paths, survives interruptions, repeats cheaply at cutover and leaves almost nothing behind when you remove it. For the typical small-business migration off a legacy server, that is usually the better set of trade-offs.

If you have a server that needs to move and no clean way to move it, get in touch with Tierney Dynamics.