How I Migrated a Website to a New Server Without Losing Data – Part 1: Preparation & Backups

How I Migrated a Website to a New Server Without Losing Data – Part 1: Preparation & Backups

How I Migrated a Website to a New Server Without Losing Data – Part 1: Preparation & Backups

Moving a website to a new server can feel risky.


Your website may contain years of content, customer information, uploaded images, databases, forms, and important configuration files. The last thing you want is to move everything to a new server and discover that something is missing.


In this first part of our three-part website migration series, we will go through preparation for a server migration, identify what needs to be moved, create reliable backups, and get the new server ready.

The goal is simple:

Before we move the website, we make sure we can recover it.


What Is Website Migration?

Website migration is the process of moving a website from one hosting server to another.

You may need to migrate a website because:

  1. Your current hosting plan is too expensive.
  2. Your website has outgrown the current server.
  3. You need better server performance.
  4. You are changing hosting providers.
  5. You are moving from shared hosting to a VPS.
  6. You need more control over your hosting environment.
  7. You want a more reliable server.

At first, website migration may sound like simply copying files from one server to another.

In reality, there is more to it.

A typical website can contain:

  1. Website files
  2. Images and media
  3. A database
  4. Configuration files
  5. SSL certificates
  6. Email accounts
  7. DNS records
  8. Cron jobs
  9. PHP settings
  10. Third-party integrations

This is why proper preparation is important.

Before You Start: Understand What You Are Moving

Before making any changes, take a moment to understand your website.


Essential questions include:

Where are my website files stored?

For a typical cPanel account, they may be inside:

/home/username/public_html

Does the website use a database?

WordPress, Joomla, Drupal, and many custom PHP websites usually use MySQL or MariaDB.

Does the website have email accounts?

If your domain also hosts email, you need to consider those accounts separately.

Where is the DNS managed?

Your DNS may be managed through your registrar, Cloudflare, your current hosting provider, or another DNS provider.

Knowing these details before starting will make the actual migration much easier.


What You Need Before Migrating

You do not need many tools to get started, but you do need access.

From the Old Server

Make sure you have:

  1. cPanel or SSH access
  2. Website files
  3. Database credentials
  4. Database name
  5. Database username
  6. Database password
  7. Access to DNS information

From the New Server

You should have:

  1. cPanel or SSH access
  2. The new server's IP address
  3. Enough disk space
  4. The correct PHP version
  5. A database server
  6. The required PHP extensions
  7. Domain or website configuration
  8. SSL support

If you are moving between two cPanel servers, the process can be even simpler because both environments provide many of the tools needed for the migration.


Step 1: Check How Much Space Your Website Uses

Before creating backups, check how large your website is.

If you have SSH access, you can use:

du -sh public_html/

You might see:

2.4G public_html/

This tells you that the website files are using approximately 2.4 GB of storage.

You should also check how much space is available on the new server.

There is no point starting a migration if the new server does not have enough storage.

You can check available disk space with:

df -h

Look for the available space on the filesystem where your website will be stored.


Step 2: Create a Backup of Your Website Files

Now we get to the most important part: the backup.

Before moving anything, create a complete copy of your website files.

If your website is located inside public_html, you can create a compressed backup using:

tar -czvf website-backup.tar.gz public_html/

Let's break that command down.

tar

tar is a Linux utility used to package files and directories into an archive.

-c

Creates a new archive.

-z

Compresses the archive using gzip.

-v

Displays the files being processed.

-f

Specifies the name of the output file.

The result is:

website-backup.tar.gz

This file contains your website files in a compressed format.


Step 3: Check That the Backup Exists

Check the file:

ls -lh website-backup.tar.gz

You should see something similar to:

-rw-r--r-- 1 username username 850M Aug 26 12:30 website-backup.tar.gz

The exact size will depend on your website.

You can also inspect the contents without extracting the archive:

tar -tzf website-backup.tar.gz | head

You should see entries from your website directory.

For example:

public_html/
public_html/index.php
public_html/wp-content/
public_html/wp-content/uploads/

This gives you some confidence that the archive contains the files you expect.


Step 4: Back Up the Database

Your website files are only half of the migration.

If your website uses a database, you need to back that up too.

