Drupal's HTTPS migration involves fewer moving parts than some CMS platforms — there's no single "site URL" database setting the way WordPress has — but a few Drupal-specific things are worth understanding before assuming a server-level redirect alone is sufficient.
How Drupal detects its own base URL
By default, Drupal dynamically detects the base URL from the incoming request rather than storing it as a fixed setting, which means a correctly configured server-level HTTPS redirect is often enough on its own — Drupal will naturally generate https:// links once requests are actually arriving over HTTPS. This is a meaningful difference from platforms like WordPress or Magento, which store an explicit base URL value that has to be manually updated.
When you do need to set it explicitly
// settings.php
$settings['base_url'] = 'https://yourdomain.com';Explicitly setting base_url in settings.php becomes necessary in specific situations: behind a reverse proxy or load balancer where Drupal can't reliably auto-detect the original protocol, in a multi-site Drupal installation with ambiguous domain detection, or when running Drush commands and other CLI operations that don't have a real HTTP request context to detect the protocol from.
Reverse proxy configuration
If Drupal sits behind a reverse proxy or load balancer (a common production setup), it needs to be explicitly told to trust the proxy's forwarded-protocol header, or it will incorrectly believe every request is plain HTTP even when the original visitor connection was secure:
// settings.php
$settings['reverse_proxy'] = TRUE;
$settings['reverse_proxy_addresses'] = ['10.0.0.1']; // your proxy's IPModules that can interfere with the redirect
A handful of common Drupal modules — particularly caching modules like Varnish integration, and some older SEO/redirect modules — can maintain their own redirect or URL-rewriting logic that conflicts with a straightforward server-level HTTPS redirect. If you're seeing unexpected redirect behavior after migration, check whether any installed module has its own HTTPS-related configuration that might be duplicating or conflicting with the server-level rule, rather than assuming the server configuration itself is wrong.
Content and hardcoded URLs
Like any CMS, Drupal content entered through the WYSIWYG editor can contain hardcoded absolute http:// URLs from before migration — these won't be automatically fixed by base URL detection, since that only affects URLs Drupal itself generates dynamically. A dedicated search-and-replace across the database (several contributed modules exist specifically for this, or a direct SQL search-and-replace targeting the relevant content tables) handles existing content.
Clearing caches after migration
Drupal caches aggressively by default. After any base_url or reverse proxy configuration change, clear all caches (drush cr, or via the admin UI) to ensure the new configuration is actually being used rather than a stale cached version of previously generated pages and URLs.
Drupal's own security review checklist
Once HTTPS is live, it's worth also reviewing Drupal's cookie and session configuration — specifically confirming session cookies are set with the Secure flag (so they're never sent over a plain HTTP connection) and that any custom code generating absolute URLs uses Drupal's URL generation API rather than string concatenation, which is what makes the automatic base URL detection discussed above actually reliable rather than something individual modules can inconsistently bypass.
How to handle Drupal's aggressive caching during the transition
Drupal's page cache, and any separate caching layer like Varnish sitting in front of it, can serve stale, pre-migration HTML containing old http:// references even after your configuration changes are correctly in place — clearing every layer of cache, not just Drupal's own internal cache, is a necessary step often missed during migration.
What Drupal's Update Manager and security advisories say about HTTPS specifically
Drupal's own security team has published guidance over the years specifically recommending HTTPS as a baseline expectation for any production site, reflecting the same broader industry shift covered throughout this site — running a current, supported Drupal version generally means HTTPS-related configuration options are well-documented and actively maintained rather than requiring workarounds.
How contributed modules can complicate an otherwise clean migration
Drupal's large ecosystem of contributed, community-maintained modules means some site-specific functionality may have its own independent assumptions about protocol or base URL baked in — reviewing any custom or less common installed modules specifically for hardcoded URL assumptions is worth doing before assuming a migration is fully complete.
What Drupal's configuration management system means for a multi-environment migration
If your Drupal site uses configuration management (config sync) across development, staging, and production environments, the base_url and reverse proxy settings in settings.php specifically stay outside the exported configuration by design, meaning each environment needs its own correctly configured settings.php independently.
How Drupal's entity URL generation differs from simple string-based links
Drupal generates most internal links through its entity and routing system rather than storing complete URLs directly, which is part of why the platform generally requires less manual content cleanup during migration than platforms storing fully hardcoded links throughout content — though custom code or older content using direct HTML links still needs the standard review.
Why testing Drupal's REST or JSON:API endpoints separately matters if you use them
If your Drupal site exposes a REST or JSON:API endpoint consumed by a separate frontend or mobile app, confirming that API specifically generates and accepts https:// URLs correctly is worth testing independently from the standard web-facing site verification.
What Drupal's Big Pipe and internal page cache mean for migration testing
Drupal's internal caching systems, including Big Pipe for dynamic content and the internal page cache for anonymous users, can serve cached pre-migration content briefly after a configuration change — clearing all cache bins explicitly (drush cr, or the equivalent admin UI action) ensures your testing reflects the actual current configuration rather than cached prior output.
How Drupal's multisite feature adds its own layer of configuration complexity
A Drupal multisite installation, running several separate sites from one codebase, requires each site's own sites/[sitename]/settings.php to have correctly configured base_url and reverse proxy settings independently — a single shared settings file update doesn't automatically propagate across every site in a multisite installation.
Why Drupal's Composer-based dependency management affects how you apply hotfixes
A modern, Composer-managed Drupal installation tracks module and core versions through composer.json rather than manual file uploads — applying any HTTPS-related module updates or security patches through Composer, consistent with how the rest of the site is managed, avoids version drift that manual file replacement can introduce.
What a systematic module audit for hardcoded URLs actually involves
A systematic audit means reviewing each enabled contributed module's own configuration and settings pages, not just custom code, for any hardcoded http:// references — most well-maintained modules avoid this, but older or less actively maintained ones occasionally store a hardcoded URL in a settings field entered years ago.
A final word on Drupal's overall migration-friendliness compared to other platforms
Drupal's automatic base URL detection and entity-based link generation genuinely make it one of the more migration-friendly platforms covered across this site — the steps that do require manual attention (reverse proxy configuration, contributed module review) are narrower and more targeted than the broader database-wide search-and-replace some other platforms require.
What ongoing maintenance looks like once the migration itself is complete
Beyond the initial migration, keeping Drupal core and contributed modules updated through your normal maintenance cycle is what keeps HTTPS-related configuration current as Drupal's own security team continues refining best-practice recommendations — treating this as a one-time task rather than an assumption baked into your ongoing update process risks configuration drift over time.
A quick closing checklist to confirm before considering the migration finished
Before signing off, confirm: base_url and reverse proxy settings correctly configured if applicable, all cache layers cleared, contributed modules reviewed for hardcoded URLs, and any REST or JSON:API consumers updated — a short but complete verification of everything this guide has covered.