How to Migrate WordPress Without FTP: 3 Reliable Methods

Yes, you can migrate a WordPress website without FTP. Use Migrate Guru for a cloud-assisted transfer, cPanel File Manager and phpMyAdmin for a manual browser-based move, or All-in-One WP Migration to export and import a single archive.

The right choice depends on your access, the destination's upload limits and whether the site accepts orders or other changes while you move it. Copying the site is only part of the job: you also need a backup, a way to test the destination, and a controlled DNS switch.

No FTP does not mean no backup. You may avoid downloading the migration files to your computer, but you should still keep an independent, recoverable copy of the site's files and database.

Which WordPress migration method should you choose?

Migrate Guru's official plugin listing gives the 200 GB figure. ServMask's current upload-limit explanation says All-in-One WP Migration reports the host's PHP limit, rather than imposing a fixed 512 MB ceiling.

For a large site with limited home internet bandwidth, start by checking whether Migrate Guru supports your setup. For a site that cannot use a cloud migration service, consider cPanel. For a manageable archive and generous upload limits, the single-file method is convenient.

Before you start: access, backup and compatibility

Have these details ready before copying anything:

• Source access: WordPress administrator access for the plugin methods, or the old hosting account's File Manager and database tools for the manual method.
• Destination access: the new hosting account, the correct domain document root, and permission to install plugins if needed.
• DNS access: the account that currently manages the domain's DNS records. It may be separate from your hosting or registrar.
• An independent backup: files and database from a matching point in time, stored away from the account you might cancel. Confirm how you would restore it.
• Storage headroom: space for the working site, archive and temporary extraction files. Check inode quotas as well as gigabytes.
• A compatible runtime: note PHP, database versions and required extensions. Test the existing theme and plugins on a supported destination runtime; a newer PHP version is not automatically compatible.
• A safe destination clone: before the restored copy first runs, have the host isolate live payment, email and fulfillment side effects and control scheduled jobs. A clone can inherit working production credentials.
• A list of services outside WordPress: mailboxes, server cron jobs, external databases, object storage, CDN settings, payment callbacks and DNS records may need separate work.

Check site size under Tools > Site Health > Info > Directories and Sizes, where available. Do not judge it only by the media library: databases, plugin storage and old backup folders can account for much of the total.

For a shop, booking system or membership site, arrange a final write freeze. Orders, uploads and registrations received after the initial copy will otherwise be missing from the destination. The cutover section below explains the sequence.

Scope: the manual instructions below cover a single WordPress installation. Multisite, domain mapping and extracting one subsite need a network-specific plan. Migrate Guru documents network migration support, but that does not make every multisite conversion equivalent to a single-site move.

Method 1: Migrate Guru without FTP or cPanel credentials

1. Prepare a reachable destination

Install a fresh WordPress site on the new hosting account. If you use Softaculous, follow our WordPress installation guide.

The destination should be disposable: migration can replace its content and users. Back it up first if it contains anything you need.

Ask the new host for a temporary hostname or another supported destination route if the public domain still points to the old server.

A hosts-file edit affects only your computer. It does not change how Migrate Guru's cloud servers resolve your domain. Being able to open the new site locally is not proof that the migration service can reach it.

2. Install Migrate Guru on both sites

On the source and destination, open Plugins > Add New, search for Migrate Guru, and install and activate the official plugin.

The vendor FAQ confirms that the destination needs WordPress and Migrate Guru. It also states that Migrate Guru does not create a backup.

3. Copy the destination key

Open Migrate Guru on the new site and use Copy Key or the equivalent migration-key control. Keep the key private and generate a fresh one if validation fails.

4. Start the transfer from the source

Open Migrate Guru on the old site. Confirm installation on both sites, paste the destination key, validate it, and check the source and destination addresses before initiating migration.

The current flow is documented in Kinsta's Migrate Guru instructions. Exact labels can vary by release or hosting integration; use “Other Host” only if your interface asks you to choose a provider.

5. Check completion and the resulting URL

Review the completion report and inspect the destination. If you used a temporary address, confirm which URL the migrated copy now uses. Before launch, convert temporary URLs to the final address using a serialized-data-aware tool, then test again.

The plugin FAQ currently describes a limit of five sites per user per month, with repeat moves of those sites allowed. This is more precise than saying only five migration runs are possible.

Key-based migration is the normal workflow; the vendor still describes FTP/cPanel details as a possible fallback. If you cannot use that fallback, ask support about the key connection or use another method. Keep a maintained plugin version rather than downgrading to reproduce an old tutorial.

Cloud processing reduces the need for local downloads. It does not guarantee an error-free transfer, an exact completion time or a lossless cutover while the source keeps changing.

Method 2: Migrate manually with cPanel File Manager and phpMyAdmin

This method uses your browser to move two things: the WordPress files and the matching database. You do not need to install a blank WordPress site first.

1. Confirm the source folder and database

Find the domain's document root in cPanel. It may be public_html, an addon-domain folder or another directory.

In that folder, inspect wp-config.php to identify DB_NAME and the table prefix. Keep database credentials private. If several sites share the hosting account, confirm that you are exporting the intended database.

