WordPress Multisite adds a layer of complexity beyond a standard single-site HTTPS migration, since each site in the network can have its own URL configuration that needs to be individually correct.
Network-wide settings
Update wp-config.php to define FORCE_SSL_ADMIN as true, ensuring the network admin area is always served over HTTPS regardless of individual site settings.
Per-site considerations
Each site in the network still has its own Site URL and Home URL values stored in its individual options table — for a subdirectory-based multisite, these generally update together with the network's primary domain, but a subdomain-based or mapped-domain multisite (where different sites use entirely different domains) requires checking each domain's certificate coverage individually, since a single wildcard certificate for the network's main domain won't cover a completely separate mapped domain.
Content
The database search-and-replace step needs to run against every site's tables in the network, not just the main site's — a script or plugin capable of network-wide search-and-replace (rather than one that only touches the currently active site) is worth using here rather than repeating the process manually per site.
Why FORCE_SSL_ADMIN alone doesn't cover every site in the network
Defining FORCE_SSL_ADMIN in wp-config.php ensures the network admin area is always served over HTTPS, but each individual site in the network still has its own separately stored Site URL and Home URL values in its own options table that need their own correct configuration.
What a subdomain-based network needs that a subdirectory-based one doesn't
A subdomain-based multisite network, where each site lives at its own subdomain, needs a certificate covering every one of those subdomains, typically a wildcard, while a subdirectory-based network sharing one domain doesn't have this additional certificate coverage requirement at all.
What to check specifically for a mapped-domain multisite setup
A multisite network using fully mapped, separate domains for individual sites rather than subdomains of one root domain needs each mapped domain's own certificate coverage confirmed individually, since neither a single wildcard nor the network's primary domain certificate would cover an entirely separate, unrelated domain.
What domain mapping plugins add to the standard multisite HTTPS picture
Domain mapping plugins, letting individual sites in a network use entirely custom domains rather than subdomains or subdirectories of the network's root domain, add their own layer of URL handling that needs separate confirmation alongside WordPress core's own multisite URL settings.
How network activation differs from individual site activation for relevant plugins
A plugin activated at the network level applies to every site in the multisite installation simultaneously, while individually activated plugins apply only to specific sites — confirming any HTTPS-related plugin (like a redirect or security plugin) is activated at the correct scope for your specific needs avoids gaps in coverage.
Why testing a representative sample of sites, not just the main one, matters at this scale
Confirming the network's primary site works correctly doesn't guarantee every other site in a large multisite network is equally correctly configured — testing a representative sample across different site types and ages in the network catches inconsistencies a single-site check would miss.
A closing note on multisite's added complexity being manageable with the right approach
While multisite genuinely adds steps beyond a single-site WordPress migration, none of the individual steps are conceptually different from what's covered in our core WordPress guide — the added complexity is one of scale and thoroughness, not fundamentally different technical requirements.
What WP-CLI commands specifically help with a network-wide migration
WP-CLI's search-replace command supports a --network flag specifically for running a search-and-replace across every site in a multisite network in one operation, rather than needing to run the command separately against each individual site's tables.
How this guide's steps differ for a brand new multisite versus converting an existing single site
A brand new multisite network can simply be configured with HTTPS from the start with no historical content to migrate, while converting an existing single site into multisite, or adding HTTPS to an established network, requires the full content migration process covered in this guide applied network-wide.