SaaS Migration Planning: Scope, Baselines, Owners and Risk

Planning decides three things the later phases cannot recover: what is actually changing, what the site looked like before it changed, and who is allowed to say yes. The baseline is the one with a deadline - several of the measurements you will want after launch stop being available while the old site is still up.

Two labels mark evidence boundaries on this page. Documented means the guidance that follows is directly supported by Google's own published documentation, quoted. Recommendation means a threshold, workflow, ownership model or pass rule that we prescribe and the documentation does not. Statements from Google staff in interviews or podcasts are attributed in the prose rather than tagged - they are first-party, but they are not documentation. Untagged text is ordinary explanation or a conclusion following from something already labelled.

Step 1: Define the Migration Precisely

Start from the classification in the pillar checklist and fill in what changes and what stays stable. The output that determines the most downstream work is a written answer to one question: are user-visible URLs changing? Google's guidance splits on that line, and so does the work.

Recommendation Treat "the URLs aren't changing" as a claim to verify against the inventory rather than a premise. Confirming it costs a crawl; assuming it costs a migration.

Separating the Changes

Documented Google: Plan your changes to your site one after the other, not everything at the same time. For example, if you want to move your site to a new domain name, change your content management system (CMS), and update your site to use a new layout, do them one at a time.

Google's team has given two different reasons for that, and they persuade different audiences:

• Error surface - Gary Illyes: with site moves, the smaller pieces you can break it into, especially if it's some complex stuff, the safer it is for you, and the more steps you introduce, the more potential errors you also introduce.
• Attribution - John Mueller: If you need to do both, I'd try to split it time-wise so that you can recognize any negative effects in each part, and take action to improve them. If you do everything at once, you'll never know what to fix, and even if things end up "same as before", you won't know if one part went down, and was compensated by an improvement on the other part.

The second argument tends to land better with a product team, because it is not a claim about risk appetite - it is a claim about whether anyone will be able to diagnose the result.

Phasing, by Site Size

Documented Google gives a size-dependent recommendation. Under the label "Small or medium sites": We recommend moving all URLs on your site simultaneously instead of moving one section at a time. Under "Large sites": You can choose to move larger sites one section at a time.

Google does not define the size boundary, so make the call on operational grounds - how much of the map you can meaningfully test in one window, and whether you can hold a rollback decision open across several releases - and record the reasoning where the decision can be found later.

If You Are Consolidating Several Domains

Documented Google: Try not to combine multiple moves to a single location. Moving sites A, B, and C all to new location D can cause some confusion and traffic loss. Its suggested approach: You might want to move sites one at a time to the new, combined location and wait till traffic stabilizes before moving the next site.

Note the hedging - "try not to" and "you might want to", not a prohibition. Stage the sources where it is practical. Where constraints require simultaneous moves, document the additional risk explicitly rather than absorbing it silently, and define what "stabilized" means before you start, or the second move never gets scheduled.

Step 2: Destination Due Diligence

Only relevant if you are moving to a domain you did not previously own - but it is cheap, and it can invalidate the destination before anything is built.

Documented Google's preparation guidance has a bullet for exactly this, labeled "Clean up your recently purchased domain," and it names two Search Console checks that a look at the site's history cannot substitute for:

• Manual actions. If there are any manual actions applied to the new site, address any problems listed there and file a reconsideration request.
• Removed URLs. Make sure that there aren't any URL removals left over from the previous owner, especially a site-wide URL removal.

Separately, and not from the documentation: John Mueller, speaking on Google's own podcast in February 2023, describes moving to a used domain name that has weird history as a recurring problem he still sees. His suggested check: with archive.org, you can look at the old version of the site. Asked whether it belonged in the documentation as a step, he said: I would mention that, because it does have an effect on search.

Recommendation Backlink-history review and a security or blacklist check are worth adding, but they are practice rather than documented requirements - keep them visibly separate from the two above.

Pass rule: for a recently purchased destination domain, a dated due-diligence record exists covering all three - archived content and prior use, the Manual Actions report in the verified Search Console property (with any listed issue resolved and reconsideration filed), and the Removals report including any site-wide or prefix removal. The record is written before the move is scheduled, not before launch.

Step 3: Capture the Baseline - and Note What Expires

