Migrating a site with several active subdomains — shop., blog., app., api., and similar — to HTTPS involves the same fundamentals as a single-domain migration, multiplied across each subdomain, with a few subdomain-specific considerations worth planning for before starting.
Certificate strategy: one wildcard versus several individual certificates
Rollout order: least risky first
Rather than migrating every subdomain simultaneously, a staged order — starting with lower-traffic or less business-critical subdomains, ending with your highest-traffic or most revenue-sensitive one (often the main site or a checkout-handling subdomain) — lets you catch subdomain-specific issues (a forgotten hardcoded link, a subdomain-specific integration) before they affect your most important traffic.
Cross-subdomain links and cookies
If subdomains link to each other, or share session cookies (a common pattern for a main site and an app. or account. subdomain), a half-migrated state — some subdomains on HTTPS, others still on HTTP — can cause specific, easy-to-miss problems: a cookie marked Secure (only sent over HTTPS) set by one already-migrated subdomain won't be sent to a still-HTTP subdomain, which can silently break session or login state across the two until every relevant subdomain is migrated.
HSTS and includeSubDomains during a staged rollout
This is the specific reason HSTS's includeSubDomains directive needs care during a multi-subdomain migration: enabling it before every subdomain is actually ready to serve valid HTTPS will make any not-yet-migrated subdomain completely unreachable for visitors whose browsers already received the header. Hold off on includeSubDomains until the full rollout across every subdomain is confirmed complete and stable.
DNS and infrastructure differences across subdomains
If different subdomains are hosted on genuinely different servers or platforms (a common pattern — main site on one host, a documentation subdomain on another, an app subdomain on a different cloud provider entirely), each needs its own certificate installation and redirect configuration independently; there's no way for one subdomain's correct HTTPS setup to somehow extend to infrastructure it isn't actually installed on, wildcard certificate or not.
Documenting the network as you go
For any organization with more than a handful of subdomains, maintaining a simple inventory — which subdomain, which server, which certificate, which renewal mechanism — pays off well beyond the migration itself. It's the single artifact that turns "did we actually finish migrating everything" from a guess into a checklist, and it's far easier to build accurately during a deliberate migration project than to reconstruct later from scratch.
How to sequence a wildcard certificate rollout across many subdomains safely
Even with a single wildcard certificate technically covering every subdomain at once, the actual HTTPS enforcement, redirects and HSTS specifically, is still worth rolling out subdomain by subdomain in a controlled order, since the certificate covering a subdomain doesn't guarantee every application running on that subdomain is itself ready for the protocol switch.
What to do about subdomains you've forgotten you're running
A Certificate Transparency log search for your domain, covered in our SSL History and Basics categories, will surface every certificate ever issued for any subdomain, including ones a wildcard now covers that nobody remembers actively maintaining — a useful discovery step before assuming you have a complete inventory of what actually needs migrating.
How DNS management complexity scales with subdomain count
Beyond the certificate and redirect work itself, a large subdomain count means a correspondingly large number of DNS records to keep accurate and consistent — using a DNS management tool that supports bulk review or automated consistency checking becomes genuinely valuable once subdomain count grows into the dozens rather than a handful.
What a phased subdomain rollout schedule might realistically look like
A reasonable phased approach might migrate an internal or staff-only subdomain first, confirm stability for a few days, then move to a lower-traffic public subdomain, and finally the primary domain last — giving each stage a chance to surface issues before affecting your most important, highest-traffic property.
How shared authentication systems across subdomains complicate the rollout order
If subdomains share a single sign-on or session system, migrating them out of sync can create a period where a Secure-flagged cookie set by an already-migrated subdomain isn't recognized by a not-yet-migrated one — worth migrating tightly coupled, session-sharing subdomains together rather than spreading them far apart in your rollout schedule.
Why a unified monitoring dashboard across all subdomains simplifies tracking migration status
Consolidating certificate expiry, HTTPS enforcement status, and any error reporting for every subdomain into a single dashboard, rather than checking each subdomain individually, makes it considerably easier to confirm the full rollout's actual completion status at a glance rather than piecing it together manually.
What a subdomain takeover risk means specifically during a migration window
A DNS record pointing to a service you've since decommissioned (an old hosting provider, a discontinued third-party service) creates a subdomain takeover risk where an attacker could claim that same service and serve content under your subdomain — a migration project is a reasonable time to also audit for and remove any such stale, dangling DNS records.
How to handle a subdomain that's intentionally still meant to stay on HTTP temporarily
If a specific subdomain genuinely needs to remain on plain HTTP temporarily during a phased migration, explicitly excluding it from any site-wide HSTS includeSubDomains directive prevents that intentionally-still-HTTP subdomain from being inadvertently broken by a policy meant for the already-migrated subdomains.
Why centralized DNS management tooling becomes essential beyond a handful of subdomains
Once managing DNS for more than a handful of subdomains, a centralized DNS management platform with change tracking and validation becomes considerably more reliable than manually managing individual records through a basic registrar interface, reducing the risk of an error introduced during a busy migration period.
What a dependency map between subdomains helps clarify before starting a rollout
Documenting which subdomains depend on which others, an API subdomain other subdomains call, a shared authentication subdomain, clarifies the safest migration order before starting, ensuring dependencies are migrated in an order that doesn't temporarily break a still-functioning subdomain's reliance on another.
A final word on treating subdomain architecture as a long-term planning concern
The certificate strategy and rollout planning covered throughout this guide is worth revisiting any time your organization plans to add a meaningfully new subdomain, rather than treating this guide's advice as relevant only during an initial migration — subdomain architecture decisions have lasting operational consequences worth planning deliberately each time.
What a completed multi-subdomain migration should leave behind as lasting documentation
A completed migration should leave behind a clear, current inventory of every subdomain, its certificate coverage, and its hosting location — documentation that pays for itself the next time a certificate needs renewing, a new team member needs onboarding, or another migration-scale change becomes necessary.
A quick closing checklist to confirm before considering the migration finished
Before considering a multi-subdomain rollout complete, confirm: every subdomain in your inventory (including ones discovered via CT log search) has valid HTTPS, cross-subdomain authentication still works correctly, and HSTS includeSubDomains is only enabled once every subdomain has been individually verified.