Migrating to ServerNet from another provider

Why Migrating to ServerNet Requires Careful Planning?

Migrating a website from a previous provider to a new host, if done without preparation, can lead to prolonged downtime, lost emails, or database corruption. Many users assume it's enough to upload files via FTP and change DNS, but in practice, details like PHP version, MySQL settings, and MX records can take the site offline for hours. In this article, we provide a practical checklist for migrating to ServerNet that covers all essential steps and minimizes downtime.

Step One: Full Preparation and Backup

Before any action, take a complete backup of all your data. Do this manually even if your previous provider has an automatic backup tool.

Backing Up Files

Via SSH or cPanel, compress the entire public_html directory:

tar -czf backup_site.tar.gz /home/username/public_html

If you don't have SSH access, use FTP with a client like FileZilla. Ensure hidden files like .htaccess and .env are also transferred.

Backing Up the Database

Export all databases using the mysqldump command:

mysqldump -u username -p database_name > backup_db.sql

If the database is large (over 1 GB), use the --single-transaction option to avoid locking tables.

Backing Up Emails

Save existing emails in mailboxes using tools like imapsync or via cPanel settings (Email Disk Usage option). If you use a third-party email service like Google Workspace, this step is unnecessary.

Step Two: Setting Up the New Host Environment

After taking backups, prepare the ServerNet environment to accept the site. This includes creating a database, configuring PHP, and installing required modules.

Creating a Database and User

In the ServerNet control panel (e.g., cPanel or DirectAdmin), create a new database. Note the database name and user. Then import the backup database:

mysql -u newuser -p newdatabase < backup_db.sql

If you encounter the ERROR 1045 error, check the user's permissions. Typically, the user needs full access to the database.

Configuring PHP Version and Modules

Your site may require a specific PHP version. In ServerNet, you can usually set it via MultiPHP Manager or the .htaccess file:

AddHandler application/x-httpd-php74 .php

Also enable modules like mysqli, curl, and gd. If the site uses WordPress, temporarily disable caching and security plugins to avoid conflicts.

Step Three: Transferring Files and Settings

Now transfer the backup files to ServerNet. The best method is using rsync, which offers high speed and security:

rsync -avz --progress /local/path/ user@server.net:/home/user/public_html/

If using FTP, be sure to enable Binary mode for image and compressed files. ASCII mode is only suitable for text files.

Configuring the Config File

Update configuration files like wp-config.php (for WordPress) or .env (for Laravel) with the new database information. Enter the database name, user, and password exactly as per ServerNet settings.

Fixing a Common Issue: Absolute Paths

Many sites use absolute paths like /home/olduser/public_html. After migration, these paths must be changed to the new ones. Use the following command to search and replace them in the database:

sed -i 's|/home/olduser|/home/newuser|g' backup_db.sql

Do this before importing the database.

Step Four: Transferring Emails and Configuring MX Records

Transfer existing emails from the old server to ServerNet using the imapsync tool. Example command:

imapsync --host1 oldserver.com --user1 olduser --password1 oldpass \
         --host2 newserver.net --user2 newuser --password2 newpass

After the transfer, change the MX records in DNS to point to ServerNet. Typically, the MX value should point to mail.newserver.net or the email server's IP address. If you use a third-party email service, do not change the MX records.

Important Note: SPF and DKIM

To prevent emails from being marked as spam, update the SPF and DKIM records. A simple SPF record looks like this:

v=spf1 mx a include:_spf.newserver.net ~all

Add this record in the ServerNet DNS zone.

Step Five: Changing DNS with Minimal Downtime

Changing DNS is the most critical part of the migration. If the TTL (Time To Live) of previous records is high (e.g., 24 hours), downtime will be prolonged. Therefore:

1. A few days before the migration, reduce the TTL of all records to 300 seconds (5 minutes).
2. After the migration, change the domain's nameservers to ServerNet. Typically, two nameservers like ns1.servernet.net and ns2.servernet.net are provided.
3. After applying the changes, use tools like dig or nslookup to check DNS propagation:

dig example.com NS +short

If the output shows the new nameservers, the change has been applied.

Common Mistake: Forgetting AAAA Records

Many users only change the A record (IPv4) and neglect the AAAA record (IPv6). If your site supports IPv6, be sure to update the AAAA record to ServerNet's IPv6 address as well.

Step Six: Testing and Troubleshooting Potential Errors

After applying all changes, thoroughly test the site. Check the following:

• Loading of main and internal pages
• Sending and receiving emails
• Logging into the admin panel (e.g., WordPress)
• Functionality of forms and contact buttons

If you encounter a 500 error, check the error_log file in the site's root directory. Usually, PHP errors or incorrect file permissions are the cause. Set file permissions with the following command:

find /home/user/public_html -type f -exec chmod 644 {} \;
find /home/user/public_html -type d -exec chmod 755 {} \;

Conclusion: Migrating to ServerNet with Confidence

Migrating a website to a new host, if done carefully and according to the checklist, can be accomplished without significant downtime. By following the steps outlined—from full backup to DNS configuration—you can perform a migration to ServerNet with minimal hassle. If you encounter any issues at any stage, the ServerNet support team is ready to assist you. Remember to always keep a backup of your site in a secure location.