Content migration off a hand-written CMS for a magazine publisher

The publisher's whole archive lived in a content system written in-house years earlier by a developer who had long gone. It worked, mostly, but it could not be patched safely, the editors had built elaborate habits around its bugs, and search engines had started treating half the archive as duplicates because of how it generated URLs. Advertising revenue depends on that archive being findable, so this was a commercial problem wearing a technical costume. They needed everything moved, every old URL still resolving, and the editors able to work on day one without a training programme.

Contract developer, about five months, working alongside one in-house developer and an editor who was given a day a week for the project. There was no product owner as such; the managing editor made the decisions and I learned to bring her two options rather than a question. I did the migration work and the redirect layer; the in-house developer did the new front end with me reviewing.

I owned the extraction and the mapping — reading the old database and its several generations of article shapes into one normalised model, including the years where formatting was stored as raw markup with a house convention nobody had documented. I wrote the redirect layer that maps every historic URL pattern to a new one, which meant reconstructing four different URL schemes from log files because the code that generated two of them had been deleted. I also owned the image pipeline, which sounds trivial and was three weeks, because half the archive referenced files by a path that no longer existed and had to be resolved by matching filenames and dates.

I chose to run the migration as a repeatable script against a copy rather than as a one-time move, and to re-run it fully every night for the last six weeks. It made the migration slower to write and meant we could keep publishing in the old system right up to the switch, which was the requirement that mattered. I also argued against cleaning up the old markup during migration — the editor wanted consistent formatting and I wanted a migration I could prove was lossless, so we moved everything as-is and did the cleanup afterwards as a separate, reversible pass. On the front end I pushed for rendering pages on the server and caching hard, because the audience is largely on slow mobile connections and the archive barely changes.

The magazine publishes weekly and there was never going to be a pause, so the old system stayed live and authoritative until the final switch. Search traffic is the business, so the redirect map had to be complete before anything went live, and we agreed a rollback trigger with the managing editor in advance: if organic sessions dropped more than a set amount over three days, we go back. Budget was tight enough that we did not build an editor migration tool — the editors moved their in-progress drafts by hand over one weekend, which was a decision made on cost rather than taste.

About ninety-one thousand articles moved with a checked sample showing no content loss, and the redirect layer covered every URL that had appeared in twelve months of logs. Organic traffic dipped for around ten days and then came back above where it started, which the editor tracked more closely than I did. Publishing an article went from a process with four known workarounds to one without them, and the editors stopped needing to ask the in-house developer to fix things in the database, which had been a weekly occurrence. The nightly re-run script was kept and is still used to test upgrades.

The editor who was given a day a week is the reason the mapping is right — she recognised article types by sight that I would have merged, and she wrote the acceptance list we checked against. The in-house developer built the front end and knew the audience's behaviour better than any analytics I could have read. An SEO consultant the publisher already used reviewed the redirect map before launch and found two patterns we had missed entirely.