Azure to AWS Migration: Moving From Network File Shares to S3 + Glacier

When a company decides to move from Azure to AWS, the pitch they usually hear is "lift and shift" — rehost the VMs, repoint the DNS, done. The most expensive mistake in that plan is invisible: it carries the network-mapped file system across to the new cloud unchanged. You rehost the file server, remount the drives, and move your storage bill from one cloud to the other without changing its shape at all.

The migration is the rare, funded moment when you can actually fix that. Done right, the same project that moves you to AWS also collapses your storage cost and shrinks your security surface.

The network-file-share tax

Plenty of applications were written to read and write files the old way: a mapped drive (Z:\), an SMB/CIFS share, an NFS mount, a file-server VM, or a premium managed file share. That architecture quietly taxes you three ways:

• You pay for provisioned capacity, not usage — the share is sized for the peak you might hit, and billed whether the space is used or not, on an always-on, often premium tier.
• It doesn't scale or heal like the cloud should — a file server is a single point of failure with its own patching, backups, and capacity ceilings.
• It's a broad security surface — open shares and mounted drives are exactly the lateral-movement path attackers look for.

In fintech especially, the biggest volume is documents: KYC files, signed agreements, statements, disbursement proofs, audit exports — written once, read rarely, and kept for years to satisfy regulators. Parking all of that on hot file shares is the single most common storage-cost mistake I see.

Why S3 + lifecycle to Glacier wins

Object storage is a fundamentally better fit for that workload:

• Pay only for what you store, with eleven nines of durability and effectively unlimited scale — and no server to run or patch.
• Lifecycle policies move data automatically by age and access: S3 Standard → Standard-IA → Glacier Instant/Flexible Retrieval → Glacier Deep Archive. Cold compliance documents settle onto Deep Archive at a tiny fraction of hot-share cost, with zero manual work.
• A smaller, controllable security surface — private buckets, encryption on by default, access through IAM and short-lived pre-signed URLs, reached over private VPC endpoints instead of an open network mount.

The part that goes wrong: POSIX ≠ object

This is why naive lift-and-shift of storage fails. Code written for a file system assumes things object storage doesn't offer: in-place updates, directory listing, file locking, random seek. Object storage gives you immutable objects addressed by key — no locking, no partial overwrite. Point the old code at a bucket and it breaks in subtle, production-only ways.

Doing it right means choosing, per application, between two honest paths:

• Refactor the data-access layer — metadata and the file index live in the database, the bytes live as S3 objects keyed by ID, large files upload via multipart, and downloads are served through pre-signed URLs. This is the durable end state.
• Bridge first, refactor later — put a translation layer in front (AWS S3 File Gateway, or Mountpoint for Amazon S3) so legacy code keeps its file interface while the data actually lives in S3. It buys you the cost win immediately and lets you refactor incrementally.

The classification step is not optional: Deep Archive restores take hours, so anything that must be read instantly stays on S3 or Glacier Instant, and only genuinely cold data goes to Deep Archive.

The migration playbook

• Inventory & classify every dataset as hot / warm / cold by access pattern and retention requirement.
• Design the target — bucket layout, key schema, lifecycle rules, encryption, and the access model — as Terraform, so it's reproducible and auditable.
• Pick a per-app strategy — refactor to the SDK, or bridge with a gateway — based on how the app actually uses files.
• Move the data with a managed transfer service, watching Azure egress charges (they're real, and they're a line item in every cross-cloud move), and verify with checksums.
• Cut over via dual-write or backfill-then-switch, validate reads and retrievals, then decommission the file server.
• Prove it — a cost dashboard, retrieval tests against each tier, and an audit trail that stands up in an exam.

The same principle on every cloud

This isn't an AWS-only idea — the pattern is identical everywhere; only the implementation differs. On Azure it's Blob with Cool and Archive tiers; on Google Cloud it's Cloud Storage with Coldline and Archive. Knowing the right way to do it on each cloud — the retrieval SLAs, the lifecycle rules, the security defaults, the egress traps — is exactly the expertise that turns a scary migration into a routine one.

Why partnering gets it done in a fraction of the time

Every hard part above — the POSIX-to-object gap, retrieval-SLA classification, egress cost, secure-by-default buckets, a clean cutover — is where teams doing this for the first time burn months. We've done it across AWS, Azure and GCP, so we bring a reference architecture, Terraform modules, and the migration tooling with us. You skip the discovery phase entirely.

The result a client gets by partnering with us isn't just "it moved." It's the storage re-architected the right way for their cloud, the bill cut sharply, and the whole thing delivered in weeks instead of quarters — with the cost savings and audit-ready controls to show for it.