A migration is a project, not a ticket.
A publisher's high-traffic platform, re-architected for scale, load-tested, and moved onto our bare metal. The customer-visible impact was a roughly five-minute window inside a two-hour operation.
In this article 4 sections
- A major publisher's group of high-traffic properties had to move datacenters onto our bare metal, re-architected for scale on the way. Breaking-news traffic is their business, and every reader would see a bad cutover.
- We designed the platform first: a two-tier edge cache on all-flash SAN, a load balancer tuned for very high connection counts, a read/write-split database tier, and an object-cache layer.
- Then we proved it under a full-scale load test, before a single real reader was moved.
- Cutover was a two-hour operation with a roughly five-minute customer-visible DNS window, every phase with a rollback path.
These are news and lifestyle sites where the traffic spike is the business. A migration that drops them, or brings them up slower, is visible to every reader in the middle of a breaking story. This was never going to be a ticket. It was a project with a cutover night.
Why one team for the whole job
The job needed two things at the same time, from one team: the engineering to re-architect the caching and database tiers, and the owned infrastructure (all-flash enterprise SAN, a real network fabric) to land it on. We brought the engineers and the metal together, and the cutover night was ours to carry.
The platform, as designed
The design intent was three things at once: re-architect for cache-and-database scale, cut over with a minimal bounded window, and carry every piece of the new design through the cutover intact. Here is what it became.
Two-tier Varnish edge cache
HAProxy in front
ProxySQL on each web node
Percona XtraDB cluster
Valkey + Sentinel
Deterministic beats elegant
The database moved by fresh hot backup rather than live replication catch-up. That was a design decision with a stated rationale: a backup is deterministic, so what is in the backup is what the new cluster has, with no replication state to untangle at the worst possible moment. The more elegant path exists, and we declined it on purpose. On cutover night, you want the move whose outcome you already know.
Moving the data fast meant relaying it in two hops: over the public internet to a staging relay, then across the internal LAN at line rate, turning a crypto-bound copy into a few minutes. On the destination, the cluster was rebuilt from the backup and re-synced node by node.
And a filesystem sync carried a surgical exclusion list so the migration could not clobber the new home's configuration: the database-pointer config, the object-cache drop-in, and the two-tier cache setup were all explicitly preserved. The one piece of state a database restore silently wipes, the cache-purge plugin's activation, was mapped in advance with its re-activation ready to fire. That is what designing the cutover twice means: once forward, and once for everything that could bite on the way.
The data, in two hops
Public internet to a staging relay, then the internal LAN at line rate. Minutes, not hours.
Cluster restored from the hot backup
Re-synced node by node.
Filesystem move, guarded
An exclusion list protects the new architecture from being clobbered.
DNS flips
The visible window: roughly five minutes.
The one silently-wiped setting, re-activated
On schedule, because it was mapped in advance.
“We didn't move your servers. We rebuilt your platform and landed it on ours, in a window of roughly five minutes, planned in advance.”
What the relationship became
The migration was the entry point, not the end. The sibling properties followed the same pattern, and the operational discipline came as part of the build rather than as a later upsell: frequent hot database backups and retained filesystem snapshots, edge caches tuned, a fleet-wide performance-monitoring layer onboarded, and load-testing validation before launch. The relationship settled into "we run and evolve the platform," not "we host it."
Straight answers
Can you migrate a high-traffic site without taking it down?+
We plan a bounded window and state it in advance. In this project: roughly five minutes of customer-visible DNS propagation inside a two-hour operation.
Backup-restore or replication for a database migration?+
Both are legitimate. We chose a fresh hot backup here because it is deterministic: what is in the backup is what the new cluster has, with no replication state to untangle mid-cutover. The elegant path is not always the safe one.
What should a migration rollback plan include?+
A rollback path on every phase, and a documented path back to the origin until the new platform has earned trust.
Do you re-architect during a migration or just move things?+
If the move is worth a project, it is usually worth the re-architecture. This platform gained a two-tier edge cache, a read/write-split database tier, and an object-cache layer on the way over. Lift-and-shift is sometimes right, but it is a decision, not a default.
Planning a move? Bring us the platform, not a ticket.
Design, load test, cutover playbook, rollback ropes. We'll tell you the honest window before the night, and we'll hold the net.
Talk to an engineerYou’ve reached the end.
Put the reading to work
What are
you running?
Tell us about the workload, traffic and recovery requirements. Start with the server builder, or talk through the details with an engineer.
Written by the engineers who build and run the infrastructure it describes.Talk to an engineer