2. Archive and download the files

In File Manager > Settings, enable Show Hidden Files (dotfiles). Include .htaccess and other required hidden files.

Select the site's files and folders, choose Compress, and create an archive. Store it outside the public document root where the host permits, then download it. Do not accidentally include an older archive or unrelated websites.

The File Manager documentation explains hidden files, compression, upload and extraction. ZIP support depends on the server configuration.

Treat the archive as sensitive: it can contain credentials and customer uploads. If you must create it in a public folder, remove that server copy promptly after verifying the download.

3. Export the database

Open phpMyAdmin, select the correct database, then Export. For a straightforward complete export, choose SQL and include all tables belonging to this installation.

A compressed SQL export can help with transfer size. For a very large or actively changing database, ask the host for a consistent export instead of relying on a browser operation that may time out.

A full cPanel account backup is a different package. The Backup Wizard documentation says full account restoration requires WHM or provider assistance; it is not the same as importing one WordPress database.

4. Create the destination database and import

Use cPanel's Database Wizard or Manage My Databases to create a database and a dedicated user. Grant that user the required privileges on this database only, and record the complete prefixed names.

Use phpMyAdmin to import into the new database. Select it first, open Import, choose the SQL or supported compressed SQL file, and wait for a successful result. phpMyAdmin documents both the import process and large-file constraints.

Do not create the database or user directly in phpMyAdmin: cPanel warns this bypasses its database mapping. If an import fails partway, resolve the cause and restart into a clean destination database rather than assuming the partial import is usable.

5. Upload and extract into the correct destination

Upload the archive through the new host's File Manager and extract it into the domain's document root.

Check that wp-admin, wp-content and wp-config.php are at the expected level. An extra enclosing folder can leave the domain showing a placeholder page.

Check files referenced outside this folder separately. A standard site archive will not automatically copy remote media, a database on another server or account-level scheduled tasks.

6. Update wp-config.php

Edit the destination copy with the new database details:

define( 'DB_NAME', 'newaccount_wpdb' );
define( 'DB_USER', 'newaccount_wpuser' );
define( 'DB_PASSWORD', 'REPLACE_WITH_YOUR_NEW_DATABASE_PASSWORD' );
define( 'DB_HOST', 'localhost' );

These are placeholders. Use the database hostname supplied by your new provider; it is not always localhost.

Keep $table_prefix consistent with the imported tables. Review old absolute paths, Redis/object-cache settings and host-specific PHP directives before testing. Do not solve ownership problems by making every file writable.

If the public URL, scheme and directory stay identical, changing hosts alone does not require a database-wide URL replacement. WordPress's migration handbook distinguishes that case from a domain or URL change.

Method 3: Export and import one .wpress file

Use this when both dashboards are available and the destination can accept the archive.

1. Install the official All-in-One WP Migration plugin on the source.
2. Open All-in-One WP Migration > Export > Export To > File.
3. Download the completed .wpress archive. Do not exclude media or database content unless you have a separate transfer plan.
4. Install a clean WordPress site and the same migration plugin at the destination.
5. Open Import > Import From > File and select the archive.
6. Read the overwrite warning, verify that this is the destination, and proceed.
7. After completion, log in using the source site's credentials. Follow the plugin's completion instructions for saving permalinks; ServMask's guide recommends saving twice.

The official user guide describes the archive, import and login behavior. A .wpress archive needs a compatible restore tool; do not assume it is a ZIP or that it is encrypted unless you explicitly configured encryption.

What if the archive exceeds the displayed limit?

Compare the Import screen with Tools > Site Health > Info > Server. Ask the host to check upload_max_filesize, post_max_size, web-server request limits, proxy/CDN limits and available resources.

The free plugin has no universal 512 MB import cap, according to ServMask's explanation. Increasing PHP limits can help, but a request may still be rejected by another layer. A supported extension or another migration route may be appropriate.

For stalled restores, also check free disk space, temporary storage, permissions and logs. ServMask's troubleshooting guide covers these requirements. An extension does not create missing disk space or make incompatible plugins work.

Changing domains or removing a temporary URL

When a domain, protocol or directory changes, old addresses can remain in content, widgets and plugin data. Changing Settings > General alone may not replace them all.

Use a serialized-data-aware replacement tool. A plain text replacement in an SQL dump can corrupt stored structures. Preserve post GUIDs, as WordPress's handbook instructs.

If your host offers a browser Terminal with WP-CLI, these are optional examples for a single site, run as its hosting user from the correct WordPress directory:

wp search-replace 'https://temp.example.net' 'https://example.com' --all-tables-with-prefix --skip-columns=guid --dry-run

Review the report and keep a database backup before applying:

wp search-replace 'https://temp.example.net' 'https://example.com' --all-tables-with-prefix --skip-columns=guid

Replace both URLs with your own. The WP-CLI reference documents serialized-data handling, dry runs and table scope. Confirm that the prefix belongs only to this installation; do not use an all-database replacement on a shared database.

Without Terminal access, ask the host to perform the replacement or use a maintained dashboard tool with serialization support and a preview. Regenerate page-builder CSS or caches where the builder requires it.

