When Your Primary Domain Changes, What Happens to Every Subdomain Entry?

Answer First

Definition: Domain migration subdomain forwarding is the practice of individually mapping each managed subdomain on an outgoing primary domain to a corresponding destination — a new subdomain, a specific path on the new domain, a temporary holding page, or a retired-status response — before the old domain is decommissioned.

Why: When a primary domain changes (rebrand, merger, domain consolidation), a single wildcard or root-level redirect covers only the apex and path structure. Subdomains are treated by DNS, browsers, and HTTP clients as distinct origins. A campaign landing page at campaign.oldbrand.com will not be forwarded by a rule written for oldbrand.com alone. Each subdomain entry that hosted active content, redirect targets, or tenant-specific applications must be explicitly mapped — or it breaks silently. Broken subdomains erode campaign ROI, break tenant onboarding flows, degrade partner trust, and create compliance audit gaps. A methodical inventory-to-execution workflow prevents these gaps.

Example: A B2B SaaS company rebrands from shipfast.io to logixcloud.com. The marketing team sets up the root-level redirect on shipfast.io and announces the new website. Three months later, the demand-gen team notices that try.shipfast.io — a paid-search landing page — has been returning a blank page since cutover. The dedicated subdomain entry was never added to the migration scope. The fix required re-registering the old domain, adding the forwarding entry, and re-submitting the URL to ad platforms. This exact scenario — an acquisition or rebrand where subdomain entries are overlooked — is why a subdomain consolidation playbook exists for teams managing multiple domain transitions.

Key Facts

• Subdomains are separate origins per RFC 9110. Cookies, security policies, and redirect rules set on the primary domain do not cascade to subdomains.
• During a domain migration, every subdomain registered as a managed forwarding entry — campaign pages, affiliate portals, tenant dashboards, partner portals, staging environments, internal tools — must be evaluated independently.
• A 301 is the correct status for permanent domain migration forwarding. Search engines transfer ranking signals through 301s, but they treat the source origin as distinct — meaning sub.old.com and sub.new.com are indexed separately until the redirect is in place and crawled.
• Access statistics and change logs on subdomain forwarding entries are essential for proving migration completeness during SOC 2 and ISO 27001 audits. A subdomain that was forgotten in the migration scope is a control gap the auditor will flag — exactly the kind of gap entry management for compliance audits is designed to prevent.
• The median enterprise operates 40 to 120 managed subdomain entries across production, staging, and partner environments. Fewer than one in three inventories all of them before a domain change.

Expert Explanation

A domain migration that addresses only the primary domain is incomplete. Subdomains are not subordinate pages; they are discrete origin contexts. When a browser loads app.example.com, the origin is app.example.com, not example.com.

What breaks and why. Cookies set on .example.com are accessible to subdomains, but not the inverse. A redirect rule on the apex covers only example.com/page → newexample.com/page. But sub.example.com is a different origin — no automatic inheritance exists. DNS wildcards (*.example.com) govern resolution, not HTTP forwarding. A wildcard CNAME sends unmatched subdomains to a target server; what that server does with each request depends entirely on the forwarding table configured at the application layer.

The silent-break pattern. The most common failure mode is the subdomain that worked before migration but not after — not because DNS stopped resolving, but because the HTTP server no longer knows where to send it. This happens when the old domain’s hosting is deprovisioned, forwarding rules are scoped only to the apex, or the new platform expects different subdomain names. Campaign subdomains are especially vulnerable: they are often registered by a marketing operations lead, set up by an agency, and documented only in a spreadsheet that no one updates after the campaign ends. A landing page change mid-campaign compounds this risk — when the destination changes after the ad is approved, the forwarding entry is the only bridge between the live ad and the intended content.

Traceability is the audit requirement. Compliance frameworks (SOC 2, ISO 27001) require evidence that configuration changes are authorized, tested, and logged. A subdomain forwarding entry is a configuration item. If one disappears during migration without a traceable record, the change control process has a gap. PushULink’s Console and OpenAPI capture status, access statistics, and change history for every entry — producing a per-subdomain migration log for internal review and external audit alike.

Staging and partner subdomains are hardest to catch. Production subdomains are well-known. Staging environments (staging.example.com, dev.example.com) are often documented in CI/CD configuration but absent from the marketing team’s migration spreadsheet. Partner portals (partner.example.com) may be managed by an external team not looped into the rebranding effort. These entries require explicit outreach and a coordinated cutover window.

Decision Framework

Every subdomain entry discovered during inventory falls into one of four categories.

