Guide Move a WordPress Site to CyberPanel by Hand: Files, Database, New URL (Tested)

Guide Move a WordPress Site to CyberPanel by Hand: Files, Database, New URL (Tested) - Printable Version

+- AdminsForum (https://adminsforum.com)
+-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels)
+--- Forum: CyberPanel (https://adminsforum.com/Forum-cyberpanel)
+---- Forum: CyberPanel Guides & Tutorials (https://adminsforum.com/Forum-cyberpanel-guides-tutorials)
+----- Forum: CyberPanel Backups & Migration Guides (https://adminsforum.com/Forum-cyberpanel-backups-migration-guides)
+----- Thread: Guide Move a WordPress Site to CyberPanel by Hand: Files, Database, New URL (Tested) (/Thread-guide-move-a-wordpress-site-to-cyberpanel-by-hand-files-database-new-url-tested)

Move a WordPress Site to CyberPanel by Hand: Files, Database, New URL (Tested) - JAY - 10-27-2026

Move a WordPress Site to CyberPanel by Hand: Files, Database, New URL (Tested)

Migration plugins are fine for small sites, but they fail on big ones, time out, or want a paid version. The manual way always works: copy the files, copy the database, then tell WordPress where it lives now. We moved a WordPress 7.1 site to a fresh website on CyberPanel 3.0 (OpenLiteSpeed, MariaDB, Ubuntu 24.04) and at the same time changed its domain, from

Code:

staging.cyber.adminslab.com

Code:

moved.cyber.adminslab.com

. In our lab the "old server" was the same machine, but every step is the one you'd use between two servers.

Three things went wrong that the usual tutorials don't mention: the new copy quietly used the old database, the archive changed the permissions of public_html, and LiteSpeed Cache kept serving the old domain after the URL change.

What you need

SSH access to the old server (or a full files backup and an SQL export from its control panel).
Root SSH on the CyberPanel server.
WP-CLI, which CyberPanel installs (
Code:
wp --version
; ours: 2.12.0).

Step 1: Export on the old server
In the WordPress folder (where

Code:

wp-config.php

is):

Code:

wp db export /root/move/site.sql --allow-root
tar czf /root/move/files.tar.gz .

Export on the old server:
[Image: attachment.php?aid=620]

No WP-CLI on the old host? Use

Code:

mysqldump -u DBUSER -p DBNAME > site.sql

, or the export button of its phpMyAdmin. Then copy both files to the new server:

Code:

scp /root/move/* root@YOUR-SERVER-IP:/root/move/

Step 2: Prepare the website on CyberPanel

Websites > Create Website with the domain. Same PHP version as the old server, or newer if your plugins support it.
Databases > Create Database for that website. Note the name, user and password.
Find the website's Linux user, you need it in Step 4:
Code:
grep extUser /usr/local/lsws/conf/vhosts/DOMAIN/vhost.conf
(ours:
Code:
moved3449
).
If the domain already points here: Issue SSL. If not, do it after the DNS change.

Step 3: Extract the files and import the database

Code:

cd /home/moved.cyber.adminslab.com/public_html
rm -f index.html
tar xzf /root/move/files.tar.gz
mysql -u moved_wp -p moved_wp < /root/move/site.sql

(The

Code:

index.html

is CyberPanel's placeholder page; WordPress doesn't need it. For big databases or import errors, see our guide on importing large SQL files over SSH.)
Extracting and importing on CyberPanel:
[Image: attachment.php?aid=621]

The site loaded right away, with its normal title. Don't celebrate yet:
Still the old database, old links, and the wrong file owner:
[Image: attachment.php?aid=622]

Code:
wp-config.php
still pointed at the old database. Because our old site was on the same server, that database existed and the new copy happily used it: every edit on the "new" site would have changed the old one. Between two servers you'd see Error establishing a database connection instead.
The page still had 30 links to the old domain.
The files kept the old server's owner (here
Code:
cyber2602
), so WordPress, which runs as the website's own user on CyberPanel, couldn't write anything: no uploads, no plugin updates, no cache files.

Step 4: Fix the owner and permissions

Code:

chown -R moved3449:moved3449 /home/moved.cyber.adminslab.com/public_html

After that the website user could write again (see above). But look at

Code:

public_html

itself. Because our archive contained the folder

Code:

.

, extracting it replaced CyberPanel's permissions on

Code:

public_html

with the ones from the old server:
What the archive did to public_html:
[Image: attachment.php?aid=623]

Code:

drwxr-xr-x

(755) means every user on the server can read the folder, including

Code:

wp-config.php

with the database password. CyberPanel creates it as

Code:

750

with group

Code:

nogroup

, so only the site user and the web server get in. Put that back:

Code:

chown moved3449:nogroup /home/moved.cyber.adminslab.com/public_html
chmod 750 /home/moved.cyber.adminslab.com/public_html

Back to CyberPanel's default:
[Image: attachment.php?aid=624]

Static files (CSS) still answered with 200 afterwards, so the web server could still read everything.

Step 5: New database details and the new URL
Run WP-CLI as the website's user (

Code:

sudo -u USER -H wp

), so the files it changes keep the right owner:

Code:

W="sudo -u moved3449 -H wp"
$W config set DB_NAME moved_wp
$W config set DB_USER moved_wp
$W config set DB_PASSWORD 'YOUR-DB-PASSWORD' --quiet
$W config set DB_HOST localhost

If the domain changes too, replace it everywhere in the database. Don't do this with a text editor on the SQL file: WordPress stores some settings as serialized PHP data, and changing the length of a URL inside it breaks them.

Code:

wp search-replace

handles that:

Code:

$W search-replace https://old-domain.com https://new-domain.com --skip-columns=guid --report-changed-only

New database details, then the URL change:
[Image: attachment.php?aid=625]

5 replacements in our small test site; a real site has hundreds or thousands.

Code:

--skip-columns=guid

leaves the post IDs for feed readers alone. Moving to the same domain? Skip the search-replace.

Step 6: Clear LiteSpeed Cache (the old domain was still there)
After all that, the homepage still had 30 links to the old domain. The response header said

Code:

x-litespeed-cache: hit

: OpenLiteSpeed served a page the LiteSpeed Cache plugin had stored before the move. Purge it:

Code:

$W litespeed-purge all

The old page came from the cache:
[Image: attachment.php?aid=626]

0 old links, 29 new ones. Any other cache plugin (WP Rocket, W3 Total Cache) or a CDN like Cloudflare needs the same purge.

Step 7: Go live

Test before you change DNS: add
Code:
YOUR-SERVER-IP new-domain.com
to the hosts file on your PC, then click through the site and log in to wp-admin.
Point the domain's A record to the new server.
Issue SSL in CyberPanel once DNS has switched (with Cloudflare: DNS only while issuing).
Re-save Settings > Permalinks once if inner pages show 404.
Delete
Code:
/root/move
on both servers; it holds a full copy of your database.

Quick fixes

Error establishing a database connection: wrong DB name, user, password or host in
Code:
wp-config.php
. See our separate guide on that error.
Uploads or updates fail, "Could not create directory": owner not fixed (Step 4).
Site redirects to the old domain: search-replace missing or cache not purged (Steps 5 and 6).

More CyberPanel guides

Tested on CyberPanel 3.0 with OpenLiteSpeed, MariaDB 10.11 and WP-CLI 2.12.0 on Ubuntu 24.04, moving a WordPress 7.1 site with LiteSpeed Cache, October 2026.