Our First Local Client: A Zero-Downtime Data Migration

Position5 has taken on its first local client.

The work is a large data migration. The kind that exists not because someone wants a flashy rebuild, but because the current shape of the data has become the ceiling on what the site can do. Page loads have to come down. Functionality can’t change underneath users. The site has to stay live the whole time. No maintenance windows, no apology emails, no “we’ll be back in an hour.”

That’s the bar: faster, identical from the user’s perspective, and 100% uptime through the cutover.

Why the migration

When a site outgrows the assumptions it was built on, you usually see it in three places: query latency creeps up, the surface area of “small” changes grows, and the performance budget starts getting spent on things that aren’t features. The migration isn’t the goal here. The goal is room to grow. The migration is just the only honest way to get there.

So the first phase wasn’t writing code. It was reading the existing system carefully enough to make a faithful copy. Every endpoint, every query, every quirky behavior users have learned to expect. If we don’t know it exists, we can’t preserve it.

How we’re handling uptime

Zero-downtime data migrations aren’t a single trick. They’re a discipline applied across the whole cutover:

• Dual-write before cut. New writes go to both the old and the new system, in parallel. That keeps the new system live and current without flipping anyone over to it yet.
• Backfill the past. Historical data gets migrated in the background, batched, with verification at every step. The old system stays authoritative until the new one demonstrably matches it.
• Read shadow. Read traffic gets mirrored to the new system before any user sees its response. We compare results, log mismatches, and chase down every discrepancy before flipping a switch.
• Gradual cutover. Real traffic moves over a slice at a time, with the old system still warm and one config flag away from being the source of truth again.
• No big-bang. If something goes wrong, we don’t roll back a migration. We roll back a flag.

None of this is novel. All of it is the difference between a migration that ships and a migration that gets postponed every quarter because nobody wants to be the one to schedule the downtime.

What this means for Position5

This is also a milestone for the studio. We’ve talked about working with local businesses for a while. Now we’re actually doing it — and doing it on the kind of problem that’s exactly what we set up Position5 to handle. Hard engineering work, scoped tightly, with the same care we’d give one of our own products.

We’ll have more to share as the cutover proceeds. The client’s name and details are theirs to share if and when they want to. For now, the work speaks for itself: a faster site, the same experience users already know, and a database underneath that’s ready for whatever they want to build next.

If you’ve got a migration or performance problem of your own that you’ve been quietly putting off, we should talk.