PrestaShop Migration from Hestia to DirectAdmin

PrestaShop Migration from Hestia to DirectAdmin

A PrestaShop migration does not have to mean moving the whole stack. In this case, I moved the backend from an older Hestia setup to a new DirectAdmin-based host in one evening. The frontend stayed on its existing platform. Newsletter and CRM services stayed where they were. The scope was tighter: make the new backend handle REST APIs, cache, and cron for a multistore ecommerce system.

The active work took about three to four hours. File transfer was the easy part. The real job was proving that routing, Redis, cron, cache invalidation, and store-specific API responses still worked after the move.

What I Moved in the PrestaShop Migration

The backend landed on a modern shared hosting plan with NVMe storage, allocated CPU, and allocated RAM. The hosting panel reported the expected package and disk quota.

I did not move everything, and that was intentional.

Moved:

Left in place:

I prefer this kind of narrow PrestaShop migration because it reduces noise. If you move the frontend, the marketing stack, and the backend at the same time, you create too many variables. Here, I wanted one clear business system to validate.

Routing Was the First Problem

PrestaShop runs as a multishop backend. That means one backend must answer correctly for two stores. On the old host, panel rules and existing URL behavior hid some of the complexity. On the new host, REST calls had to preserve the store context before PrestaShop redirected or canonicalized the request.

The fix was to route store-prefixed REST calls correctly:

That looks minor on paper. In practice, this is the kind of detail that makes a migration feel broken even when the files, database, and DNS are correct. In my work, I check routing before I blame PHP, Redis, or the database.

Redis Helped, but Cache Clearing Mattered More

Redis was enabled through a Unix socket:

/home/account/.redis/redis.sock

PrestaShop then used Redis as the cache backend. API responses improved, but cache only matters if it clears at the right time.

Back office is the source of truth. When someone changes a price, product description, PageBuilder block, category, or campaign in PrestaShop, the frontend API must serve fresh data. Enabling cache alone is not enough. I also had to connect cache clearing to the relevant PrestaShop hooks.

I verified the behavior directly:

That is the difference between “cache is enabled” and “cache can be trusted.” In ecommerce, that difference matters immediately.

Cron Jobs Needed Careful Filtering

The first Hestia cron check found jobs that belonged to another service, not the PrestaShop backend. Those jobs did not belong on the new host because that service was not part of this migration.

The relevant PrestaShop jobs were on the old live Hestia server:

I did not migrate a suspended CRM job. I also skipped Hestia's internal system jobs. DirectAdmin has its own maintenance and backup flow, so copying panel debris would only have created confusion.

One database dump job was first mapped as a cautious development dump. I removed it once I confirmed the hosting panel already handled backups. Duplicating backup flows creates noise unless there is a clear recovery reason.

Performance Results from the Backend Move

I tested the same public REST endpoint 12 times per store:

/rest/pagebuilder/placements

Here were the results:

The stage server was a simple reference server and answered consistently. The new host still answered faster for both stores.

The new host also showed a higher server load average, around 10-13. SSH exposed more CPU threads on the physical host than the account allocation, so that number was not alarming by itself. The account looked quiet: Redis was almost idle, PHP workers were not driving CPU, and the database had low active query load when I checked.

That is why I treat load average carefully on shared hosting. It reflects the host, not only one account. If your provider sells a plan with clear CPU and RAM specs, it still helps to ask how those limits are enforced through CloudLinux or LVE.

My AI Workflow for the Migration

I used Codex as the operating agent for SSH, DirectAdmin API work, server checks, crontab changes, timing tests, and PrestaShop override work.

For review, I use my open workflow ai-collab-bridge. The idea is simple: one AI implements the change, then another AI receives a review packet with the diff, context, and focused questions. Claude Code can then review the work as a second technical reader instead of reacting to a loose summary.

That matters in a PrestaShop migration because there are many small decisions:

AI helps when it has to show its checks. “It works” is not enough. A useful migration run shows commands, status codes, cache behavior, cron state, and the parts that were intentionally not moved.

Lessons I Took from This Migration

Do not copy panel behavior blindly. Hestia and DirectAdmin solve hosting maintenance differently. Hestia panel cron does not belong in DirectAdmin.

Keep the backend migration narrow. If the frontend already runs elsewhere, moving it only adds risk.

Verify cache from the back office point of view. Ecommerce changes happen through price, stock, copy, and campaign edits. Cache that fails to clear becomes a business problem.

Measure the same endpoint repeatedly. One `curl` request says little. Twelve runs per store gave me a much clearer signal.

Do not hardcode database passwords in scripts. Read from the application's existing configuration when needed, and let the hosting panel own backups.

Result

After the move, the backend answered faster than both the old live server and the stage reference in my tests. Redis and LiteSpeed helped. DirectAdmin API was enough for the panel settings I needed. OPcache memory turned out to be a host-level setting, so that belongs with hosting support rather than app code.

The main result was not a lower TTFB. The important result was that the backend still behaved like an ecommerce backend: back office owns the data, the API answers per store, cache clears on changes, and cron runs only the jobs that belong on the new host.

FAQ

How long did the migration take?

The active backend migration took about three to four hours. With timing tests, cron inventory, cache verification, and support notes, the work was closer to four to five hours.

Why did you not move everything?

The frontend already ran elsewhere. Newsletter automation and CRM had their own environments. A narrow backend move reduced risk.

Why was Redis important?

Redis improved backend cache speed, but the real value came when cache clearing was connected to PrestaShop hooks. Without that, back office changes can fail to reach the API.

Why is load average hard to read on shared hosting?

Load average often shows the whole host queue, not only your account. In this migration, the account looked quiet while the host showed higher load. That is why CloudLinux or LVE limits should be confirmed by support.

Why use AI in a server migration?

AI is useful when it works with evidence: config reads, timing tests, cron comparison, API checks, and documented changes. Peer review through an open workflow makes it easier to let another model inspect the risks.