A high-traffic Drupal site can run reliably for years on the same hosting platform, right up until the platform no longer fits. We see this often with established sites that have grown well beyond a basic VPS or shared hosting environment but do not want to take server management in-house.

One recent example was a Drupal site attracting two to three million unique visitors a month. It had been hosted with the same provider for nearly two decades, but that provider was winding down its bare-metal offering in favor of VPS. The customer did not want to manage the infrastructure themselves. They needed a managed hosting partner that understood Drupal, could protect years of email-sending reputation, and could run the migration without disrupting the business.

The obvious parts of a migration — copying files, moving the database, updating DNS — are rarely the hard parts. The problems usually appear later, when traffic spikes, cache layers are incomplete, or email deliverability drops after the sending environment changes.

For a high-traffic Drupal migration, three areas matter most: realistic hardware sizing, a Drupal-aware caching stack, and a proper email deliverability plan.

Why Drupal Migrations Are Different

A small WordPress, Joomla, or brochure-site migration can often move cleanly onto a standard LAMP stack. The site is copied across, a caching plugin is enabled, DNS is updated, and the migration is complete.

High-traffic Drupal sites are different.

Drupal performs best when several layers work together. Internal Page Cache and Page Cache reduce application work. Render caching helps avoid repeated processing. CSS and JavaScript aggregation reduce front-end overhead. Redis, Varnish, PHP OPcache, and a properly configured web tier then keep repeated requests away from PHP and the database wherever possible.

When those layers are aligned, Drupal can handle large volumes of traffic efficiently. When one layer is missing or poorly configured, PHP and the database start doing work that should have been handled earlier in the request path.

That is where generic hosting often falls short. A larger server with default templates is not the same as a Drupal-ready environment. The issue may not show up on launch day. It often appears during the first major traffic spike, when uncached requests hit the database, and the stack runs out of headroom faster than expected.

A managed Drupal platform should be prepared for this before the first file is moved.

The Hardware Reality for 2M+ Monthly Visitors

Early migration briefs often underestimate the hardware needed for a busy Drupal site. A developer may specify 8 GB of RAM, 4 CPU cores, and SSD storage. That might work for a smaller site, but it is usually too light for a Drupal site serving two million or more unique visitors per month.

The monthly average is not the real problem. Peak traffic is.

During busy periods, cache misses can arrive together. Authenticated users may bypass the ‘easiest cache wins’ rule. AJAX requests can stack up. Crawlers may arrive at the worst time. If the infrastructure has little spare capacity, PHP workers and the database can quickly become bottlenecks.

For sites at this level, dedicated infrastructure with proper headroom is usually the safer starting point. That often means 32 to 64 GB of RAM, modern multi-core CPUs, and fast NVMe storage for database and cache-heavy workloads.

The extra cost is small compared with the cost of an outage during a campaign, launch, or seasonal traffic surge. A managed Drupal host should be willing to have that conversation early, rather than simply quoting the smallest possible server.

The Drupal Caching Stack That Matters

Performance does not come from enabling one cache and hoping for the best. It comes from reducing work at every layer.

At the front of the stack, Nginx can serve static assets efficiently, handle modern TLS and HTTP/2 configurations, and pass requests to PHP-FPM. In front of Drupal, Varnish can absorb a large share of anonymous traffic before those requests ever reach PHP.

For Varnish to work properly with Drupal, cache invalidation needs to be tied back to Drupal’s cache tags, often through the Purge module. Without that, teams either cache too cautiously or risk serving stale content.

Redis is commonly used for Drupal’s cache bins, keeping render cache, Page Cache, and other high-churn cache activity out of the database. That allows MySQL or MariaDB to focus on the data work that only the database can perform.

The application layer should run on a supported PHP 8.x release with OPcache enabled and tuned appropriately. The exact PHP version should match Drupal core support, module compatibility, and the hosting provider’s supported stack.

The database layer also matters. MariaDB 10.6+ or MySQL 8.0 should be configured to align with Drupal’s query patterns, with a healthy InnoDB buffer pool and slow-query logging enabled during migration and early tuning. This gives the team visibility into performance issues before they become outages.

A complete Drupal hosting environment should also include the tools teams expect to use: Composer, Drush, Git, and Node.js with npm, as needed for front-end builds. If cPanel/WHM is part of the customer’s existing workflow for email, databases, or domain management, the operating system choice may also need to align with cPanel’s support for managed environments.

The goal is simple: Drupal should not be forced to run on a generic stack. The hosting platform should be built around how Drupal actually behaves under load.

Protecting Email Deliverability During the Migration

Email is one of the easiest parts of a migration to under-plan.

A site that has been running on the same provider for many years may have a mature email setup. SPF records may be carefully built. DKIM may be configured for multiple sending domains. DMARC may have been tightened over time to p=reject. Marketing platforms, transactional email tools, and website-generated mail may all rely on specific DNS records and sending infrastructure.

