October 28, 2026 SEO

Starting a Domain Migration in Q4? Finish It Before the Freeze

Planning a Q4 domain migration? Google needs the whole move live to transfer signals. Finish your redirects and Change of Address before the year-end deploy freeze.

Dark editorial graphic titled Starting a Domain Migration in Q4? Finish It Before the Freeze on howardcreativeco.com

If a year-end deploy freeze is on your calendar, do not start a domain migration you cannot finish before it locks. Google needs the whole move live and crawlable to transfer ranking signals, and a migration that freezes half-done sits broken through your highest-intent weeks of the year.

The short version

  • A domain migration is not finished on launch day. It is finished when Googlebot has recrawled every old and new URL, which takes weeks.
  • A deploy freeze that starts mid-migration locks your redirects, DNS, and server config in whatever state they are in, usually incomplete.
  • Google's Change of Address tool forwards signals for 180 days, and your redirects should stay live for at least a year.
  • The two safe calls are finish the whole move before the freeze, or wait until January. Straddling the freeze is the expensive option.

A migration is a crawl window, not a launch date

The risk in a domain move is not launch day, it is the weeks of crawling that follow it. Google is explicit that a move is only complete once Googlebot has visited every URL on your old and new site at least once, and that for a medium-sized site it can take a few weeks or more before the new URLs show up in search. So the window where something can quietly go wrong, a redirect returning the wrong status code, a deep page that 404s, a canonical still pointing back at the old domain, stays open long after the team has moved on to the next sprint. If that window overlaps a freeze, you cannot touch anything inside it.

A freeze turns an unfinished migration into a six-week outage

A deploy freeze does not pause a migration. It photographs it. Whatever is shipped when the lock comes down is what you live with until it lifts. If ninety percent of your redirect map is live and the last ten percent is still sitting in a pull request, and that last ten percent is almost always the long tail of deep pages that carry the inbound links worth keeping, those pages keep 404ing or hitting a homepage catch-all for the entire length of the freeze. The Change of Address request may be in or it may not. A bad canonical keeps pointing at a dead URL. None of it can be fixed.

I am in the middle of a SaaS domain consolidation right now, folding one established brand's site into another after a merger. The redirect map alone runs to thousands of URLs, and the deep pages, the ones with the links actually worth preserving, are always the last to get mapped because they are the ones nobody remembers exist. That is exactly the work a freeze catches unfinished. You do not want a four-thousand-line redirect file eighty percent applied when engineering locks the repository for six weeks. On a Webflow Enterprise build the redirect rules and the published branch are inside the same freeze, so a redirect you forgot ships in January or not at all.

Do the cutoff math backwards from the freeze date

Pick your migration date by counting backwards from the freeze, not forward from today. Start with the date the repository and DNS lock. Subtract Google's crawl window, a few weeks for a small to medium site and longer for a large one, because you want the move substantially processed and not just shipped before you lose the ability to patch it. Subtract a buffer for the problems your monitoring will surface in week one, because there are always problems in week one. What is left is your real launch cutoff. If that cutoff has already passed, the honest answer is to wait until the freeze lifts. Google's own timing guidance points the same way: it recommends you time your move to coincide with lower traffic, and for most businesses the weeks around a year-end freeze are the opposite of low traffic. Which URLs you map first is its own decision, and I score pages before a migration so the ones carrying real equity are never the ones left in the pull request.

Redirects and Change of Address run on their own clocks

Two separate clocks start the day you migrate, and both outlast the freeze. Use permanent redirects: Google states plainly that 301 and other permanent redirects don't cause a loss in PageRank, and recommends 301 or 308 sent straight to the final URL with no chains. Keep them up a long time. The site-move documentation says to keep the redirects for as long as possible, generally at least one year. The Change of Address tool in Search Console is the second clock. It needs both the old and new properties verified under the same Google account, it forwards signals and prioritizes the new site for 180 days, and Google tells you to keep the redirects in place for at least that 180 days, longer if the old URLs still pull traffic. Submit it for every verified variant of the old domain, www and non-www and any subdomains, including the ones you assume are unused. None of this is work you want to be starting, or discovering you forgot, during a freeze.

What to ship before the freeze, specifically

If you are going to beat the freeze, five things have to be live and verified, not merely merged. The full redirect map applied in production and spot-checked for status codes, not just the top twenty pages. The Change of Address request submitted and confirmed for all old-domain variants. XML sitemaps for the new URLs submitted, so Google has a discovery path that does not depend on recrawling the old site. Canonical tags on the new pages pointing to themselves rather than back to the old domain. And monitoring you will actually watch, Search Console coverage and your server logs for 404 spikes, because during a freeze the only thing you can do about a problem is see it coming. If any of those five cannot be done before the lock, you do not have a pre-freeze migration. You have a January migration that happens to start in November.

What this does not cover

This is about moving to a different domain or subdomain, the kind of move that needs redirects and a Change of Address. It does not cover restructuring URLs inside the same domain, moving from HTTP to HTTPS, or switching between www and non-www, none of which use the Change of Address tool. It does not cover the content and QA side of a migration, the parity checks and template testing, which need their own runway. And it assumes you already have a redirect map. If you do not yet know which old URLs matter enough to map, that work comes first, and a replatform checklist is a better starting point than this.

Can I run a domain migration during a code freeze?

Technically the migration keeps processing, because Googlebot does not care about your freeze, but you lose the ability to fix anything that breaks. Since the first weeks after a move are exactly when problems surface, a freeze is the worst possible time to be blind to them. If the move is already live and clean before the freeze starts, the freeze is fine. Starting one into a freeze is the mistake.

How long do I have to keep the old redirects?

At least 180 days to cover the Change of Address forwarding window, and Google's broader guidance is to keep them for at least a year, longer if the old URLs still earn search traffic. In practice, on a consolidation, I leave them permanently. The cost of keeping a redirect rule is close to zero, and the cost of removing one that still carries link equity is a ranking drop you will spend a quarter recovering from.

When is it too late to start a migration before year-end?

Count backwards from your freeze date: subtract a few weeks for Google to process a small to medium move, longer for a large one, plus about a week of buffer for first-week fixes. If today is already past that cutoff, start in January instead. A clean migration in a quiet January beats a rushed one that freezes half-done in December, every time.

Does a deploy freeze hurt rankings by itself?

No. A freeze on a stable, fully migrated site does nothing to rankings. The damage comes only when the freeze preserves a broken or incomplete state, unmapped redirects, a missing Change of Address, a bad canonical, and holds it there for weeks. The freeze is not the problem. An unfinished migration under a freeze is.

If you are looking at a Q4 domain migration and a freeze date on the same calendar, I will map your redirect cutoff against your freeze window on a 20-minute call and tell you honestly whether to ship it now or wait for January.