This is the section with a deadline. Some of what you will want after launch is only available while the old site is live, and some of it rolls off on a fixed window regardless.

Recommendation On the log window: Google publishes no fixed site-wide crawl cycle, and different URLs are revisited on different schedules, so "one full crawl cycle" is not an auditable criterion. State the window, the crawler-verification method used, and the URL coverage achieved instead.

Pass rule for this step: every applicable item above exists as a dated file in a location the team will still have access to in twelve months - or the plan records why it is unavailable and which evidence replaces it. Alongside each file, record the extraction method, the date range, and the row or URL coverage obtained. A screenshot is not a baseline, and a saved Search Console view is not an export - the underlying data is what rolls off.

Step 4: Plan the Continuity Items Before Anything Is Built

These are the things that are cheap to design in and expensive to retrofit, and several of them are on Google's own preparation list.

Search Console Verification

Documented Google is specific about how this breaks. Make sure your Search Console verification will continue to work after the hosting move. Two mechanisms it names: If you're using the HTML file method to verify ownership of your site in Search Console, make sure you don't forget to include your current verification file in your new copy of the site. And: Likewise, if you include in your content management system's (CMS) templates a meta tag or Google Analytics to verify ownership, ensure the new CMS copy includes these as well.

Losing verification does not damage the site. It removes your ability to see what is happening to it at the exact moment you need to look - and re-verification takes time you will not want to spend during a cutover.

Measurement Continuity

Documented Google's preparation list includes: Use web analytics to analyze usage on both the old and new sites.

Recommendation The detail is yours to plan: analytics implementation on the new templates, consent management behavior, conversion and goal definitions, and any server-side tagging. Broken measurement is worth planning for specifically because of how it presents - a tracking failure and a traffic collapse look identical on the dashboard everyone watches, and the first hour after cutover is a bad time to be establishing which one you have. Confirm measurement fires correctly on staging, before launch, as part of the go/no-go criteria.

Assets, Certificates, Robots.txt and Capacity

Documented Four more items from Google's preparation list, quoted as written:

• Transfer images and downloads (such as PDF documents) that you host. These might already be getting traffic from Google Search or links, and it's useful to tell users and Googlebot about their new location.
• For a move to HTTPS, get and configure the required TLS certificates on your server.
• Set up a robots.txt for your new site and make sure the rules in the new site's robots.txt file correctly reflect the parts you want blocked from crawling.
• Ensure that your server has enough computing resources - with a caveat on scope, below.

The Testing Environment

Documented Google suggests you Create a testing environment, perhaps with IP-restricted access, and for a publicly reachable staging host: To prevent accidentally letting the test site get indexed, add the noindex robots rule to the HTML or the HTTP headers of your pages.

Recommendation Decide now which of those you are using, and record every staging-only control you introduce - each noindex, header directive, robots rule and environment flag - in a list with a removal owner. That list is what staging QA gates against and what the launch sequence verifies has been removed. Building it at planning time is much easier than reconstructing it under launch pressure.

Step 5: Ownership and Approval Gates

Recommendation Nothing in this section is documented by any platform. It is how I run migrations, offered as a working structure rather than a standard.

Assign these by name, not by team. Ownership gaps are a recurring migration failure mode, and the mechanism is mundane: an item goes unchecked because two people each assumed the other owned it.

Assign the universal roles on every migration. Assign the conditional ones only where the classification in step 1 calls for them - a framework replatform that changes no public URLs does not need a redirect owner, and inventing one produces a person with no artifact and an acceptance check that cannot fail.

Universal

Conditional

Two structural notes. The approver should not be the migration owner: the person who has spent six weeks getting a project to the gate is not well placed to decide it is not ready. And where a redirect owner applies, that responsibility runs for a year - past the point where a project team typically disbands, which makes it a resourcing decision to take now, while there is still a project to attach it to.

Step 6: The Risk Register

Recommendation One row per risk, each with an owner, a detection method and a response. The detection column is what makes it more than a list - a risk nobody is watching for is not managed, it is just written down.

Drawn from the failure modes documented across this cluster. Each row carries an applicability condition, for the same reason the roles do - a register full of rows that cannot apply trains people to skim it.

Applicable to Every Migration

