Migrating from Another Panel

If you're moving a site from cPanel, aaPanel, CloudPanel, Plesk, or a hand-configured server, the underlying files and databases move the same way regardless of which panel you're leaving. What differs is terminology and where things live. This page maps that, then walks through a real migration.

Terminology map

Concept	cPanel	aaPanel	CloudPanel	AidiPanel
Add a site	"Domain" / "Addon Domain"	"Add site"	"Add Site"	site:add
Per-site OS user	cPanel account	usually shared www user	dedicated Site User	dedicated no-login Linux user (always, per-site)
Web root	~/public_html	/www/wwwroot/<domain>	/home/<site-user>/htdocs/<domain>	/home/<site-user>/htdocs/<domain>
PHP isolation	suEXEC / CloudLinux CageFS	shared PHP-FPM pool by default	per-site PHP-FPM pool	per-site PHP-FPM pool (always, not optional)
Page cache	plugin-based (LiteSpeed Cache, WP Super Cache)	plugin-based, or manual Nginx config	none built-in	Nginx FastCGI Cache, built in, per-site toggle
CLI	WHM API / whmapi1	bt command (limited)	clpctl	aidipanel
SSL	AutoSSL	one-click Let's Encrypt	one-click Let's Encrypt	ssl:install, one-click, CLI or panel

The biggest structural difference to internalize: on AidiPanel, per-site user + per-site PHP-FPM isolation is not a setting you turn on — it happens automatically on every site:add. If you're coming from aaPanel specifically, where PHP-FPM pools are commonly shared across sites unless manually separated, this is the one habit to unlearn — you don't need to (and can't) configure shared PHP for multiple sites here.

Pre-migration checklist

Before touching the new server, from your old server:

• [ ] Export each database: mysqldump -u root -p dbname > dbname.sql
• [ ] Archive each site's files: tar czf sitefiles.tar.gz -C /path/to/webroot .
• [ ] Note down any custom .htaccess rules, cron jobs, and PHP .ini overrides — these don't migrate automatically
• [ ] Note the site's current PHP version, so you can match it on the new server (or intentionally upgrade)
• [ ] Lower your domain's DNS TTL to something short (300s / 5 min) a day or two ahead of the cutover, so the eventual DNS switch propagates fast

Migration steps

1. Create the site on AidiPanel

sudo aidipanel site:add --domain example.com --user example --type php

Use php when importing an existing WordPress installation. The wordpress type is for fresh atomic provisioning and requires the new site's title and administrator fields. Use laravel, php, or static for other existing applications as appropriate; see Site Management → Site Types.

2. Move the files

From your local machine (or directly server-to-server with scp):

scp sitefiles.tar.gz root@new-server-ip:/home/example/htdocs/example.com/
ssh root@new-server-ip
cd /home/example/htdocs/example.com
tar xzf sitefiles.tar.gz
rm sitefiles.tar.gz
chown -R example:example .

That final chown is the step people most often forget coming from a panel where the web user was already the file owner by default — on AidiPanel, anything uploaded via scp/root needs to be handed off to the site's dedicated user explicitly.

3. Create the database and import

aidipanel db:add --name wp_example --user wp_example_user
# Save the generated password it prints

mysql -u wp_example_user -p wp_example < dbname.sql

4. Update config to match the new database

For WordPress, edit wp-config.php:

define('DB_NAME', 'wp_example');
define('DB_USER', 'wp_example_user');
define('DB_PASSWORD', 'the-new-generated-password');
define('DB_HOST', 'localhost');

For Laravel, update the DB_* values in .env the same way — see Deploy a Laravel App, step 3.

WordPress site URL not matching?

If the old site used a different domain, or http vs https, update siteurl and home directly in the database rather than just in wp-config.php:

UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name IN ('siteurl','home');

5. Match the PHP version (or upgrade deliberately)

aidipanel php:list
aidipanel php:install --version 8.2   # if the old site needs a version not installed yet
aidipanel php:version --domain example.com --set 8.2

If the old server was running something old like PHP 7.4, this is a natural moment to test on the oldest version AidiPanel supports rather than carrying legacy PHP forward — but test first, since very old codebases sometimes break on newer PHP major versions.

6. Test before cutting over DNS

Before pointing the domain at the new server, confirm the site actually works using your local machine's hosts file so you're testing the real domain against the new server without affecting live traffic:

# /etc/hosts (or C:\Windows\System32\drivers\etc\hosts on Windows)
<new-server-ip>  example.com

Visit example.com in your browser — you're now hitting the new server directly while everyone else still hits the old one. Check the homepage, an inner page, login, and any forms.

Remove that hosts file entry once you're satisfied.

7. Cut over DNS

Update the domain's A record at your DNS provider to the new server's IP. Since you lowered the TTL ahead of time (checklist above), this should propagate within minutes rather than hours.

# Watch propagation from the new server
watch -n 10 'dig +short example.com'

8. Install SSL on the new server

Only once DNS has actually switched:

aidipanel ssl:install --domain example.com --email admin@example.com

9. Decommission the old server

Once you've confirmed the new site is stable (give it at least 24–48 hours), you can shut down the old one. Keep the database export and file archive around for a few weeks as a safety net regardless.

Common migration snags

Symptom	Usual cause
White screen after import	PHP version mismatch, or a plugin/extension available on the old host but not installed here
"Error establishing a database connection"	wp-config.php / .env still has the old server's DB credentials
Uploads/images broken	File ownership wasn't fixed with chown after transfer — PHP can't write, and old absolute URLs may still point at the old domain
Site loads but assets (CSS/JS) are missing	Old site used absolute URLs baked into the database pointing at the old domain — see the siteurl/home tip above, and search-replace the domain across the DB if this was a domain change too

For anything not covered here, the general Troubleshooting index is organized by symptom rather than by cause, which tends to be faster when you're not sure what's actually wrong yet.