That reputation can be damaged quickly if the sending IP changes and the DNS cutover is handled casually.

Email deliverability should be treated as its own migration workstream. The plan should include:

Inventory every sender. List every service and subdomain that sends mail for the site’s domain. This includes the website itself, marketing platforms, transactional email services, CRM tools, and any legacy systems still sending messages.

Rebuild SPF carefully. The new sending infrastructure needs to be added to the SPF record before production traffic moves. The old provider’s records should be removed only after the cutover is confirmed.

Stage DKIM before cutover. DKIM signing should be configured and tested on the new environment before the old environment is retired. Low-volume test messages can reveal DNS or key-path issues early.

Watch DMARC during the move. A strict DMARC policy can block legitimate mail if alignment breaks during migration. The cutover plan should include monitoring DMARC aggregate reports and tightening policy only once mail is flowing cleanly.

Preserve BIMI alignment where used. If the domain uses BIMI, the DMARC policy, SVG logo, and certificate alignment need to remain intact. The migration should not accidentally break brand indicators that were already working.

Warm the new sending IP if needed. A cold IP should not receive full production email volume on day one. If the sending IP changes, the volume should ramp gradually over 1 to 2 weeks.

If SPF, DKIM, DMARC, BIMI, and sending-IP reputation are not discussed during the hosting conversation, assume email deliverability has not been properly scoped.

What Fully Managed Drupal Hosting Should Include

For a high-traffic Drupal site, “fully managed” should mean more than server provisioning. It should mean the provider is responsible for the infrastructure foundation on which the site depends every day.

At a minimum, a managed Drupal hosting service should include:

  • A Drupal-ready stack with Nginx, Varnish, Redis, PHP-FPM, and OPcache configured properly.
  • Operating system patching, security updates, and baseline hardening.
  • Firewall management and brute-force protection for Drupal login and admin paths.
  • Off-server backups covering the web root, uploaded files, private files, configuration exports, and database snapshots.
  • Periodic restore testing, not just backup creation.
  • 24/7 monitoring that detects downtime before the customer has to report it.
  • Migration assistance that covers DNS, cutover planning, and email deliverability.
  • Clear response commitments for business hours and out-of-hours support.

It is also important to separate infrastructure management from application support.

Drupal module debugging, custom-theme work, database index tuning, query, replication design, web application firewall tuning, vulnerability scanning, and intrusion detection may all be available, but they are often separate professional services.

A good proposal makes this clear. It shows what is included, what is optional, and what can be added later if the site needs deeper support.

How Atlantic.Net Approaches a High-Traffic Drupal Migration

Atlantic.Net helps customers move high-traffic Drupal workloads onto dedicated bare-metal servers or the Atlantic.Net Cloud Platform. The first stage is usually a practical discovery conversation to understand the current environment, the traffic profile, and the operational risks associated with the move.

Typical questions include:

  • What Drupal core version is the site running?
  • Which contributed and custom modules are in use?
  • What are the current traffic patterns, including authenticated-user activity?
  • What is the current caching stack?
  • Is Varnish already in use?
  • Are Drupal cache bins stored in Redis?
  • How large is the database working set?
  • What does peak traffic look like?
  • Which systems send email for the domain?
  • What SPF, DKIM, DMARC, BIMI, and sending-IP dependencies exist today?
  • Which DNS records and third-party services must be rehearsed before cutover?

From there, Atlantic.Net can scope a hardware configuration, a managed-services package, a backup plan, and a fixed monthly cost.

For a Drupal site in the two-million-unique-visitors range, a typical starting point may be a dedicated server with 64 GB of RAM, 12 to 16 CPU cores, and RAID-10 NVMe storage. The final design depends on the site’s cache hit rate, database size, authenticated traffic, file storage, and operational requirements.

The stack is built for Drupal rather than a generic LAMP template. Backups are stored off-server, with retention shaped around the customer’s content update pattern and recovery needs. Atlantic.Net’s 24/7 engineers handle infrastructure monitoring, patching, escalation, and operational response. Deeper Drupal application tuning or database can be scoped separately, where required.

The migration itself should be staged. A full build is created on the new infrastructure, followed by testing, traffic rehearsal, email deliverability checks, and a planned production cutover. The old environment remains available until the new platform is confirmed stable.

Moving Forward

A high-traffic Drupal migration is not a file copy. It is an infrastructure project with several moving parts that need to be planned before cutover night.

The most successful migrations start with honest hardware sizing, a Drupal-tuned stack, and an email deliverability plan that treats SPF, DKIM, DMARC, BIMI, and sending-IP reputation as production systems.

A hosting partner that asks about these areas early is usually the partner most likely to run the migration cleanly.

To scope a specific Drupal migration, share the current stack, traffic profile, caching setup, and email-sending footprint with the Atlantic.Net solutions team. The conversation may start with server sizing, but the real value is in building a runbook that protects performance, uptime, and deliverability throughout the move.