When you want to move a website entirely by hand — no plugin, no host doing it for you — you need to understand the actual mechanics: what a website is made of, how you copy each part, and how you reconnect them on the new server. The manual method is the most hands-on route, but it is also the one that teaches you what every migration is really doing, and it works for any site, any host, with no size limits or tool dependencies. This is that method, laid out step by step.

This cornerstone guide walks the full manual migration end to end: understanding the two components (files and database), backing up first, moving the files, moving the database, reconnecting and configuring on the new host, and testing before the cutover. By the end you will be able to migrate a website by hand with confidence, and understand precisely what plugins and host services automate on your behalf.

The two components you’re moving

Every website — whether it runs WordPress, another system, or hand-coded pages — comes down to at most two components, and a manual migration is simply moving both. The first is the files: everything that makes up the site’s code, design, and media, stored as files on the server. The second, for any dynamic site, is the database: the store of content and settings the code reads from.

A purely static site (plain HTML, CSS, images) has only the files and no database, which makes it the simplest possible migration — you just copy the files across. A dynamic site (WordPress, most content-managed or app-driven sites) has both, and the migration involves copying the files, copying the database, and reconnecting the two on the new server so the code knows where to find its data.

So the whole manual migration is organised around these two components: move the files, move the database, reconnect them. Everything in the steps below is one of those three things, plus the surrounding safeguards of backing up and testing. Holding this two-component picture in mind makes every step legible — you always know whether you are dealing with files, the database, or the connection between them.

Step 1: back up everything first

Before you move anything, make a complete backup of both components — all the files and the full database — and confirm it is genuinely restorable. This is the non-negotiable first step of any migration, manual or otherwise, because it is your safety net: if anything goes wrong at any point in the move, you can restore to exactly where you started and try again.

In a manual migration, this backup happens naturally as part of the process, because the first thing you do is download all the files and export the database — which together are a full backup. But treat it deliberately: keep that downloaded copy safe and untouched as your restore point, separate from the working copies you will upload to the new host. Do not begin altering anything until you have this in hand.

So back up first, always, and verify it. A manual migration gives you the backup as a by-product of downloading everything, but the discipline is to recognise that copy as your safety net and guard it. With a verified backup secured, every subsequent step is reversible — the single most important thing that turns a manual migration from a nerve-wracking gamble into a controlled, low-risk procedure.

Step 2: move the files

The first component to move is the files. You download the entire site’s files from the old host — connecting via FTP with an FTP client, or using the host’s file manager — copying everything in the site’s web directory to your computer. This includes all code, themes or templates, and the media/uploads folder, which is often the bulk of the data.

Then you upload those same files to the new host’s web directory, in the same structure. On a large site, or one with thousands of files, downloading and re-uploading individually over FTP can be slow, so a common shortcut is to compress the files into a single archive on the old server (if the host allows), download that one file, upload it to the new host, and extract it there — far faster than moving files one by one.

So moving the files is a download-then-upload of the whole site directory, ideally via a compressed archive for speed. Once complete, an exact copy of your site’s files sits on the new host. For a static site with no database, this is essentially the whole migration (bar testing and cutover). For a dynamic site, the files are now in place, and you turn to the second component: the database.

Step 3: move the database

For a dynamic site, the second component is the database, which you move by exporting it from the old host and importing it into a new database on the new host. On the old host, you use phpMyAdmin (the standard database tool in most control panels) to export the database to a .sql file — a complete dump of all your content and settings.

On the new host, you first create a new, empty database along with a database user and password (noting these credentials down, as you will need them to reconnect). Then you import your .sql file into that new empty database using phpMyAdmin on the new host, which recreates all your tables and data on the new server. The database now exists on the new host, holding all your content exactly as before.

So moving the database is export-to-a-file then import-into-a-new-database, mirroring the download-then-upload of the files. After this step, both components exist on the new host — the files in the web directory and the data in the new database — but they are not yet talking to each other. Connecting them is the pivotal next step that turns two copied components into a working site.

Step 4: reconnect and configure

With both components on the new host, you reconnect them by telling the site’s code where to find its new database. For WordPress this means editing the wp-config.php file with the new database’s name, username, and password; for other systems it is the equivalent configuration file. This single reconnection is what brings the copied site to life on the new server.

• Update the database credentials: point the site’s config file at the new database name, user, and password.
• Fix stored URLs: run a safe search-and-replace on the database if the domain or paths changed, so nothing points back at the old location (handle serialised data carefully).
• Set file permissions: ensure files and folders have correct permissions so the site can read and write as needed.
• Carry over config: replicate any special server settings (redirect rules, PHP settings) the site relied on.

