How to Migrate a WordPress Site Manually

Moving a WordPress site manually is one of those jobs that looks simple until a lead form stops sending, a redirect breaks, or Google begins indexing staging URLs. The files are only one part of the business asset. Your database, media library, SSL certificate, DNS records, analytics, CRM forms, email routing, search visibility, and conversion paths all need to arrive intact. This guide explains how to migrate a WordPress site manually with the controls a business owner or marketing leader should care about: preserving traffic, avoiding downtime, protecting pipeline, and knowing when a manual move is worth doing yourself.

A manual WordPress migration means moving the website files and database yourself instead of relying on a migration plugin or a host-managed transfer. In practical terms, you copy WordPress core files, themes, plugins, uploads, configuration files, and the MySQL or MariaDB database from the old server to the new one. Then you update the configuration, point the domain, install SSL, and test every important path.

That sounds technical because it is technical. But it is also a marketing operations task. A business website is not a brochure stored in a folder. It is usually connected to analytics tags, ad conversion tracking, HubSpot or another CRM, form notifications, scheduling tools, email delivery, cookie consent, live chat, payment systems, and search engine indexes. If any of those connections fail during the move, the site may look fine while revenue reporting quietly goes blind.

The benefit of a manual migration is control. You can inspect what moves, leave behind abandoned themes and unused plugins, verify database changes, and keep a documented rollback path. The downside is that you own the checklist. For a small brochure site, a plugin may be enough. For a lead-generating site with paid traffic, hundreds of indexed pages, or custom integrations, treating migration as a controlled release is usually the safer approach.

Manual migration is a good fit when the new host does not offer a reliable transfer service, when the site has custom code, when you need to clean up the installation during the move, or when you want to understand exactly what is happening. It is also useful when plugin-based migrations hit upload limits, time out on a large media library, or fail because of unusual server settings.

It is not automatically the right choice for every company. If your site is a standard WordPress installation with modest traffic and no complex integrations, a reputable host migration tool may reduce risk and save time. The goal is not to prove technical toughness. The goal is to preserve the commercial function of the site with the lowest reasonable risk.

Think about the cost of failure before selecting the method. If the website produces demo requests, ecommerce orders, appointment bookings, or organic leads every day, a few hours of broken forms can cost more than paying for experienced help. The same applies when a migration is paired with a redesign, a domain change, or a CMS cleanup. Combining too many major changes at once makes diagnosis much harder if rankings or conversion tracking drop.

Questions to Answer Before You Touch the Old Server

First, identify what is changing: hosting only, domain name, WordPress version, PHP version, theme, URL structure, or all of the above. A hosting-only move with the same domain is far less risky than moving to a new domain and redesigning the site in the same week. Separate projects wherever possible so you can tell which change caused a problem.

Second, inventory business-critical dependencies. List contact forms, CRM connections, SMTP settings, ecommerce payments, membership access, booking widgets, tracking tags, pixels, cookie banners, caches, CDN rules, DNS records, and email accounts. Include owners for each item. A developer may confirm that a page loads; marketing needs to confirm that a test lead reaches the CRM with the correct source data.

Third, establish a rollback point. Keep the old hosting active until the new site has passed functional, SEO, and reporting checks. Export backups to a location outside both servers. If the new environment fails, you want the option to repoint DNS rather than trying to repair a live incident under pressure.

Start with a written inventory, not a browser tab collection. Record the old host login, SFTP or SSH credentials, database credentials, WordPress administrator access, domain registrar access, DNS provider access, CDN access, and email platform access. Store credentials in an approved password manager and limit access to people who actually need it.

Next, crawl the current site with an SEO crawler and export the URL list, titles, meta descriptions, canonical tags, status codes, XML sitemap URLs, and internal links. This gives you a baseline for validation after launch. Google Search Console performance and index coverage data are also useful reference points, especially for pages that drive meaningful non-branded traffic.

