You are moving a large, heavily linked site and its API to a new domain. How do you choose among HTTP status codes 301, 302, 307 and 308 for the redirects, and what operational risks do you plan for?

## Framing the decision A domain migration is not one redirect decision but two, along independent axes: **how durable is the statement** (temporary vs permanent) and **must the request method survive** (rewrite tolerated vs preserved). The four codes fill the grid: 302 temporary/tolerated, 301 permanent/tolerated, 307 temporary/preserved, 308 permanent/preserved. And there is a third axis that principals actually optimise: **when** you make the permanent statement. ## Browser traffic Page traffic is GET, so method preservation is moot; the choice is durability. 301 is what you eventually want — it transfers search ranking, updates bookmarks and link databases, and has universal support in crawlers, proxies, and analytics. But it is cached by browsers by default and often persisted to disk indefinitely, and search engines keep the mapping for a long time. A wrong 301 is not something you can retract. So run the rollout on 302, which is not cacheable by default. Validate the mapping against real traffic — 404 rate on the new host, top-URL spot checks, session continuity — then promote to 301 and attach an explicit `Cache-Control: max-age`. Bounding the lifetime yourself is cheap insurance; the default is "whatever the browser feels like". ## API traffic Here method preservation is the whole game. If a client POSTs to the old host and receives 301 or 302, the client may re-issue it as a GET with the body discarded — and the specification tolerates that, so it is not a bug you can file. Silent data loss on writes is the worst possible migration failure. Use **307** during the transition and **308** once the endpoint has permanently moved. But go in with clear eyes about what preservation costs the caller: - **The body must be replayable.** Clients that stream uploads cannot rewind, so they either buffer (memory cost, sometimes prohibitive for large payloads) or fail outright with "cannot rewind request body". - **`Authorization` is usually stripped across origins.** Most HTTP clients and all browsers drop bearer tokens when a redirect crosses to a different host, so the preserved POST arrives unauthenticated and returns 401. Cookies are similarly domain-scoped. - **CORS.** Browsers do not allow a preflight to be redirected at all, and a redirected cross-origin request has extra requirements. Single-page apps calling the old host will break in ways the server-side view never shows. - **Latency doubles** for every redirected call, and old SDK versions may not follow 308 at all. The honest conclusion: **do not migrate write APIs with redirects.** Version the base URL, ship updated clients, publish a deprecation timeline, and let redirects catch stragglers while you watch the counter fall to zero. ## Operational risks to plan **Chains and loops.** Every hop is a round trip, and some link equity is diluted. Build the mapping so any old URL reaches its final destination in **one hop** — do not let `old → old-canonical → new → new-https` accumulate. Loops appear where independent rules collide: an HTTPS-upgrade rule, a `www` canonicalisation rule, a trailing-slash rule, and a legacy-path rewrite, each correct alone. Test the composed behaviour, not the individual rules, and cap-check against the browser's ~20-hop limit. **The mapping itself.** A large site needs a data-driven mapping (path pattern rules plus an explicit table for the long tail), held in version control, with tests asserting `source → final URL` and hop count, run in CI. Anything unmapped should land on a purposeful page — not the new home page, which produces "soft 404s" and terrible user experience. **Capacity.** The redirect tier initially takes 100% of old-domain traffic, including crawler load, which often spikes during a migration as search engines re-crawl. It must be independently scalable and cheap, and it should not depend on the application stack you are decommissioning. **The long tail of the old domain.** You must keep the old domain registered, its DNS live, and its TLS certificate renewed — for years, not months. Budget it and put the renewal in the same automation as production. A migration that dies because nobody renewed a certificate on a domain "we don't use any more" is a classic. **Session and identity.** Cookies do not cross domains. Users will be logged out unless you implement an explicit cross-domain session hand-off, and that hand-off is a security-sensitive design (single-use tokens, short expiry, strict target validation). Analytics attribution also breaks: cross-domain tracking must be configured or the new domain reports its own old domain as a referrer. **Open redirect.** If any rule builds the `Location` from user input, an attacker gets a phishing link on your trusted domain. Accept relative paths or an allow-list of hosts only. **Observability as burn-down.** Instrument redirect hits by source pattern and client type. The migration is done when that curve flattens near zero — that is the signal, not a calendar date. Alert on new 404s at the destination and on any chain longer than one hop. ## The judgement being tested A principal-level answer does not just recite the code grid. It says: permanent redirects are a public, unrecallable commitment, so the design is a *sequence* — temporary while learning, permanent when certain — with method preservation chosen per traffic class, redirects treated as a compatibility net rather than a migration mechanism for writes, and the whole thing instrumented so "finished" is a measurement rather than an assumption.