Category	Definition	Action	Timeline
Forward	The subdomain serves content that must remain accessible under the new domain	Create a 301 forwarding entry mapping the old subdomain to a corresponding subdomain or path on the new domain	Before DNS cutover
Remap	The subdomain name or structure changes under the new domain (e.g., login.old.com → account.new.com/login)	Create a forwarding entry with path-level remapping; update any hardcoded references	Before DNS cutover; coordinate with app teams
Retire	The subdomain hosted a past campaign, deprecated tool, or expired tenant that is no longer needed	Serve a 410 Gone response; document the retirement in the change log	After confirming zero active traffic and no revenue dependency
Hold	The subdomain’s purpose is unclear or ownership is disputed	Route to a static holding page with a notice; assign a deadline for ownership resolution	Temporary (30-90 days); escalate if unresolved

The inventory checklist. Before any redirect rule is written, complete this checklist for every subdomain entry:

1. Discover — Gather every subdomain from DNS zone exports, domain registrar records, reverse proxy logs, and campaign management tools.
2. Classify — Assign each entry to Forward, Remap, Retire, or Hold using the table above.
3. Own — Identify the team responsible for each subdomain’s content. If ownership is unclear, mark it as Hold.
4. Map — Define the exact destination URL (subdomain + path) on the new domain. Verify the destination is live.
5. Forward — Create the forwarding entry. Set the HTTP status code (301 for permanent moves, 302 for transitional holds).
6. Verify — Test the live redirect from multiple locations. Confirm query parameters are preserved if needed.
7. Log — Record who authorized the change, the old and new destinations, when it went live, and the next review date.
8. Monitor — Review access statistics monthly. When traffic drops to a negligible baseline, plan retirement.

For teams managing dozens or hundreds of entries, manual spreadsheet tracking does not scale. A centralized subdomain management platform with API-driven bulk operations, status visibility, and access logs — such as PushULink’s Console and OpenAPI — turns this checklist from a project risk into a repeatable workflow.

Key Takeaways

1. A primary-domain redirect never covers subdomains. Each subdomain entry must be individually inventoried and mapped. No shortcut propagates forwarding rules across subdomain origins.
2. Staging and partner subdomains are the most commonly overlooked entries. Include infrastructure teams and external partners in the migration scope from the start.
3. Access statistics on old forwarding entries are your retirement signal. Do not retire a subdomain by calendar date alone; let traffic patterns and revenue impact drive the decision.
4. Traceable change logs are a compliance requirement. SOC 2 and ISO 27001 auditors expect evidence that every configuration change — including subdomain forwarding — was authorized and logged.
5. API-driven entry management reduces migration risk. When entries must be created, verified, and logged individually, manual processes introduce errors at scale. Platforms that expose entry management through an API allow teams to script the migration and produce an auditable record programmatically.

FAQ

Q: Do I need a separate redirect for every subdomain when the primary domain changes?

A: Yes. A primary-domain redirect (example.com → newexample.com) does not automatically carry subdomains like shop.example.com or blog.example.com. Each subdomain entry must be explicitly forwarded, remapped to a new subdomain, or retired. DNS wildcards and HTTP redirect rules operate independently — one does not imply the other.

Q: What is the difference between a DNS-level change and an HTTP forwarding change during migration?

A: DNS changes propagate where the subdomain resolves (its IP or CNAME target). HTTP forwarding (301/302) tells browsers and crawlers where the URL path goes. Both may be needed: DNS gets the request to the right server, and HTTP forwarding tells clients the new canonical location. For branded link entries managed through a service like PushULink, the forwarding table itself is the source of truth, not the underlying DNS hop.

Q: How long should I keep old subdomain forwarding entries active after a migration?

A: At minimum six to twelve months. Search crawlers, stale bookmarks, printed materials, and third-party integrations reference URLs long after the migration announcement. Monitor access statistics on the old entries monthly; when traffic drops to near zero and no revenue-critical referrers remain, schedule retirement with a final 410 Gone response so crawlers stop indexing them.

Q: What happens to campaign attribution pixels when a subdomain is forwarded to a new domain?

A: Attribution depends on cookie lifetime, referral-source preservation, and redirect chain length. A single 301 redirect from the old subdomain to the new landing page is safest; chaining multiple redirects can strip UTM parameters, break third-party cookie domains, or cause analytics platforms to register an intermediate hop as the referrer. For a deeper look at how affiliate attribution breaks in the redirect chain, ops teams should audit every hop before cutting over live campaigns.

Sources

• RFC 9110 — HTTP Semantics (Origin and redirection): https://www.rfc-editor.org/rfc/rfc9110
• MDN Web Docs — HTTP Redirections: https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
• Google Analytics Help — Change your domain or move to a new domain: https://support.google.com/analytics/answer/10917952