{"id":148,"date":"2026-06-06T09:01:00","date_gmt":"2026-06-06T09:01:00","guid":{"rendered":"https:\/\/blog.offshorekaka.in\/?p=148"},"modified":"2026-08-27T05:39:06","modified_gmt":"2026-08-27T05:39:06","slug":"how-to-migrate-wordpress-to-offshore-hosting","status":"publish","type":"post","link":"https:\/\/offshorekaka.in\/blog\/how-to-migrate-wordpress-to-offshore-hosting\/","title":{"rendered":"How to Migrate WordPress to Offshore Hosting Safely"},"content":{"rendered":"
\n

Tutorial<\/span><\/p>\n

Copy first, switch last<\/h2>\n

A WordPress migration is four things: the files, the database, the config, and the URLs inside the database. Get all four right on the new server before you change DNS, and the switch itself is a non-event.<\/p>\n

The step people forget is the fourth one. WordPress stores absolute URLs all over the database, including inside serialised PHP data, and a plain find and replace on the SQL file corrupts that data in ways that only show up later.<\/p>\n

\n
Time<\/strong>An hour for a normal site.<\/span><\/div>\n
Order<\/strong>Copy, test by IP, then DNS.<\/span><\/div>\n
Never<\/strong>sed the SQL file to change URLs.<\/span><\/div>\n<\/div>\n<\/div>\n
On this page<\/strong>Export from the old host<\/a>Import on the new one<\/a>wp-config.php<\/a>The URLs inside the database<\/a>Test before DNS<\/a>Switching over<\/a>FAQ<\/a><\/div>\n

Export from the old host<\/h2>\n

Two things come across: everything under the web root, and the database.<\/p>\n

tar czf site-files.tgz -C \/var\/www\/yourdomain.com .\nmysqldump --single-transaction --quick -u dbuser -p dbname > site.sql<\/code><\/pre>\n
\"Terminal
Check the size after the export. A dump of a few kilobytes means it failed and printed the error somewhere you did not look.<\/figcaption><\/figure>\n
If you only have cPanel and no SSH, use the File Manager to compress the folder and phpMyAdmin to export the database. Same result, more clicking.<\/p>\n
Skip the cache directory while you are at it. It can be gigabytes, it regenerates on its own, and stale cache files on the new server cause confusing behaviour:<\/p>\n
tar czf site-files.tgz --exclude='*\/cache\/*' -C \/var\/www\/yourdomain.com .<\/code><\/pre>\n
Import on the new one<\/h2>\n
Create the database and user first, then import:<\/p>\n
mysql -u root -p -e \"CREATE DATABASE newdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;\"\nmysql -u newuser -p newdb < site.sql<\/code><\/pre>\n
Extract the files, then set ownership. This is the step that causes the FTP credential prompt people spend an hour on:<\/p>\n
tar xzf site-files.tgz -C \/var\/www\/yourdomain.com\nchown -R www-data:www-data \/var\/www\/yourdomain.com<\/code><\/pre>\n
Use nginx<\/code> or apache<\/code> as the owner on the RHEL family.<\/p>\n
wp-config.php<\/h2>\n
Update the four database lines to match what you just created:<\/p>\n
define( 'DB_NAME', 'newdb' );\ndefine( 'DB_USER', 'newuser' );\ndefine( 'DB_PASSWORD', 'the-new-password' );\ndefine( 'DB_HOST', 'localhost' );<\/code><\/pre>\n
While you are in there, check the table prefix line matches the prefix in the dump. A site that was installed with a custom prefix and a wp-config.php<\/code> that says wp_<\/code> gives you a working database connection and an installation screen, which is a very confusing combination.<\/p>\n
The URLs inside the database<\/h2>\n
If the domain is not changing, skip this section entirely. If it is changing, this is the part that matters.<\/p>\n
Use WP-CLI, and run it with --dry-run<\/code> first:<\/p>\n
wp search-replace 'https:\/\/old-domain.com' 'https:\/\/yourdomain.com' --dry-run<\/code><\/pre>\n
\"WP-CLI
A dry run shows you the tables and counts before anything is written.<\/figcaption><\/figure>\n
WP-CLI unserialises PHP data, changes the string, and reserialises it correctly. A plain sed<\/code> on the SQL file changes the string but leaves the recorded string length wrong, so the data no longer unserialises. That breaks widgets, theme options and page builder layouts, usually a week later when you have forgotten what you changed.<\/p>\n
Run it for real once the dry run looks right, and do both the http and https variants of the old domain if the old site was ever served over plain HTTP.<\/p>\n
Test before DNS<\/h2>\n
Do not change DNS to find out whether the migration worked. Point your own machine at the new server by adding a line to your hosts file:<\/p>\n
203.0.113.10  yourdomain.com www.yourdomain.com<\/code><\/pre>\n
That is \/etc\/hosts<\/code> on Linux and macOS, or C:WindowsSystem32driversetchosts<\/code> on Windows. Now your browser sees the new server while everyone else still sees the old one.<\/p>\n
Walk the site properly. Homepage, a post, a category page, the search results, a contact form, and the dashboard. Log in and check that widgets and theme settings survived. Remove the hosts line when you are done.<\/p>\n
Switching over<\/h2>\n
    \n
  1. Lower the TTL a day ahead. See our DNS propagation guide<\/a>.<\/li>\n
  2. Do a final database export from the old site, so posts and orders from the last few hours come across.<\/li>\n
  3. Change the A record. Our domain pointing guide<\/a> covers the detail.<\/li>\n
  4. Issue the certificate on the new server once DNS resolves there.<\/li>\n
  5. Leave the old server running for 48 hours.<\/li>\n<\/ol>\n
    If the site takes orders or comments, put the old copy into read-only mode as soon as DNS changes, so nothing gets written to a database you are about to throw away.<\/p>\n
    How to test<\/h2>\n
      \n
    1. Homepage, a post, a category and a search result all load.<\/li>\n
    2. Images load, which proves uploads came across and permissions are right.<\/li>\n
    3. Log in to the dashboard.<\/li>\n
    4. Submit a contact form.<\/li>\n
    5. Check permalinks work on an inner page.<\/li>\n
    6. Check robots.txt does not disallow everything.<\/li>\n
    7. Confirm the certificate is valid.<\/li>\n<\/ol>\n
      When something breaks<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n
      What you see<\/th>\nWhy<\/th>\nFix<\/th>\n<\/tr>\n<\/thead>\n
      Error establishing a database connection<\/td>\nWrong credentials in wp-config.php<\/td>\nRecheck all four lines and the table prefix<\/td>\n<\/tr>\n
      Installation screen instead of your site<\/td>\nTable prefix does not match the dump<\/td>\nSet the correct prefix in wp-config.php<\/td>\n<\/tr>\n
      Homepage loads, everything else 404<\/td>\nRewrite rules missing on the new web server<\/td>\nAdd try_files<\/code> on nginx, or the rewrite rules on OpenLiteSpeed<\/td>\n<\/tr>\n
      Asks for FTP credentials on plugin install<\/td>\nFiles not owned by the web server user<\/td>\nchown -R<\/code> to the right user<\/td>\n<\/tr>\n
      Widgets and theme settings lost<\/td>\nURLs replaced with sed instead of WP-CLI<\/td>\nRestore the database and redo with search-replace<\/td>\n<\/tr>\n
      Images missing<\/td>\nUploads excluded, or wrong permissions<\/td>\nList the archive to confirm, then fix ownership<\/td>\n<\/tr>\n
      Mixed content warnings<\/td>\nOld http URLs still in the database<\/td>\nRun search-replace for http to https as well<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
      Checklist<\/h2>\n