Skip to content
Atomic WaxBook an AssessmentBook

← Field Notes

How we moved kpixies.com to a new platform without a flag day

Peter Benes ·

kpixies.com is our performance-based Google Ads program for single-store retailers. Until August it ran as a static Astro site on Cloudflare Pages. It now runs on EmDash, a CMS built on Astro, on Cloudflare Workers with D1 for content and R2 for media. This note covers why we moved it and how the live site kept serving the whole time.

Why rebuild a site that worked

The site loaded fine. The problem was somewhere else. The copy had not been touched since June 17, and the reason was obvious once we said it out loud: changing a sentence meant a developer, a repo and a deploy. An update path existed. Nobody was using it.

That was the failure we were fixing. EmDash gives the site an admin screen where copy can be edited without opening a code editor. The admin was the point of the rebuild, not a side benefit.

The cost, stated plainly

For a six-page marketing site, EmDash loses on simplicity and on serving cost. A static site is about as simple and cheap as the web gets. We wrote that down before we started.

We chose it anyway because kpixies was the only site in our estate on a different stack. Every exception is a second way of doing things: a second set of checks, a second deploy path, a second list of gotchas to remember. One stack across every site is worth more than a small saving on one of them.

Moving from static files to per-request rendering created a risk we had to name, which was speed. So edge caching became a launch requirement, not an optimization for later. The rule we set: a marketing site that got slower by replatforming would be a failed build regardless of its conformance score.

Two truths during the build

Rebuilding a live site is different from building a new one. During the build there are two versions of the truth, and both matter.

The daily probe keeps measuring the old site, because that is what customers and Google are seeing. A separate preview gate measures the new build before it goes anywhere near the real domain. On August 8 we made this a named variant of the Atomic Wax process, so our registry holds both results side by side instead of letting one overwrite the other.

In this variant, deploy does not mean pushing code. It means a DNS and route flip, and that belongs to one person. Peter makes it. Agents build and verify; they never touch DNS. The old platform stays parked and untouched until the new site has held up in production. If something goes wrong, the way back is to point the domain at the old project again.

Port from the wire, not the repo

We froze the old repository as a historical reference and ported the content from the live site instead. Whatever the repo said, the live pages were what customers had read and what search engines had indexed. Taking content from the wire meant we migrated what was real, not what someone once intended to ship.

Less bookkeeping than expected

Before the rebuild, kpixies sat in our queue as a site to patch on its old stack, with a list of open items against it. Once we decided to rebuild instead, that list did not need closing by hand. Our status is derived from probing the live site, so the open items close themselves on the day the rebuilt site serves. Nobody has to remember to tick a box, and nobody can tick one early.

What we would tell anyone planning a move

The temptation in a replatform is to treat cutover day as one dramatic moment. It works better as a boring one. Build alongside, measure both, flip a pointer, keep the old site warm.

The other lesson is to be clear about why you are moving. We did not rebuild kpixies.com to make it faster or prettier. We rebuilt it because the people who should have been updating it couldn’t. If you can name the failure, you can tell afterwards whether the rebuild fixed it.

What this means if you hire us

This is the same pattern The Deal puts in writing: your site stays live while we build, and moving over is a reversible switch, not a weekend outage. You end up with a site you can edit yourself, which is the whole idea behind sites that run themselves. The steps are laid out in how it works.