Document current marketing measurements before the migration. Take screenshots or exports of recent leads, ecommerce conversions, paid-media conversions, and form completion data. If tracking changes during the move, you need a factual baseline. This is the difference between saying, “Traffic seems down,” and knowing whether traffic, form delivery, attribution, or actual demand changed.

Protect SEO Signals and Conversion Paths

For a like-for-like hosting migration, URLs should remain identical. That means the same protocol, hostname, permalink structure, trailing slash behavior, and page paths. The fewer public URL changes you make, the fewer redirects and indexing risks you create. Avoid changing categories, slugs, and navigation simply because the team has access to the site.

Export existing redirects from your old server, redirect plugin, CDN, or SEO plugin. These rules often contain years of accumulated fixes from deleted pages, campaign URLs, old product names, and prior site changes. Losing them can produce a sudden wave of 404 errors and waste hard-earned backlinks.

Also identify every high-intent conversion route: contact page, demo page, quote form, booking page, checkout, thank-you page, and downloadable asset. Test these routes manually after the move. A landing page can retain its rankings while becoming commercially useless if the form action, confirmation page, or CRM integration has changed.

Your WordPress site has two core parts: files and database content. Files include WordPress itself, installed themes and plugins, uploaded images, PDFs, and custom code. The database contains posts, pages, users, settings, menus, form configuration, plugin data, and much more. You need both for a complete migration.

Use SFTP, SSH, or your host file manager to download the entire WordPress directory. Pay particular attention to the wp-content folder because it contains themes, plugins, uploads, cache directories, and often custom integrations. Include hidden files such as .htaccess, which may contain redirect rules, security controls, and permalink logic.

Then export the database through phpMyAdmin, a hosting control panel, or a command-line tool such as mysqldump. Save the export as an SQL file and label it with the site name and date. Do not assume one backup is enough. Create a second copy in separate storage, and confirm that the export is not an empty file or a partial download.

Check for Large Files, Custom Code, and Environment Settings

Large media libraries are a common reason manual migrations stall. Before transfer, identify unusually large folders such as wp-content/uploads, backup archives stored inside WordPress, cache folders, and old staging copies. There is no value in moving several obsolete backup files to a new server if they add hours to the transfer and consume storage.

Look for custom functionality in the child theme, mu-plugins directory, wp-config.php file, server cron jobs, and external scripts. Some plugins depend on absolute server paths or environment-specific settings. A move to a different host may require changes to PHP memory limits, upload limits, cron configuration, file permissions, or outbound email settings.

Make a note of the active PHP version and key server settings before migration. An old site may run on a version that the new host does not support, while an outdated plugin may fail on a newer version. Test compatibility in a staging environment rather than discovering the conflict after DNS is live.

Create the destination database and database user on the new host. Grant the user full permissions for that database, then record the database name, username, password, and host value. Some hosts use localhost; others provide a specific database server address. A single incorrect character in these settings can produce the familiar “Error establishing a database connection” message.

Upload the WordPress files to the correct web root on the new host. This might be public_html, www, httpdocs, or another directory depending on the provider. Confirm that the domain is mapped to the folder containing index.php and wp-config.php. If the document root is wrong, you may see a directory listing, a default host page, or an unrelated installation.

Before importing the database, set up a staging URL, temporary domain, or local hosts-file preview if possible. The point is to inspect the new copy before public DNS changes. Keep search engines away from a staging site using password protection or noindex controls, but do not rely on noindex alone for sensitive environments.

Import the SQL file into the destination database through phpMyAdmin or a database command-line tool. Larger databases may exceed web upload limits, in which case SSH import is often more reliable. Watch for import errors, especially character set issues, duplicate tables, or timeouts. If you are importing into a database that already has tables, clear the destination first unless you deliberately need a shared setup.

Update wp-config.php with the new database name, username, password, and host. Also review any custom constants in that file, including WP_HOME, WP_SITEURL, memory settings, cache flags, debugging controls, and third-party API settings. Hard-coded old URLs are a frequent cause of login redirects and unexpected behavior after migration.

