Please! Someone help me migrate a WordPress site via FTP!

Mac
1

I need help moving my WordPress site to a new hosting account using FTP. I copied the files, but now the website is showing errors and some pages will not load correctly. I’m not sure if I missed a file, database step, or configuration setting, and I need guidance to complete the WordPress site migration without breaking the site further.

2

I moved a WordPress site to a different host last week and skipped the migration plugin route. I’ve had plugins freeze on big sites, or choke on giant media folders, so I went old school with FTP and a manual database move. It looks messy at first. It wasn’t too bad once I did it in order.

If you want the short version, you’re moving two things. Site files, and the database. Miss either one and the site won’t load right.

Pick an FTP app first

You need something to pull files down from the old server and push them up to the new one. A few common options:

  1. FileZilla: Free, cross-platform, easy enough. I used it for years. My only gripe is file-heavy WordPress installs feel slow, esp with tons of tiny cache files and uploads.
  2. Commander One: Mac-only. Paid. Feels better if you do this more than once in a blue moon. Archive support helps when you want to zip stuff before transfer.
  3. Cyberduck: Free and open source. Some people like it. I had a couple weird moments with file operations, so I don’t reach for it first.
  4. CloudMounter: Good for people who hate dedicated FTP interfaces. It mounts the server like a local drive, so moving files feels more normal in Finder or File Explorer.

Step 1, export the old database

While the files are downloading over FTP, do the database part in parallel and save some time.

  1. Sign in to your old host’s cPanel.
  2. Open phpMyAdmin.

Grab a Good FTP Client
Grab a Good FTP Client1536×870 145 KB

  1. In the left sidebar, click the database tied to your WordPress install.
  2. Hit the Export tab.
  3. Leave it on Quick and SQL if you don’t need anything fancy.
  4. Click Go and save the downloaded .sql file somewhere you won’t lose it.

I usually toss a copy into a backup folder right away because I’ve misplaced one before and had to redo the export. Annoying.

Step 2, create a database on the new host

Now set up the destination.

  1. Log in to the new hosting account and open the MySQL Databases area, or MariaDB if your host labels it that way.
  2. Create a new database.
  3. Create a database user with a strong password.

Step 1: Export Your Database
Step 1: Export Your Database1536×870 145 KB

  1. Add the user to the database.
  2. Give the user All Privileges.
  3. Write down the database name, username, and password. If you fat-finger one of these later in wp-config.php, WordPress throws the usual database connection error and you waste 15 minutes checking the wrong thing. Ask me how I know.

Step 3, upload the WordPress files

This is the bulky part.

  1. Connect your FTP app to the new server.
  2. Go to the site directory. On many shared hosts, that’s public_html.
  3. Upload the files you downloaded from the old host.
  4. Keep your local copy until the new site is fully working.

If the site is huge, I’d check whether your host offers file manager zip upload or SSH. FTP works, but on some hosts it drags.

Step 4, edit wp-config.php

The files are there, but WordPress still points at the old database settings unless you change them.

  1. Find wp-config.php in the site root through FTP.
  2. Open it in a text editor.
  3. Replace DB_NAME with the new database name.
  4. Replace DB_USER with the new database username.
  5. Replace DB_PASSWORD with the new password.
  6. Save the file and upload it back, overwriting the old copy.

If your host uses a different database server name, check DB_HOST too. A lot of hosts leave it as localhost, but not all. This trips people up more than it should.

Step 5, import the SQL file

At this point, you have the file structure in place and a blank database waiting on the new host.

  1. Open phpMyAdmin on the new host.
  2. Select the database you created.
  3. Click Import.
  4. Choose the SQL file from your computer.
  5. Leave format set to SQL.
  6. Click Go.

If the import dies on a timeout, the database is likely too big for the web uploader. I’ve had hosts import it through SSH or command line when phpMyAdmin tapped out. If you hit that wall, ask support instead of retrying the same upload six times like I did.

Step 6, fix URLs if the domain changed

If the domain name changed during the move, old links inside the database still point to the previous URL. Images break, internal links go weird, and serialized data gets ugly if you do a sloppy replace.

I usually use the Search Replace DB script from GitHub. Upload it into a temporary folder, run the old-to-new URL replacement, verify the results, then delete the script right away. Don’t leave it sitting there. Seriously, remove it as soon as you’re done.

