I helped build the canada.com launch, and it was tied to going live on Canada Day. That date was not moving. Marrying several legacy systems into a single WordPress VIP launch against a fixed national holiday was, to put it kindly, chaotic.
The lesson stuck, and it’s the reason I now scope a newsroom migration around the hard date first and the feature wishlist second. Three things run long on every news migration I’ve worked on: the cutover is more redirect-heavy than anyone scoped, the archive is larger than anyone scoped, and the newsroom needs more training than anyone scoped. All three are visible during a scoping conversation. None of them are visible in a demo.
If you run a marketing site that publishes monthly, none of this applies to you and you can close the tab with my blessing. This is for editorial operations leads at news properties working toward a date that genuinely cannot move: an election, budget day, a parliamentary return, a print partner’s deadline, or a launch somebody has already sold sponsorship against.
Why newsroom migrations miss dates
Not because anyone underestimated the content move. The content move is the part everyone plans for, and it usually lands roughly where it was supposed to.
Dates get missed because the three things above compound at exactly the same moment. They all surface during cutover week, they all need the same two or three people, and each one individually looks like a couple of days of work. Together they’re a fortnight, and cutover week doesn’t have a fortnight in it.
The fix is to move each of those three discoveries much earlier, to a point in the schedule where finding a problem is inconvenient rather than fatal. Heroics in the final week are what a failed schedule feels like from the inside. That’s what the three checkpoints do. Each one is deliberately scheduled to fail early, while failing is still cheap.
Checkpoint one: redirect coverage
Audit every URL pattern in production and map each one to the new structure with a deliberate redirect plan. Not a sample. Every pattern, including the ones from the platform you were on two platforms ago, because a news archive accumulates URL formats the way a house accumulates paint colours.
Then test it at least four weeks out, against real inspection rather than against a spreadsheet. A redirect map that looks complete in a spreadsheet and one that holds up when something actually crawls it are two different artifacts, and the gap between them is where launch dates go to die.
Testing means pulling real URLs through Google’s URL Inspection tool and reading what it reports back, rather than trusting the mapping document. Take a sample from every era of the archive, include the formats you inherited from older systems, and check that each one lands where the plan says it should. The failures cluster in the oldest patterns, which are also the ones least likely to have been tested by anyone building the new site.
Four weeks is the number because it’s the runway you need to find the gaps and still have time to close them. At two weeks you’ll find the same gaps and ship anyway. For a news property the stakes are higher than for most sites, because your archive is cited by other journalists, linked from research, and referenced in documents you’ll never see. It’s the same requirement I write about in the Drupal migration post, where a national paper’s archive made URL preservation non-negotiable.
Checkpoint two: archive integrity
Migrate a representative slice first. Roughly a tenth of the archive, spread deliberately across every year rather than taken from the top, and validate it completely before scaling to the full set.
Spread across every year is the part people skip, and it’s the part that matters. A news archive changes shape over time. The 2009 articles came out of a different CMS than the 2019 ones, the photo handling changed at some point, someone ran a bulk edit in 2015 that left a signature on everything it touched. Sampling the recent stuff tells you the recent stuff is fine.
The reshape problems always appear. The question is only whether they appear on a sample you can throw away, or on the production set the night before launch. I’d rather find them on something disposable, which is why this checkpoint exists at all.
Checkpoint three: editorial parity
A week before cutover, run a full production rehearsal. The team publishes an entire real day’s work in the new system, start to finish, on deadline.
If they can’t get the day out, you aren’t ready. That’s a hard sentence to hear seven days from launch and a much harder one to discover on launch morning, which is the whole argument for doing it. The technology being ready and the newsroom being ready are two separate milestones, and only one of them shows up on a project plan.
What this rehearsal surfaces is rarely a bug. More often it’s the photo desk’s crop workflow taking three times as long, or the wire feed landing somewhere nobody expected, or the one editor who does the evening pass discovering their entire routine was built on a feature that didn’t come across. Those are all fixable in a week. None of them are fixable in a morning.
What a missed date actually costs
Work this out for your own property rather than taking anyone’s percentage, mine included.
The arithmetic is simple enough. An election, a budget, or a parliamentary return is one of the highest-traffic weeks your property gets all year. It’s a week where advertising is sold ahead against expected audience, where new readers arrive who might stay, and where your competitors are publishing whether you are or not. A migration that lands badly during that week doesn’t just cost you the week’s revenue. It costs you the audience that came looking and found something broken.
Put a number on that for your own newsroom and compare it against the migration budget. For most news properties I’ve worked with, the number for one bad week is larger than the entire project. That’s the comparison that justifies the three checkpoints, and it’s usually the one that gets a rehearsal onto the schedule when the schedule is already tight.
The dates that do not move
Build the calendar backward from the immovable dates rather than forward from the kickoff. For most Canadian news properties that means the election periods, the federal and provincial budget days, the parliamentary return, and whatever local civic cycle your audience actually cares about.
One thing worth raising early rather than late: if your property holds a broadcast licence, election-period coverage may carry obligations that a purely digital publisher doesn’t have, and those obligations can interact with what you’re allowed to change and when. I’m not your compliance advisor and I won’t pretend to be. What I will do is ask the question during scoping, because the answer occasionally moves a launch date, and it’s much better to learn that in week one than in week ten.
When moving the date is the right call
Sometimes the honest answer is that the date is wrong, and saying so is part of the job.
Move it if the redirect audit at four weeks shows gaps you can’t close in the time left. Move it if the archive sample surfaces a reshape problem that needs a rethink rather than a fix. Move it if the production rehearsal fails and the reasons are structural rather than a matter of practice.
All three of those are findings the checkpoints are designed to produce while moving the date is still possible. A date moved in week six is a scheduling conversation. The same date moved in week eleven is a crisis with an audience watching.
Common questions about newsroom migrations
How long does a newsroom migration take? Longer than the content move suggests, because the archive, the redirects and the newsroom training set the pace rather than the article count. Let the three checkpoints sit on the calendar first and build the rest of the schedule around them. If you’d like a realistic timeline for your own property, tell me what you’re running.
Can we migrate during an election period? You can, and I’d rather you didn’t. There’s no technical barrier, but you’d be spending your highest-attention week of the year on a system nobody has muscle memory for yet. If the timing genuinely can’t be avoided, move the cutover to the quietest hour of the quietest day inside that period and staff it properly.
What about the archive we never look at? It still needs redirects, even if nobody on staff has opened a 2011 article this decade. Your archive’s value sits in the citations, the inbound links, and the search visibility it has quietly accumulated over the years, rather than in your own traffic reports. All of that runs through the URLs.
Do we need to move everything before launch? Not always. On a very large archive it’s often calmer to launch with the recent years fully migrated and the deep archive served through redirects while it finishes, provided the redirect layer is genuinely solid. That’s a decision to make deliberately during scoping rather than to arrive at in week ten because the archive ran long.
Leave a reply