If the domain is changing, perform a careful database search-and-replace for the old URL and new URL. Do not use a basic text editor on an SQL file if you are not certain how WordPress serialized data works. Serialized values can break when string lengths change. Use a serialization-aware tool such as WP-CLI search-replace or a well-tested database migration utility, and always run a dry test or retain a backup first.

Handle URLs, SSL, and Mixed Content Carefully

Once the new site is reachable, install and validate an SSL certificate before sending public traffic to it. Your canonical URL should resolve consistently over HTTPS. Check both www and non-www versions and choose the existing preferred version unless you have a specific reason to change it.

Mixed content occurs when an HTTPS page still requests scripts, images, fonts, or stylesheets over HTTP. Browsers may block those assets, leaving the page visually broken or functions partially disabled. Use browser developer tools and a site crawl to find these requests, then update source URLs where needed.

Review redirect behavior at the server and CDN levels. You want one clean redirect from HTTP to HTTPS and one clean hostname policy, not a sequence of hops through several versions of the domain. Redirect chains slow users down and can complicate crawling. Test important old URLs directly, not only the homepage.

Preview the new environment using the temporary URL, staging domain, or hosts-file method. Begin with basic checks: homepage, primary navigation, mobile layout, internal search, major landing pages, blog posts, media files, and the WordPress admin area. Then inspect errors in the browser console and server logs.

Run transaction tests next. Submit every important form with a controlled test email, make a test booking where possible, run a test purchase in a safe payment mode, and confirm thank-you pages load. Check that notifications arrive, that CRM records are created, and that lead source fields are preserved. This is where many migrations fail despite appearing successful to a casual reviewer.

Marketing infrastructure deserves its own review. Confirm Google Analytics, Google Tag Manager, ad pixels, consent controls, call tracking, chat, heatmaps, and conversion events. If your business depends on clean lifecycle reporting, verify that the website-to-CRM handoff still works. A properly configured CRM implementation is only useful if forms, attribution fields, and follow-up workflows survive platform changes.

When the staging checks pass, lower DNS TTL values in advance if your provider allows it. This can reduce the time it takes for record changes to propagate, although propagation is never perfectly instant across every network. Schedule the switch during a lower-risk period for your business, but make sure someone can monitor the result.

Update the A record, CNAME, or nameserver configuration according to the new host’s instructions. Be cautious when changing nameservers: that can affect email records, verification records, and other DNS entries beyond the website. If possible, copy all existing DNS records before making the change and compare the new zone afterward.

Keep the old host running for several days after launch. During that time, monitor uptime, page behavior, form delivery, server errors, and traffic. Do not cancel the old account as soon as the homepage appears on the new server. A rollback plan is only real while the previous environment remains available.

After DNS resolves, crawl the live site again and compare it with your pre-migration crawl. Look for 404 pages, unexpected noindex tags, missing canonicals, broken internal links, redirected images, and altered page titles. Confirm that the XML sitemap is available and that robots.txt has not inherited a staging block.

Use Google Search Console to monitor indexing, crawl issues, and performance over the next few weeks. A like-for-like hosting move should not require a change-of-address request because the domain is unchanged. If the domain changed, that is a separate SEO migration with redirect mapping and Search Console work that should be planned carefully.

For businesses publishing content consistently, migration is a good time to make ownership clear. Content, technical SEO, conversion paths, and reporting should not sit in separate silos when one change can affect all four. Teams using AI SEO content systems should also protect publishing workflows, schema, internal linking rules, and analytics events during a platform move.

The most common mistake is treating a site migration as a file transfer rather than a business continuity project. Files move, pages load, and everyone assumes the job is finished. Then the sales team notices that leads are missing because the SMTP credentials were not copied, the CRM webhook was blocked, or a consent platform prevented tracking scripts from firing.

Another costly mistake is allowing staging pages to be indexed. Password protection, noindex tags, and robots rules should be applied before the staging site is publicly accessible. Equally risky is forgetting to remove noindex directives after launch. Both mistakes can reduce organic visibility, but one creates duplicate content while the other hides the new site from search engines.

