PHP/MySQL applications frequently outgrow their shared hosting environment, especially because they typically start on a mainstream shared provider. Atlantic.Net engineers commonly handle PHP/MySQL migrations from shared to private hosting.

Recently, our engineering team helped a customer migrate their PHP/MySQL application from a modest GoDaddy plan that was once ideally sized, but now fell short. 

GoDaddy served the customer well, but over several years, the application grew, the database grew, and Stripe integrations and background jobs were added. The hosting plan did not change, and as a result, issues started to creep in; report pages took longer to render, cron jobs overran their start windows, and some outbound API calls timed out under load. Such examples are often hosting-tier problems, not necessarily application defects, but it’s not uncommon for the two to be routinely confused.

Using this scenario as a foundation, this article covers the real-world decisions our engineers help customers make when moving a production PHP/MySQL application to managed dedicated infrastructure: hardware sizing, PHP version strategy, the cPanel-or-not question, and the four workstreams that account for most post-cutover problems: email, database integrity, outbound API reliability, and DNS.

Why Shared Hosting Became the Bottleneck

Shared hosting is sized for large numbers of small, predictable workloads on a single machine. GoDaddy and other mainstream providers have run low-traffic brochure sites, static portfolios, and small ecommerce stores reliably on this model for years. A PHP/MySQL application with a real database, real concurrency, and background jobs may often require a different class of tenant.

Three things happen as the application grows past the tier:

  • Resources stop being predictable. A shared server packs dozens or hundreds of tenants onto the same hardware. When a neighbor’s cron job runs, or a neighbor’s site is crawled, the application’s query times can be impacted.
  • Background and CPU-intensive work gets throttled. Shared plans cap execution time, memory per process, and concurrent connections. A report that runs in a single query on a dedicated server may need to be split into five smaller queries on a shared server and risk timing out on a long join or failing on a subsequent cron iteration.
  • Outbound reliability degrades under load. Applications calling Stripe, email APIs, or payment gateways need steady outbound connectivity. Shared tenants share outbound IP reputation and rate limits, so a percentage of timed-out checkouts may appear to be a payment-provider issue when the real cause is more likely a shared-IP reputation problem or overloaded outbound infrastructure.

The Hardware Profile for a Business-Critical PHP App

A PHP/MySQL application handling payments, large queries, and background jobs at a moderate scale typically needs more capacity than developer briefs initially suggest. A production-appropriate profile for this class of workload would typically be:

  • 128 GB of RAM so the MySQL InnoDB buffer pool can hold the working set of a 15 GB database in memory, with room for PHP-FPM, the operating system, and application caches.
  • 2 × 1 TB NVMe in RAID 1 (or an equivalent mirrored configuration) for fast local storage with disk-level redundancy.
  • At least 1 Gbps network for API chatter and the bandwidth volume generated by a few hundred GB of outbound Stripe traffic per month.
  • Modern Intel Xeon or AMD EPYC processors with strong single-thread performance, because PHP serves a request on a single core, and MySQL’s execution stage is often single-threaded per query.

Meaningful sizing guidelines need to focus on CPU-bound or I/O-bound workloads on the database. Most PHP/MySQL applications at this size benefit more from NVMe storage and a generous buffer pool than from a faster processor. But hardware is only the starting point.

A database-heavy PHP application also needs professional MySQL or MariaDB tuning: an appropriately sized InnoDB buffer pool, enough connections for the PHP-FPM worker model, slow-query logging during the stabilization period after cutover, and storage settings aligned with NVMe rather than older spinning-disk assumptions. The right hardware choices create the headroom for the application, and tuning determines how much of that headroom the application uses.

PHP 7.4 Is a Legacy Dependency, Not a Supported Choice

Any long-running PHP application faces a versioning question during migration. Applications in production for several years are often still on PHP 7.4, which reached end of life on 28 November 2022. PHP.net has issued no security updates for it in over three years. For a payment-processing application in 2026, PHP 7.4 is not a supported runtime — it is a legacy dependency.

Hosting an application on PHP 7.4 in the short term is possible, but only as a bridge while the code is modernized. A managed provider may be able to support legacy PHP through hardened or specially maintained builds, but that should be treated as a temporary compatibility measure rather than a long-term hosting tier. The goal is to keep the application stable, reduce immediate migration risk, and give the development team time to move the codebase onto a supported PHP 8.x release. The migration plan should name a modernization target date from the first conversation, so PHP 7.4 does not quietly become the new permanent state.

A current PHP 8.x release should be your starting point, with the exact minor version chosen by application compatibility and the hosting provider’s supported stack. Modernizing as part of the migration, rather than deferring the problem.

  • Target a server that runs a vendor-supported PHP version from day one.
  • Choose a provider that is not constrained by legacy-PHP availability.
  • Ensure any payment-processing application does not rely on an end-of-life PHP runtime.

For applications where the code change is complex, the practical sequence is a migration to managed dedicated infrastructure on CloudLinux Hardened PHP 7.4 as a short bridge, with a committed modernization project running alongside, cutting over to PHP 8.x on the same server once the code is ready. The bridge should be measured in weeks, not years.

The Workstreams That Get Forgotten

