Aloye Computer Enterprises, a US-based cloud reseller, needed 32 client environments migrated from the LLSMP stack to Apache + PHP-FPM. This was a full web server and PHP-layer conversion—not a simple lift-and-shift—with different PHP versions, permissions, configurations, and application requirements across each environment.
Aloye's entire cloud hosting and reseller infrastructure was running on the LLSMP stack — Linux, LiteSpeed, MySQL/MariaDB, and PHP — with lsphp, LiteSpeed's PHP interpreter, powering PHP workloads across every downstream client environment. Because the CloudStack IaaS platform does not carry the LiteSpeed and lsphp stack forward, this migration required much more than moving data or relocating virtual machines. It involved a complete web server and PHP stack conversion, replacing LiteSpeed with Apache and lsphp with PHP-FPM across dozens of production environments while preserving application compatibility, database connectivity, file permissions, and existing website functionality.
The real challenge was not performing a single LiteSpeed to Apache migration; it was executing the same Apache and PHP-FPM migration correctly across a large number of independently managed environments that had accumulated years of configuration drift. Different servers were running different PHP versions, file ownership and permission histories, undocumented customizations, application-specific settings, and varying MySQL/MariaDB configurations. Each environment therefore required its own validation, troubleshooting, and migration path rather than a one-size-fits-all conversion. The scale of these differences made this one of our most complex managed cloud migration, Linux server migration, web hosting migration, and cloud reseller infrastructure transformation projects to date.
lsphp is LiteSpeed’s PHP interpreter, designed specifically to run with LiteSpeed Web Server.
That means a migration away from LiteSpeed cannot be handled as a simple server move, cloud migration, or infrastructure lift-and-shift. The PHP execution layer has to change with the web server itself. For Aloye’s reseller hosting environments, moving to our CloudStack IaaS infrastructure required replacing LiteSpeed with Apache and migrating lsphp to PHP-FPM, while ensuring PHP applications, websites, databases, permissions, and custom configurations continued to operate correctly after the stack conversion.
Moving to Apache with PHP-FPM gave the reseller a more portable and widely supported Linux web hosting stack that is not dependent on a single commercial web server ecosystem. Apache and PHP-FPM are broadly documented, widely supported across cloud and hosting platforms, and easier to standardize across dedicated servers, VPS hosting, reseller hosting environments, and CloudStack infrastructure. For a cloud reseller managing many downstream customer workloads, this creates a more flexible operational model and reduces dependency on LiteSpeed licensing, vendor-specific updates, and lsphp compatibility requirements.
In a single hosting environment, configuration drift may be a minor technical issue. Across dozens of production servers and customer environments, it becomes the core engineering challenge. Each Aloye environment had evolved independently over time, with different PHP versions, file permissions, ownership settings, virtual host configurations, application requirements, database dependencies, and undocumented customizations. As a result, the LiteSpeed to Apache and lsphp to PHP-FPM migration could not be handled with one generic migration script or template. Every environment required individual assessment, configuration mapping, testing, and validation to ensure a reliable web server migration, maintain application compatibility, and deliver a consistent managed cloud hosting platform without customer-facing escalations.
The migration was structured as a repeatable managed cloud migration workflow, but each downstream client environment was still handled individually. Rather than applying one blanket configuration across dozens of servers, we preserved each environment’s existing application requirements while converting the underlying LLSMP stack to Apache + PHP-FPM. The process covered PHP version matching, PHP-FPM pool rebuilds, phpMyAdmin recovery, WordPress .htaccess cleanup, port-forwarding validation, and SSL certificate replacement before final DNS cutover.
Across every environment, LiteSpeed Web Server and lsphp were removed and replaced with Apache and PHP-FPM. Instead of forcing all downstream customers onto a single PHP release, we matched each client’s existing PHP version individually using the appropriate Remi modular and Remi 8.x package streams. This reduced application compatibility risk and allowed the LiteSpeed to Apache migration to preserve the runtime expectations of each website, CMS, and PHP application while moving the hosting stack onto a more portable Apache + PHP-FPM architecture.
Each environment required its PHP-FPM pools to be rebuilt under the existing litespeed user so that established file ownership, permissions, and application access controls remained intact. Resetting ownership during a large-scale Linux server migration can create subtle failures in WordPress, custom PHP applications, upload directories, cache folders, and deployment workflows. By preserving the original ownership model, we avoided introducing new permission errors while still completing the lsphp to PHP-FPM conversion cleanly.
During lsphp removal, phpMyAdmin can disappear as a dependency casualty, even though the database itself remains available. We treated that as a predictable migration dependency rather than waiting for a support ticket after cutover. phpMyAdmin was reinstalled and validated per environment so downstream reseller clients retained browser-based access to MySQL and MariaDB databases throughout the migration. This proactive step reduced avoidable post-migration support issues and helped keep the wider cloud reseller migration free of customer escalations.
Many of the migrated WordPress hosting environments contained LiteSpeed-specific directives inside .htaccess files. Those directives may work correctly under LiteSpeed but can trigger immediate Apache 500 Internal Server Errors after a web server stack conversion. We identified the affected sites and sed-patched LiteSpeed directives out of .htaccess files before cutover, rather than discovering failures after traffic had already moved. This ensured the WordPress migration from LiteSpeed to Apache was compatible with Apache from the first request.
Every environment’s port-forwarding and network access configuration was checked explicitly before DNS changes were made. On a multi-environment cloud infrastructure migration, one missing forwarding rule can create a silent outage even when the server, application, and database are otherwise healthy. Because this is one of the easiest issues to overlook at scale, each reseller environment was validated independently for required service ports, connectivity, and routing before DNS cutover. No environment was assumed to be complete simply because another environment with a similar configuration had passed.
The existing default SSL catch-all virtual host was disabled in each environment, and fresh per-domain SSL certificates were issued after cutover. Rather than carrying forward a shared certificate configuration that could create a fragile dependency across multiple customer websites, every domain received its own SSL configuration. This improved isolation between downstream reseller clients and gave each migrated website a cleaner HTTPS and SSL certificate setup on the new Apache-based hosting stack.
By combining these six controls, the migration became a repeatable but environment-aware LiteSpeed to Apache conversion process. That balance was essential: standardized enough to execute across dozens of servers, but flexible enough to respect each client’s PHP version, permissions, WordPress configuration, database tooling, networking requirements, and SSL setup.
For teams planning their own LiteSpeed to Apache migration, lsphp to PHP-FPM conversion, or broader Linux web hosting stack migration, these are the issues most likely to surface after the web server swap is already complete. In a single server migration they can look like isolated configuration problems; across multiple reseller hosting environments, VPS instances, dedicated servers, or CloudStack workloads, they can become recurring sources of downtime, broken applications, and post-migration support tickets.
One of the easiest mistakes in a large PHP-FPM migration is standardizing every website or customer environment onto a single PHP version. That can immediately break applications that depend on an older or newer runtime. During a LiteSpeed to Apache conversion, preserve each client’s existing PHP version wherever possible and map it individually using the appropriate Remi modular or Remi 8.x package streams. Version-by-version migration reduces compatibility issues across WordPress, custom PHP applications, reseller hosting accounts, and legacy websites.
Rebuilding the PHP layer can accidentally reset Linux file ownership, permissions, and application access controls. Those changes may not fail visibly at first, but they can silently break uploads, cache directories, WordPress plugins, deployment scripts, scheduled jobs, and undocumented customer customizations. When rebuilding PHP-FPM pools, retain the existing ownership model — including the current litespeed user where appropriate — rather than normalizing permissions across every environment. In a multi-client cloud hosting migration, preserving ownership is often safer than forcing a new standard during cutover.
Removing lsphp and LiteSpeed-related packages can also remove phpMyAdmin as a dependency casualty, even though MySQL or MariaDB continues running normally. From the customer’s perspective, database access suddenly appears to be missing after migration. Reinstall and validate phpMyAdmin per environment before cutover so downstream users retain browser-based database administration immediately after the Apache + PHP-FPM migration.
Many WordPress sites running on LiteSpeed accumulate LiteSpeed-specific directives inside .htaccess. Those directives can cause immediate Apache 500 Internal Server Errors after the web server is replaced. Search for and remove or patch LiteSpeed-only rules before traffic moves to Apache. For migrations involving many websites, this is better handled proactively and consistently — for example with controlled sed updates after validation — rather than troubleshooting each WordPress site only after customers report errors.
Port-forwarding gaps are among the most common causes of silent outages during a multi-environment cloud server migration. The application may be healthy, Apache may be running, PHP-FPM may be serving requests correctly, and the database may be available — but one missing forwarding or firewall rule can still make the service unreachable. Validate required ports, NAT rules, routing, connectivity, and service exposure for every environment before DNS cutover. Never assume that because one server passed, another similarly configured server is complete.
Carrying forward a shared SSL catch-all vhost can leave multiple customer domains dependent on one certificate configuration and create unnecessary risk after migration. Disable the shared catch-all configuration and issue fresh per-domain SSL certificates after cutover. This gives each customer environment a cleaner Apache HTTPS configuration, improves isolation between reseller clients, and prevents one SSL configuration problem from affecting multiple hosted domains.
These six checks should be part of any serious LiteSpeed to Apache migration checklist, especially when converting LLSMP environments to Apache + PHP-FPM at scale. The stack swap itself is usually straightforward; the real migration risk is hidden in PHP version differences, permissions, database tools, .htaccess rules, network forwarding, and SSL configuration that only become visible after the new stack starts receiving live traffic.
The migration was completed across dozens of downstream client environments in carefully phased batches over several weeks, making it our largest single cloud reseller migration to date. Despite the scale and complexity of replacing LiteSpeed and lsphp with Apache and PHP-FPM, the project finished with zero client escalations. Each migrated environment retained its original PHP version, Linux file ownership and permissions, database access, networking requirements, and per-domain SSL certificate configuration, even though the underlying web server and PHP execution stack changed completely.
The outcome demonstrated that a large-scale LiteSpeed to Apache migration, lsphp to PHP-FPM conversion, and managed cloud reseller infrastructure migration can be executed without forcing every customer into a single standardized configuration. By preserving environment-specific requirements and validating each server individually, we completed the stack conversion with service continuity, consistent application behavior, and no downstream customer escalation during the phased rollout.
Multiple production reseller hosting environments converted from LiteSpeed and lsphp to Apache + PHP-FPM.
No downstream customer escalations during the migration and phased DNS cutover process.
The migration was executed in controlled batches rather than as a high-risk, all-at-once infrastructure cutover.
Our most extensive cloud reseller hosting migration and web server stack conversion completed as one coordinated project.
"Watching a stack conversion of this scale run across dozens of client environments without a single escalation proved the strength and precision of AccuWeb.Cloud's migration engineering."
Please ask your queries. We are available 24/7
Tell us your current stack and how many environments are on it. An engineer writes back a phased plan, sized to your reseller business, not a generic template.