Finally, avoid using the migration as an excuse for unplanned redesign work. New templates, new URLs, new copy, a new domain, and new tracking setup can all be valid projects. They should not be bundled into a hosting move without a disciplined plan. If organic visibility is a meaningful acquisition channel, review the work with the same care you would give a major paid campaign launch.

Keep a manual migration in-house when you have a technically capable owner, a straightforward site, documented integrations, and enough time to test without rushing. Assign one person to coordinate the release and another to validate marketing outcomes. Even a small move benefits from clear accountability.

Bring in specialist support when the site drives material revenue, has custom development, runs paid media to landing pages, connects to a CRM, handles ecommerce, or carries substantial organic traffic. The cost question is not only what a migration provider charges. It is also what a tracking outage, lost form submissions, or prolonged ranking decline could cost the business.

This is where an operator model can be more practical than routing the issue through several agency departments. Anton Chisliuk · AI Marketing Ops combines website, SEO, CRM, and automation work under one senior operator, so migration checks can follow the actual customer journey rather than a generic development checklist. The approach is grounded in operating outcomes: for example, Cleverence grew from zero to 80K organic visits per month and 2K inbound leads per month. You can learn how the business is structured on the Anton Chisliuk · AI Marketing Ops company page.

For the first 24 hours, monitor site availability, server error logs, form submissions, ecommerce events, and major landing pages. Check the site from different networks and devices because DNS caching can make the launch appear inconsistent. Review real user behavior, not just administrator access.

For the first seven days, compare daily traffic and conversions against a relevant baseline. Some variation is normal, especially around weekends or campaigns. What matters is identifying unexplained gaps: a landing page receiving traffic with no conversions, a sudden rise in 404s, or a drop in tracked sessions that does not match ad platform clicks.

For the first month, watch Search Console trends, keyword visibility, crawl errors, Core Web Vitals, and the status of redirected legacy URLs. Keep a simple migration log with changes made and issues resolved. That documentation becomes valuable when future developers, marketers, or vendors need to understand why a particular redirect or configuration exists.

A manual WordPress migration can be controlled, clean, and low-risk when you treat it as more than a hosting task. Back up files and database, preserve URLs and redirects, test every conversion route, verify analytics and CRM handoffs, switch DNS with a rollback option, and monitor the site after launch. The technical move matters, but the business continuity checks matter more.

If your WordPress site supports a meaningful pipeline and you need an outside set of experienced eyes before moving it, start with a Growth Audit to identify website, SEO, CRM, and tracking risks before they become launch-day surprises.

This guide was prepared in the operator-led style used by Anton Chisliuk: connect the technical change to the pipeline it is meant to support.

- Can I migrate a WordPress site manually without a plugin?

Yes. You can download the WordPress files, export the database, upload both to the new host, update wp-config.php, and test the site before changing DNS. The process requires careful handling of URLs, database data, SSL, and integrations, but a plugin is not required.

- How long does a manual WordPress migration take?

A basic site can take a few hours when access, backups, and hosting are ready. Larger sites with extensive media, ecommerce, custom code, CRM connections, or SEO requirements can take longer because testing is the real work. Plan for validation time, not only transfer time.

- Will migrating WordPress hurt SEO?

A like-for-like hosting move should not inherently hurt SEO if URLs, content, redirects, canonical tags, crawl settings, and server performance remain stable. SEO problems usually come from accidental URL changes, lost redirects, staging blocks, duplicate pages, or broken internal links.

- Do I need to change DNS when moving WordPress to a new host?

Usually, yes. You need to point the domain to the new server through an A record, CNAME, or nameserver change. Before changing DNS, copy existing records and check email-related records so the website move does not interrupt business email or domain verification services.

- What should I test after a WordPress migration?

Test page loading, mobile behavior, navigation, logins, forms, booking flows, checkout, email notifications, CRM record creation, analytics, ad conversion tracking, redirects, sitemap access, robots.txt, and SSL behavior. Prioritize the pages and actions that produce leads or revenue.