Test the destination before changing public DNS

For a manual or single-file move using the same domain, a temporary hosts-file entry can send your computer to the new server:

192.0.2.10 example.com www.example.com

The IP is an example. Substitute the actual destination IP. On Windows, edit C:\Windows\System32\drivers\etc\hosts with administrator privileges. On macOS and Linux, the file is /etc/hosts.

Confirm the new server is handling your requests using its access logs or a host-provided identifier. A cached page can make the old and new sites look identical.

Test valid HTTPS before entering passwords. A hosts-file entry does not install a certificate. Ask the host to provision a certificate through DNS validation, a secure preview hostname or another supported method. Do not treat a certificate warning as a passed HTTPS check.

Check these journeys:

• Homepage, inner pages, search, menus and a deliberate missing-page request.
• Media files, downloads, mobile layouts and any externally stored assets.
• Administrator and customer logins.
• Forms, with actual delivery to the intended test inbox.
• Cart, taxes, shipping and checkout in a safely isolated sandbox.
• Scheduled tasks, cache behavior, redirects and application error logs.

A local override cannot redirect a payment provider's webhook server. Plan external callback tests separately. Remove the hosts-file entry before checking the public DNS switch.

Switch DNS without losing new orders or registrations

A successful copy does not guarantee zero downtime or zero data loss. The following is an operational cutover plan; adapt it with your host for a busy transactional site.

1. Prepare DNS early. Record the current zone and old origin IP. If your DNS service allows it, lower the website record's TTL and wait at least the previous TTL before cutover. Lowering it at the last moment does not clear existing caches. Cloudflare explains how TTL affects caching.
2. Choose one source of truth. Pause content edits, uploads, registrations and checkout for the final copy. Include API writes, imports and background integrations; a visual maintenance page may not stop them.
3. Control duplicate side effects. Prevent the destination clone from sending live emails, charging subscriptions or running fulfillment integrations during testing. WooCommerce Subscriptions has staging detection rules, but a clone using the same domain may not be recognized as staging.
4. Take the final consistent copy. Transfer the latest database and any files changed since the rehearsal. Confirm recent orders, customer records and uploads are present. Do not assume the migration tool continuously synchronizes them.
5. Update the website's destination. Change the relevant A/AAAA records or CDN origin configuration. Check www and other served hostnames, and remove a stale IPv6 route if the destination does not support it. You usually do not need to change nameservers just to change web hosting.
6. Reopen writes only at the new origin. Confirm the new site is ready, restore its live integration settings and enable its intended scheduled jobs. Keep the old copy unable to accept writes. Visitors reaching the old server can see maintenance, or the host can arrange a tested proxy to the new origin.
7. Monitor both origins. Check traffic, errors, payment callbacks and order records. Keep old scheduled jobs from processing duplicate work.

Maintenance may last longer for visitors with cached DNS. A host-managed proxy or coordinated synchronization can reduce interruption, but the three transfer methods alone do not provide that coordination.

WordPress migration does not move mailboxes. Preserve MX, SPF, DKIM, DMARC and mail-host records as appropriate. If changing nameservers too, recreate the full zone and coordinate DNSSEC with the DNS providers. Our domain-to-hosting guide covers the connection basics.

Keep search visibility intact

For a hosting-only move, keep URLs, canonical tags, content and internal links consistent. Remove temporary staging authentication and indexing blocks from the public destination when ready. Monitor Search Console and server errors, following Google's hosting-change guidance.

For a domain or path change, map old URLs to their new equivalents with permanent redirects. Update internal links, canonical URLs and the sitemap; use Search Console's Change of Address when applicable. Google recommends keeping redirects generally at least one year in its site-move guidance. The old WordPress installation can be retired separately from the redirect service.

Common migration problems and what to check

Use logs to identify the failing component before making broad changes. Keep errors containing credentials or customer data out of public support posts.

Rollback and cleanup

Before cutover, record how to restore the previous DNS or CDN origin and where the matching backup is stored. Define what would trigger rollback, such as broken checkout or persistent server errors.

After the destination accepts new data, rollback needs reconciliation. Switching DNS back can strand new orders, users and uploads on the destination. Pause writes, preserve both copies, and have the host reconcile changes before choosing which database becomes authoritative.

Keep old hosting until traffic has drained, essential journeys pass and you have a recoverable backup. A fixed “24 hours” or “three days” rule is less useful than those checks.

Once stable:

• Remove public ZIP/SQL archives, temporary accounts and migration keys; retain private backups.
• Remove migration-only plugins when they are no longer needed.
• Confirm HTTPS, SMTP, server cron and application scheduled jobs.
• Set up backups on the new host and test restoration in a separate environment.
• Purge stale caches without caching private pages, carts or checkout.
• Cancel old hosting only after checking that email and other services no longer depend on it.

If you want help planning a move to Hostlelo, contact support through your Hostlelo account. Share the site size, access available, whether the domain is changing, and whether orders or memberships must remain active. Ask the team to confirm migration scope and timing before scheduling the cutover.