• Staging-only noindex or robots rules reaching production - detection: post-cutover fetch of representative URLs, inspecting response headers, HTML and the live robots.txt.
• Content missing from what Google renders - detection: comparison of the raw response, the browser-rendered DOM and Google's rendered output.
• Server capacity insufficient for the post-migration crawl pattern for this migration type - detection: error rates and Crawl Stats host status.
• Measurement broken at cutover - detection: confirmed firing before launch, re-confirmed after.
• Search Console verification lost - detection: checked on every applicable property; both old and new for a domain move.

Applicable When Public URLs Change

• Redirects pointing at URLs that do not exist - detection: the map tested against its expected outcomes, per redirect mapping.
• Redirects or content delivered differently to crawlers than to browsers - detection below.
• Backlinked URLs mapped incorrectly - detection: manual confirmation of the top set by referring domains.

Applicable When the Domain or Infrastructure Changes

• Change of Address not filed, or not for every old-domain variant - detection: filing status reviewed in Search Console.
• DNS or TTL misconfiguration, or the old host shut down before it should be - detection: DNS propagation checks and logs on both old and new infrastructure.

Step 7: Define the Gates Now, Not Later

Recommendation Both of these are written during planning and executed by later phases. Writing them under time pressure, after the build, is how they end up describing what the build happens to do.

• Go/no-go criteria - the named, measurable conditions the staging build must meet before cutover is authorized, with the approver identified. Staging QA tests against them.
• Rollback triggers and escalation thresholds - two separate lists, because they operate on different timescales. Conditions you can observe immediately and unambiguously (availability, routing, missing critical content, broken transactions) can justify an immediate revert. Indexing, ranking and traffic signals arrive aggregated and lagged, and belong to escalation and investigation rather than to automatic rollback. The launch-day page holds the full model.

Step 8: The Launch Freeze

Recommendation Set the date after which no further scope enters the release, and agree it with whoever is able to overrule it. A freeze agreed the week before launch is not a freeze - by then, the work it exists to exclude has already been committed.

What the freeze protects is not the code but the testing: every change admitted after the staging crawl invalidates part of the comparison the go/no-go decision rests on.

What This Phase Does Not Decide

Planning defines the constraints and the gates. It does not produce the artifacts:

• The URL inventory and redirect map belong to phase 2.
• Rendering decisions belong to phase 3.
• The executable test specification belongs to phase 4.

The planning deliverable is a short document someone can read in ten minutes: what is changing, what the baseline was and where the files are, who owns what, what the gates are, and what would make you stop.

Sources

Sources: Google Search Central, Site moves with URL changes - the change-one-element-at-a-time guidance; the preparation list including the same-CMS preference, image and download transfer, TLS certificates, the new site's robots.txt, Search Console settings, web analytics and server capacity; the "Clean up your recently purchased domain" bullet with its manual-action and removed-URL checks; the two lists to save for the move, including the list of sites linking to your old URLs; the heavier post-migration crawling of a URL-changing destination; and the size-dependent phasing recommendation. Google Search Central, Verifying Googlebot and other Google crawlers - the reverse and forward DNS method, and identification by published IP ranges. Google Search Console Help, Start a new bulk data export - that the first export covers the day of the export, and that earlier history comes from the API or the reports; and Export data directly from a Search Console report - the 1,000-row truncation, what it means for smaller and larger sites, and that report totals still include the truncated data. Both reviewed 27 August 2026; neither carries a publication date. Google Search Central, Site moves without URL changes - Search Console verification continuity and the two mechanisms it names; the IP-restricted testing environment; the noindex rule for a publicly reachable test host; and the documented crawl-rate-drop pattern for a stable-URL move. Google Search Central, Debugging drops in Google Search traffic - the 16-month range and the pointer to the Search Analytics API or bulk data exports for longer extracts. Google Search Console Help, Crawl Stats report - the root-level-property eligibility requirement, the representative-sample scope of its example URLs, and host status. Reviewed 27 August 2026; the page carries no publication date. Google Search Console Help, Change of Address tool - the caution against combining multiple moves to a single location. Reviewed 27 August 2026; no publication date shown. Gary Illyes on breaking a move into smaller pieces, and John Mueller on used destination domains - Search Off the Record, episode 56, Google Search Relations, 23 February 2023. A recorded conversation, not documentation. John Mueller on separating a redesign from a domain move, Reddit, July 2020, as reported by Search Engine Journal.

---