Moving from cPanel to Enhance: what changes for you

cPanel has been the default hosting panel for twenty years, so most people moving away from it are not comparing features — they are worried about the day after the move. This is what actually changes.

The mental model is different, and that is the point

cPanel gives you one account with everything in it: files, databases, mail, cron, all sharing the account’s limits. Enhance gives you a container per website. Your five sites are five isolated environments with their own CPU, RAM and I/O ceilings.

The practical consequence is the one people notice first: a plugin that runs away with the CPU takes down that one site instead of all of them. The second consequence takes a week to notice — per-site limits mean per-site numbers, so when something is slow you can see which site is doing the work.

Where the things you use every day moved

• The same jobs, in different places. Nothing in this list is missing on Enhance — it moved.

Nothing here is missing, but two things genuinely differ. There is no public_html at the account level — each site has its own web root. And there is no .cpanel directory of account-level config: the panel owns that state, which is why moving a site between servers is a panel operation rather than a tarball.

The two habits to unlearn

Stop thinking in “accounts”, start thinking in “websites”. In cPanel, adding a second project meant an addon domain inside the same account, sharing the same PHP version and the same limits. On Enhance you add a website, and it gets its own PHP version, its own limits, its own backups. Migrating people often recreate the old layout — one website with five addon domains — and then wonder where the isolation went.

Stop installing per-site security plugins. WAF, malware scanning and brute-force protection run below the site, on the server. A WordPress security plugin on top of that mostly burns CPU re-scanning files that were already scanned, and its login-lockout feature fights the server-level one.

How the move actually happens

A competent migration is not a tar file and hope. The order that keeps downtime at zero:

1. Copy, don't moveThe sites are recreated on the new platform while the old ones keep serving. Nothing about DNS changes yet.
2. Check every site on a preview URLEnhance gives each website a temporary hostname. Click through the checkout, the contact form, the login. This is the step people skip and then discover their payment gateway was locked to the old IP.
3. Lower the DNS TTLTo 300 seconds a day before the switch, so a rollback is minutes rather than hours.
4. Sync the last deltaThe database and any files that changed while you were testing.
5. Switch DNSWatch both servers for an hour, then turn the old one off after a week, not the same evening.

The five moves that keep downtime at zero. Nothing about DNS changes until step 5.

# before the switch: how long will a rollback take?
dig +short example.com A
dig example.com A | awk '/^example/ {print "TTL", $2}'

# after the switch: are you actually on the new host?
curl -sI https://example.com | grep -iE 'server|x-litespeed'

What breaks, honestly

• Hardcoded paths. Anything referencing /home/olduser/public_html — a WordPress WP_CONTENT_DIR, an include in a legacy PHP app, a cron command — needs the new path.
• IP allowlists. Payment gateways, mail relays and third-party APIs that were locked to the old server IP. Collect these before the move; it is the most common post-switch incident.
• Mail. Moving mail is a separate project from moving websites. If the domain’s MX records point elsewhere, leave them there and move the sites first.
• Very old PHP. Code that needs PHP 5.6 will not run on a current platform. That is a rewrite, not a migration, and it is better to know before you start.

On inSave, migrations are done by the engineers who run the platform, not by a script: we copy the sites, hand you preview URLs, and you confirm each one before DNS moves. It is free on every plan, including the reseller lines where there are dozens of client accounts to move.

The short version

You lose one account containing everything; you gain a container per site with its own limits, its own backups and its own PHP. The move is safe when it is a copy-test-switch, and risky when it is a cut-over. Most of what goes wrong is not the panel — it is a hardcoded path or an IP allowlist that nobody wrote down.