These four configuration tasks assemble the two copied components into a functioning site on the new host. The database reconnection is the core; the URL search-and-replace prevents the migrated site pointing back at the old host for images and links; correct permissions let the site operate; and carrying over any special settings preserves behaviour. Once done, the site should run on the new host — though your domain still points to the old one, so only you can see it, which is exactly the safety you want for testing.

Step 5: test before the cutover

With the site assembled on the new host but your domain still resolving to the old one, you have a private window to test the migrated copy before any visitor sees it — and you must use it. Because your domain points to the old host, you preview the new site specifically by editing your computer’s hosts file to map your domain to the new server’s IP (so only your machine sees the new site), or by using a temporary URL the host provides.

Then click through the migrated site thoroughly: check pages load with correct content, images and styling appear (missing images usually mean an unfinished URL search-and-replace), internal links work, forms submit, logins function, and any dynamic features behave. Any problem you find here — a database-connection error from wrong config credentials, broken styling, missing media — is fixed with zero public impact, because the world is still being served the old site.

So test privately and thoroughly before cutover, because this is the step that guarantees the switch is safe. Once the migrated site is confirmed genuinely working on the new host, you complete the migration exactly as any migration ends: cut over by updating your domain’s DNS to the new host, keep the old host running through propagation so no visitor meets a gap, re-verify on the live site, and retire the old host only after a few stable days. The manual method’s steps — back up, move files, move database, reconnect, test, switch — are the complete anatomy of a website migration, done by your own hand.

FAQs

How do I migrate a website manually?

Move its two components by hand: back up everything first, download the files (via FTP or a compressed archive) and upload them to the new host, export the database with phpMyAdmin and import it into a new database on the new host, reconnect by editing the site’s config file (wp-config.php for WordPress) with the new database credentials, fix stored URLs with a safe search-and-replace, test privately, then cut over DNS and retire the old host last.

What are the two parts of a website I need to move?

The files (all code, themes/templates, and media/uploads stored on the server) and, for a dynamic site, the database (the store of content and settings the code reads). A static HTML site has only files — the simplest migration. A dynamic site like WordPress has both, so you copy the files, copy the database, and reconnect them on the new server.

Do I need to back up before a manual migration?

Yes, always — and verify it’s restorable. In a manual migration the backup comes naturally, since you download all the files and export the database as your first steps, and those together are a full backup. Keep that copy safe and untouched as your restore point. With a verified backup, every later step is reversible, which is what makes the migration low-risk.

How do I reconnect the site to its database on the new host?

Edit the site’s configuration file — wp-config.php for WordPress, or the equivalent for other systems — with the new database’s name, username, and password, so the code knows where to find its data on the new server. This reconnection brings the copied site to life. A wrong value causes a database-connection error, so double-check the credentials against the new database.

Why do images or links break after a manual migration?

Usually because URLs stored in the database still point at the old location, so you need a search-and-replace to update them to the new one — using a tool that handles serialised data safely, not a blind find-and-replace. Broken styling or missing images right after a move is the classic sign of an unfinished URL search-and-replace. For a same-domain host move it may be minimal, but always check.

When is a manual migration the right choice?

When you want full control, are moving a site a plugin can’t handle (very large, unusual setup, or non-WordPress), or want to understand exactly what’s happening — since plugins and host services simply automate these same steps. It has no size limits and no tool dependency, making it the reliable fallback that always works. For a simple site, a plugin or free host migration is easier.

The bottom line

A manual website migration is the complete, tool-free anatomy of moving a site, and it is organised entirely around the two components every website is made of: the files (code, design, and media) and, for a dynamic site, the database (content and settings). The method is a clear sequence built on that structure. First, back up everything and verify it — which in a manual move happens naturally as you download the files and export the database, giving you a full restore point to guard. Then move the files by downloading and re-uploading the whole web directory, ideally as a single compressed archive for speed. Then move the database by exporting it from the old host to a .sql file and importing it into a new, empty database on the new host.

With both components copied across, you reconnect them — the pivotal step — by editing the site’s config file (wp-config.php for WordPress) with the new database credentials, then fixing any stored URLs with a safe search-and-replace, setting correct file permissions, and carrying over any special server settings. Finally, because your domain still points to the old host, you test the assembled site privately via a hosts-file preview before any visitor sees it, catching problems with zero public impact, and only then cut over DNS, keep the old host alive through propagation, re-verify, and retire the old host last. Back up, move files, move database, reconnect, test, switch: that six-beat rhythm is what every plugin and host service automates, and doing it by hand once means you can move any site, on any host, with no tool and no size limit — the reliable method that always works.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. Manual website migration moves the two components by hand: back up first, download files (FTP or a compressed archive) and upload to the new host, export the database with phpMyAdmin and import into a new database, reconnect via the config file (wp-config.php) with the new credentials, fix stored URLs with a safe search-and-replace, set permissions, test privately, then cut over DNS and retire the old host last. It’s what every tool automates.