After that, the site should load from the new server. I’d still click around the homepage, a few posts, the media library, and the admin area before calling it done. Last time I did this, everything looked fine until I noticed broken image paths on two old blog posts. So yeah, test more than the front page.

3

If files are already copied, I’d stop looking for one missing file first. Most broken manual moves come from 3 places.

  1. Wrong wp-config.php values.
    Check DB_NAME, DB_USER, DB_PASSWORD, DB_HOST. New hosts often change the database prefix too. If the tables in phpMyAdmin start with wp7x_ and your wp-config.php says $table_prefix = ‘wp_’, pages break fast.

  2. Bad site URL values.
    If the domain or temp URL changed, login paths, images, and some pages fail. Check siteurl and home in the wp_options table on the new host. Those two values need to match the address you are loading.

  3. Serialized data issues.
    I disagree a bit with @mikeappsreviewer on using search-replace scripts as the first fix. They work, but they also create cleanup risk. I’d start with WP-CLI search-replace if your host gives shell access. It handles serialized data right.

Also check .htaccess. A bad rewrite file causes 404s on inner pages while the homepage still loads. Rename it, log into wp-admin, then resave Permalinks.

If images are missing, compare wp-content/uploads on old vs new. FTP skips files sometiems on huge transfers. Commander One is solid on Mac for rechecking folder counts and syncing diffs. File count mismatches are a big clue.

One more thing. Turn off all plugins by renaming wp-content/plugins. If pages load, a plugin path or server version issue is the problm.

4

If files are already on the new host, I’d troubleshoot before re-copying everything. @mikeappsreviewer covered the file/database split, and @nachtschatten is right about wp-config.php and .htaccess, but I’d also check server environment stuff because that gets missed a lot.

A few things that break manual FTP moves:

  • PHP version mismatch. Old host on 7.4, new host on 8.1 or 8.2, and suddenly themes/plugins throw fatal errors.
  • File permissions. Usually folders 755, files 644. Wrong perms can make pages half-load or block uploads.
  • Missing hidden files. Some FTP apps skip dotfiles, so .htaccess may never have transferred.
  • Corrupt/incomplete transfer in wp-content, esp uploads or plugin folders.

If you can, turn on debugging in wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Then check /wp-content/debug.log. That often tells you the exact plugin, theme file, or PHP function causing the mess.

Also, don’t use the host’s temporary URL for testing unless you have to. WordPress hates that more often than peple admit. Better to edit your local hosts file and preview the site on the real domain pointed to the new server.

If you’re on Mac, Commander One is actually handy here, not just for transfer but for comparing local vs server folders and spotting skipped files fast. FTP can be annoyng with giant media libraries.

So my order would be:

  1. Check wp-config.php
  2. Confirm DB imported fully
  3. Verify siteurl/home
  4. Re-save permalinks
  5. Check PHP version
  6. Enable debug log
  7. Compare uploads, plugins, and hidden files

Post the exact error message if you have one. “Showing errors” can mean like 12 diffrent things in WordPress.

5

I’d check one thing none of the others really stressed: the database charset/collation and mixed-content/caching leftovers.

If the move mostly works but random pages fail, forms act weird, or some text looks broken, compare the old and new DB collation in phpMyAdmin. A bad import into a different MySQL/MariaDB setup can cause odd behavior without a full crash.

Also clear any server cache, plugin cache, CDN cache, and browser cache. Manual moves often look broken because you’re seeing cached old paths.

I slightly disagree with going straight to plugin renaming unless you already have clues. First, inspect the server error log in hosting control panel. It’s often faster than blind toggling.

Quick checks:

  • confirm open_basedir or ModSecurity isn’t blocking files
  • verify SSL is installed if the old site forced HTTPS
  • check hardcoded paths in wp-config.php, theme functions.php, or plugin settings
  • resave your theme options if the builder stores asset paths separately

If you need to compare folders visually, Commander One is useful. Pros: dual-pane sync, easier folder diffing, good for spotting skipped uploads. Cons: Mac-only, not everyone needs a paid file manager for a one-off migration.

@nachtschatten, @chasseurdetoiles, and @mikeappsreviewer covered the core migration steps already. At this point I’d focus less on “missing file?” and more on “what is the server specifically rejecting?”