Six-week migration of 58 TB with a four-hour cutover, plus an over-budget run rate

Do the arithmetic before choosing anything. 58 TB is 58 × 8 × 10^12 = 4.64 × 10^14 bits. At a theoretical 100 Mbps that is 4.64 × 10^6 seconds, about 54 days - before any overhead. IPsec and TCP over a WAN realistically deliver 60–70% of line rate, so plan on 75–90 days. The requirement is six weeks. The VPN cannot do this, full stop; no amount of tuning closes a 2× gap.

A 1 Gbps dedicated line moves the same volume in about 5.4 days at line rate, or roughly 8–9 days at realistic efficiency. That fits inside six weeks even with a three-week provisioning lead time: order the line on day one, use the wait to build the landing zone, and you still have about two and a half weeks of transfer window.

Additional levers, because 8–9 days is comfortable but not free.

• Compression. The file share compresses about 2.5:1, so 40 TB becomes roughly 16 TB on the wire if you compress before transfer. Do not compress PDFs twice expecting more; the stated ratio already accounts for them.
• Parallelism. A single TCP stream will not fill 1 Gbps; use many parallel streams or a multipart upload tool that does.
• Shape of the work. Database first over the dedicated line while it is quiet, then documents, then the delta catch-up.

Keep the VPN. It stays as the management and break-glass path and as a control-plane backup, but it is not the bulk pipe. Do not run bulk transfer over the VPN during the same weeks you need it as a fallback.

The four-hour window is not for moving 58 TB. Bulk data must already be in the cloud before the window; the window is only for the final delta and the switch. If anyone plans to copy the file share on Saturday night, the plan fails.

Cutover design.

1. Continuous replication before the window. Seed the target database from a full export, then run ongoing change replication from the source so the target tracks the source with seconds of lag. The 18 TB database is loaded and validated days earlier.
2. Pre-stage documents. Sync the file share, then run repeated incremental passes; on the night, only new or changed files move, and a final checksum pass proves completeness.
3. In the window (target timeline for a 4-hour budget): put the application into read-only or drain mode (about 20 minutes) → confirm replication lag reaches zero and the last change is applied (about 15 minutes) → validate the top 20 tables by row count and checksum, and spot-check document counts by prefix (about 45 minutes) → switch the connection string and DNS, with a low TTL prepared in advance (about 30 minutes) → run smoke tests and open for writes (about 30 minutes). That is roughly 2.5 hours, leaving buffer for the unexpected.
4. Rollback must exist for 48 hours. Keep the source writable and run reverse replication from cloud back to source, so if validation fails at hour three you repoint and resume on-premises with no data loss. Reversibility is what makes the four-hour window safe rather than optimistic.

Rehearse twice. Dry-run the full sequence with a timed stopwatch, including the validation queries and the DNS change, on the real topology. Cutovers fail on the twenty small steps nobody timed, not on the big ones.

Split the overrun into structural and behavioural causes, because the fixes differ.

Structural (the business case was probably wrong). NAT Gateway is billed for existing plus data processed, and every private-subnet workload that talks to the internet flows through it - outbound image pulls, package installs, and API calls add up in ways per-server estimates miss. That is a design cost, reduced by scoping routes to only the subnets that need egress and by keeping traffic inside the VPC where possible.

Behavioural (nobody is watching). Unattached public IPs, three idle load balancers, and forgotten development environments are not architecture, they are housekeeping. These are free to fix: find resources with no traffic or no attachment, confirm with the owning team, and release them. A weekly report of untagged and zero-traffic resources is worth more than any purchasing discount.

Migration-specific costs to plan for explicitly. The dedicated line carries a fixed monthly port fee and becomes waste the day after cutover if nobody cancels it - put the cancellation date in the plan with an owner. Running source and target in parallel for six weeks doubles some run rate; that is legitimate and temporary, and should be shown as a migration cost rather than hidden in steady-state.

Reductions I would take, in order.

1. Release unattached IPs and idle load balancers - immediate, no risk.
2. Scope NAT egress by subnet and reduce outbound volume.
3. Right-size servers from observed utilization, not peak-plus-headroom guesses.
4. Put genuinely steady-state workloads on an annual commitment to capture the contract discount; do not commit to anything still being re-architected.

What I would not do. Cutting monitoring, backups, or the second availability zone to hit a number. Those savings are repaid with interest in the first incident. The honest framing to management: roughly half the gap is a fixed design choice, the other half is hygiene and right-sizing.