For a MySQL or MariaDB database, you can use:

mysqldump -u DATABASE_USER -p DATABASE_NAME > database-backup.sql

For example:

mysqldump -u website_user -p website_db > database-backup.sql

The command will ask for the database password.

Once completed, you should have:

database-backup.sql

This file contains the database structure and data required to restore the website's database.


Step 5: Check Your Database Backup

Check the file:

ls -lh database-backup.sql

You can also inspect the beginning of the SQL file:

head -n 20 database-backup.sql

You should see SQL statements describing the database.

For a larger database, the backup file may be quite large. That is normal.

The important thing is that the file exists and was generated successfully.


Step 6: Keep a Second Copy of Your Backups

Do not keep your only backup on the server you are trying to migrate away from.

Imagine this:

Old server fails → backup is stored on old server → backup is lost → migration becomes a recovery operation.

That is exactly what we want to avoid.

Download or copy your backups to another secure location.

You should ideally have:

Old Server
├── Website Backup
└── Database Backup
Separate Backup Location

Your second copy could be stored on secure external storage, another server, or another backup system.


Step 7: Make a Note of Your Website Configuration

Before moving the website, record the important configuration details.

For a WordPress website, one of the most important files is:

wp-config.php

This file contains information such as the database connection details.

You may see settings similar to:

define('DB_NAME', 'website_db');
define('DB_USER', 'website_user');
define('DB_PASSWORD', 'your-password');
define('DB_HOST', 'localhost');

Do not publish or share your real password.

You are simply recording the information you will need when connecting the website to the database on the new server.

For a custom PHP application, look for configuration files such as:

.env
config.php
database.php
settings.php

The exact filename depends on how the website was developed.


Step 8: Check the PHP Version

The old server might be running one PHP version while the new server uses another.

Check the current PHP version:

php -v

You may see:

PHP 8.2.x

Make a note of it.

If the website depends on a specific PHP version or extension, make sure the new server supports it before you move the website.

This is particularly important for older WordPress websites and custom PHP applications.


Step 9: Check Your DNS Before the Migration

DNS tells the internet where your website is hosted.

Before changing anything, find out where your DNS is currently managed.

You should know:

  1. Your domain registrar
  2. Your DNS provider
  3. Current A record
  4. Current www record
  5. MX records if email is hosted on the domain
  6. Any other important DNS records

For example:

example.com
DNS
Old Server IP

Later, we will change this to:

example.com
DNS
New Server IP

Do not change the DNS yet.

We will handle that in Part 3 after the new server has been tested.


Step 10: Prepare the New Server

Now that your backups are safe, you can start preparing the new server.

If you are using cPanel, create the website account or add the domain.

Make sure the document root is correct.

A common cPanel path is:

/home/username/public_html

If you are using a VPS, your website might instead use:

/var/www/example.com

The exact location depends on your server configuration.

Also confirm that the new server has the software your website requires.

For example:

  1. PHP
  2. MySQL or MariaDB
  3. Required PHP extensions
  4. Web server
  5. SSL support


What We Have Accomplished So Far

At this point, we have not moved the website yet.

We have:

  1. Checked the website size.
  2. Created a website files backup.
  3. Created a database backup.
  4. Verified the backup files exist.
  5. Created a second copy of the backups.
  6. Recorded important configuration information.
  7. Checked the PHP version.
  8. Reviewed the DNS setup.
  9. Started preparing the new server.


In Part 2, we move from preparation to the actual migration.

We will take the backups we created here and move them to the new server.

We will cover:

  1. Transferring website files using SCP
  2. Using rsync as another option
  3. Extracting the website
  4. Creating the new database
  5. Importing the database
  6. Updating the website configuration
  7. Checking file ownership and permissions
  8. Resolving common migration errors

The important thing is that we will not change the DNS yet.

The old website will remain available while we prepare and test the new server.


Continue to Part 2

How I Migrated a Website to a New Server – Part 2: Moving Website Files & Database

Once the new server is ready, we can safely move the website and database without sending visitors to it just yet.


African Script — helping businesses build, manage, and move their digital platforms with confidence.

Comments

Oops! This post doesn't have any comment currently.

Leave a Reply

Your email address will not be published. Required fields are marked *

Quick Enquiry