Sizing, PHP version, and operating system are the visible parts of the migration. Four less-visible workstreams account for most late-stage problems:

  • Email. A move changes the outbound IP reputation. Applications sending transactional email need SPF updated for the new sending infrastructure, DKIM keys staged on the new host before cutover, and DMARC temporarily softened to p=none during IP warm-up before tightening back. Mailbox data does not migrate itself either: IMAP sync, mail-server cutover, and the DNS MX change need to be sequenced.
  • Database integrity. A 15 GB production database is small enough for a controlled dump-and-restore, but not casually. Migrations can be performed using mysqldump, a Snapshot hot copy, or a staged cutover with a brief read-only window. You should work with the hosting provider to choose an approach based on write volume, acceptable downtime, the storage engine, and consistency requirements.
  • Stripe and outbound API reliability. Payment-processing applications depend on reliable outbound HTTPS to Stripe and equivalent services. Outbound connectivity on managed dedicated hosting is typically a non-event, but should be confirmed rather than assumed. Work with your provider to test the outbound stability.
  • DNS. A change of IP is a DNS change, and a DNS change is a propagation window. Short TTLs set before cutover, a well-rehearsed record change on the night of the move, and monitoring of propagation should be part of the migration planning.

Why Migration Discovery Matters

Shared hosting environments often depend on details that are not obvious from the outside. A site may rely on custom PHP extensions, specific Apache or LiteSpeed rewrite rules, email account settings the customer no longer has documented, or .htaccess behavior that only works because of undocumented server configuration.

Proper migration discovery catches these issues before the quote is finalized. That means reviewing the current PHP configuration, loaded extensions, DNS records at both the registrar and the existing host, cron jobs, mail settings, and any hosting-level dependencies the customer may have forgotten about. The result is a quote that reflects the real work required, and a cutover that is far less likely to produce late-night surprises.

What “Fully Managed” Should Include

When choosing your next hosting provider, understand what “Fully managed” really means. Does it include cPanel management, additional managed services, and 24/7 engineering support?

For a business-critical PHP/MySQL application, the minimum recommended Managed Service should be:

  • OS patching and security updates on a regular cadence
  • Managed firewall with ruleset updates, port management, and brute-force protection via Fail2ban or equivalent
  • 24/7 monitoring and alerting on the host and core services
  • Off-server backups with daily full backups, a reasonable retention window, and both file- and database-level restore options
  • Response-time commitments during business hours and out of hours, such as a 100% Uptime SLA.
  • Migration assistance covering the cutover sequencing, DNS, and email

You should also consider if any additional professional services are needed before or after the migration. Consider discussing these points with your prospective provider:

  • Is Application-Level Support Available?. Code debugging, schema work, and application performance tuning are paid consulting, not standard managed services.
  • Do you provide Database Administration? Index tuning, query performance work, and replication setup are often a separate service line.
  • Is Advanced Managed Security an Option? Web application firewalls, vulnerability scanning, and intrusion detection are common add-ons.

A proposal that itemizes these makes the monthly bill easier to predict and easier to trim if a specific line is not needed.

How Atlantic.Net Approaches the Migration

Atlantic.Net is an expert at migrating almost any workload to either our dedicated or cloud hosting platforms. We welcome you to reach out to our skilled engineers to discuss your requirements.

Our first interactions with the customer are usually grounded in fact-finding, with the aim of providing the customer with the facts of how Atlantic.Net hosting and our vast range of managed services can improve the reliability, performance, and stability of the customer’s critical PHP/MySQL applications.

Here are the typical questions we would ask:

  1. What is the current shared environment?
    Typically, GoDaddy or a similar mainstream shared host — and what does it expose: OS, PHP version, cPanel or other control panel, email volume, database size, outbound traffic?
  2. What is the target CPU and memory profile?
    Based on the database working set and the concurrency, what does the application see?
  3. Is the application already on PHP 8.x?
    If still on PHP 7.4, what is the modernization timeline, and does the migration need a short CloudLinux Hardened PHP bridge?
  4. Do you still need cPanel?
    Does cPanel need to come along, or can the environment run on plain, one-click Ubuntu LTS?
  5. What sits on the DNS, email, and API dependency list?
    These are just the introductory due diligence questions we will ask to determine if the client needs to be rehearsed before cutover.

We use the initial due diligence to create a plan for a potential hardware configuration, a managed-services package, a backup plan, and a fixed monthly cost. Atlantic.Net scopes the environment around the application’s actual footprint, the RAM for the database working set, NVMe sized for files and database growth, cPanel and CloudLinux licensing where required, managed firewall and monitoring, backup retention tuned to recovery targets, and migration assistance covering files, database, email, DNS, and cutover. The final environment may be dedicated bare-metal or a Private Cloud, depending on performance, management, and isolation requirements.

Moving Forward

A PHP/MySQL application outgrowing shared hosting is a healthy problem — it’s doing enough work to justify better infrastructure. The work that separates a clean migration from a painful one is the work done before the first file moves: honest sizing, a PHP version strategy, the cPanel-or-not decision, and a migration plan that names email, database integrity, Stripe connectivity, and DNS as separate workstreams.

To scope a specific migration, share the current shared-hosting footprint — PHP version, database size, email volume, outbound dependencies — with the Atlantic.Net solutions team.