Every Drupal redesign has a moment when the content stops being a living thing and becomes cargo — something to be lifted from the old site and set down on the new one intact. That moment is the content freeze, and it is where redesign schedules go to die, because teams treat it as a switch (“as of Monday, nobody edits anything”) instead of what it actually is: a staged plan with windows, exceptions, and an end. Freeze everything too early and your editors sit idle for a quarter while the business moves on without its website. Freeze too late — or not at all — and you migrate a moving target, discovering on launch day that half the URLs changed after the redirect map was built. This article gives you the staged approach that avoids both failures: how to sequence freeze windows, what stays editable when, how to set the migration cutoff, and how to communicate it all so editors feel informed rather than handcuffed. The freeze only works if the content model underneath it has been cleaned up first, which is the job of cleaning up the content model before a redesign; the editor-side verification of frozen-then-migrated content connects directly to content preview before launch; and the freeze formally ends in the post-launch checklist.
One framing rule before the stages: a content freeze is a business decision wearing a technical costume. The dates exist to protect content integrity, but they are chosen to hurt the business as little as possible — every window below is a trade, not a lockdown.
Why A Hard Freeze Fails Almost Every Time
The hard freeze — “no content changes from kickoff to launch” — fails for reasons that are obvious in retrospect and invisible in the project plan. The business does not pause: prices change, staff leave, a regulator updates a requirement, and three weeks into the freeze someone edits a page anyway because the alternative was publishing something wrong on the live site. Now the migration source is stale in a way nobody tracked, and the team discovers it during QA, which is the most expensive possible time. The deeper problem is that a hard freeze treats all content as equal when it is not. A pricing page and a ten-year-old blog post have completely different risk profiles if edited mid-migration: one breaks the business if it is wrong, the other breaks nothing. The staged approach exists because it can tell the difference. It also respects a psychological fact about editors: people respect windows they helped set and sabotage windows that were imposed on them. Inviting the editorial team into the freeze planning — showing them the migration mechanics that make late edits dangerous — converts them from freeze victims into freeze custodians, which is worth more than any lock on the CMS.
The Staged Freeze Windows That Actually Work
The working pattern is three windows, each with a different rule set, announced together at project kickoff so nobody is surprised later. The table below is the standard sequence for a mid-size Drupal redesign; adjust the durations to your migration method, but keep the logic — progressively narrower permissions with a published exceptions path.
Notice what each stage protects. The soft freeze protects the migration source from silent drift while keeping the business editable where it matters. The hard window exists only as long as the actual migration run — days, not months — because its cost is real and should be paid for as short a time as possible. And the exception path is not a weakness in the plan; it is the plan. An editor who knows a pricing fix can go live in twenty-four hours through a named contact will use that path instead of editing behind the freeze. When you present this to the editorial team, present the exception path first — it is the part that tells them the freeze was designed by people who understand their job.
Setting The Migration Cutoff And Redirect Map Date
Two technical artifacts depend on freeze discipline, and both are unforgiving. The first is the migration cutoff: the moment the content snapshot used for the migration run is taken. Every edit made after the cutoff on the old site is content the new site will not have unless it is carried over manually — so the cutoff and the launch date together define a reconciliation backlog, and that backlog must be estimated, not discovered. The official Drupal migration documentation describes the same snapshot discipline in tooling terms: migrations run from a defined source state, and drift after that state is a reconciliation problem by definition. The rule of thumb: the gap between cutoff and launch should be short enough that the backlog is a known list a person can work through in days. The second artifact is the redirect map, which maps every old URL to its new destination. It is built from the old site’s URL list at a specific date; edits after that date create new URLs nobody mapped, and unmapped URLs become 404s on launch day. So the redirect map date should be after the soft freeze begins — when URL churn has slowed — and any URL created after it must go into the map manually through the same exceptions path. Neither artifact tolerates optimism. Build both from a dated snapshot, record the dates in the project plan, and treat any content edited after its date as a reconciliation task with an owner, not as a vague risk.
Communicating The Freeze So Editors Cooperate
The best freeze plan fails silently if communication treats editors as an afterthought. The announcement needs four parts, and it needs to go out before anyone hits a wall. First, the why, in one honest paragraph: edits made between the cutoff and launch must be manually reconciled, and the team is asking for windows so that work stays small. Editors who understand the mechanics stop experiencing the freeze as bureaucracy. Second, the calendar: the three windows with their exact dates and rules, posted where the team actually looks — not in a project tool only the developers open. Third, the exceptions path with a named human and a response-time promise; a freeze without a visible escape hatch gets treated like a suggestion. Fourth, the checklist of what each editor should do before their areas freeze: finish in-flight drafts, resolve pending revisions, and flag content they know will need updating during the window. That last part is the quiet miracle of a well-communicated freeze — editors do the pre-freeze tidy-up themselves when they can see the calendar, and the migration source arrives cleaner than any audit would have made it.
Unfreezing: The First Week Back To Normal Editing
Teams plan the freeze and forget the unfreeze, which is how sites end up locked “temporarily” for a quarter. Before launch, schedule the unfreeze as an event with the same visibility as the freeze itself: a date, an owner, and a short checklist. The checklist has four items. Reopen editorial permissions per role, in the reverse order they were narrowed. Reconcile the carryover backlog — the edits made during the hard window that the migration did not include — and confirm with each editor that their urgent changes landed. Retire the old site’s editing access in a controlled way so nobody fixes something in the wrong place out of habit. And run the first week under a light-touch watch: new content published into the new theme sometimes exposes layout or field issues that QA missed, and catching them in week one is cheap. This closing phase connects directly to the broader the post-launch checklist, which covers everything beyond content. A freeze with a planned ending is a tool; a freeze without one is a slow accident. Plan the unfreeze on day one and the whole mechanism stays trustworthy — which matters, because there will be a next redesign, and the editors’ memory of this one decides how the next freeze goes.
Publish the window dates where the whole team can see them, name the exceptions contact, and treat the unfreeze date as part of the freeze plan from the very first draft of the schedule.