Free Website Migration Service

How To Request Free Website Migrations from Liquid Web

The Migration team at Liquid Web is dedicated to providing you with an efficient and as uneventful a migration as possible. Whether you are migrating from a current Liquid Web server (internal migration) or from another host (external migration) into Liquid Web, it is important that we work together to ensure an effective transfer of information.

If you would like to skip the overview and go straight to the request form, you can do that clicking on this link for Requesting A Migration. At the bottom of this article we guide you through making a migration request. To request a Windows server migration, please open a Support Ticket with the Windows Team indicating that you are requesting a migration.

Otherwise, check out some helpful terms to know before your migration begins. Still have questions about what to expect? We have a handy guide called What to Expect During a Site Migration.

Before Your Migration Begins

Before you start your migration, there are a few terms that we use that you will need to be familiar with:

  • Initial Sync – This is the first of three stages of a migration. In this stage, access levels are determined and tested, version matching occurs, and the initial seed of data for your websites being migrated is brought to the new server.
  • Hosts File – The hosts file is a computer file used by an operating system to map hostnames to IP addresses. This file is a plain text file and stored on your computer or workstation, it is the first stop when your browser looks up a domain name via DNS. You can edit the hosts file to re-route requests for a particular domain name to a different IP Address. This is the preferred method of testing your site on your new server. This allows you to view the site as if it were live on the new server at Liquid Web and verify that all pages are working as intended prior to going live with a DNS update.
  • Final Sync – The final sync is the last transfer of data in the migration process. This is completed after you confirm that all testing has come back without any major issues to fix before the site goes live. The final sync typically updates files, email, and databases that have been changed since the initial migration of data. This is done with the source server no longer serving requests and is most effective when a DNS update is performed in tandem.
  • DNS Update – A DNS update is part of the final sync of your migration which makes the target server (the new server at Liquid Web) live. The DNS update can be performed in conjunction with a final sync, or on its own if a final sync is not possible.
Note:
Your site is not live on the new server until the DNS update has occurred. It is normal to see some errors during testing and most will resolve once the DNS has been updated.
  • Authoritative Nameservers – a specific nameserver which holds the authoritative DNS records for a specific domain. Authoritative nameservers are defined for a specific domain at that domain’s registrar. A change to DNS at the authoritative nameserver will make its way around the internet through propagation. This is why it can sometimes take a little while for your DNS changes to take effect.
  • Nameserver – A nameserver is computer hardware or software that implements a network service for providing responses to DNS queries. Nameservers serve several types of information for a certain domain name, including A Records, MX Records, and CNAME records.
  • Nameserver Glue – Nameserver glue is a record which associates a named nameserver with an IP address on the internet, much like a A Record associates a domain name with an IP address. This record is stored at the domain registrar. During migrations, if nameserver authority is moving from one machine to another, the glue records at the registrar will need to be changed after the final sync and DNS update.

Requesting a Migration

Migrations begin by filling out our form through your Liquid Web account.
1. Once you log into your account, click on the Migration Center link at the top of the page.

2. You will be directed to the Migration Center home page. Click on Create a Migration Request to begin filling out the form.

Note:
If you want more information about migrations to Liquid Web, we have linked our Help Center Migration articles in the Migrations tab. Here you can read our articles What to Expect During a Site Migration and Testing Best Practices for Migrations.

3. Once the Request Migration form opens, you will be given the option to name your migration and add your source account. Click on the Add a Source Account button to add information about the hosting account you are migrating from.

4. Click on the Add a Source button to add server access information for the source account. This is where you would add SSH or panel login details for the server or cPanel account you are migrating.

5. You can add more than one source by clicking the link Add a Source Account at the bottom of the section.

6. Next, you will select your destination. You can choose the server from the drop-down menu.  If you do not currently have a server at Liquid Web, click on the Create a New Server link to be directed to a page for you to purchase and create a server.

7. Provide us with information on what software you’d like to have updated with the migration, or if you don’t need or want updates, you can leave this as it is.

8. We will need information from you on the domains on the incoming server and DNS settings. You can choose what domains you want tested and how you want the DNS handled.

9. The final step before submitting your request is to review the information you’ve provided. When you are ready, click the Submit button and a ticket will be sent to our Heroic Migration team.

We will contact you to schedule the migration and stay in contact with you through the entire process. Once the migration is complete, the last step is to test your site.

Please see our article Editing Your DNS Hosts File for information on how to securely test your site. If at any time you have questions or concerns, please feel free to contact our Heroic Support team by chat, phone or support ticket.

 

Restarting Services From the Command Line

One of the more common management tasks performed on web servers is restarting services (such as your web server daemon, mail daemon, FTP server, or DNS service).

You might need to restart the service(s) if:

  • The service may be crashing or stalled
  • The load the process is causing on the server might be too high
  • A restart might be needed to produce a configuration change to go into effect.

This article is geared towards operating systems using the systemd service.

  • CentOS 6
  • CentOS 7
  • most newer Ubuntu or Debian servers.

Note
For this article, general program names are bolded and italicised, binary commands or operands are highlighted in blue.

There are many ways to do anything on a computer, particularly in Linux, and performing service restarts is no exception. Here are three ways to achieve the same action, restarting Apache for typical Liquidweb Fully Managed servers:

  • With the first method, we use the service command, also known as systemd, to issue commands to the desired service. For Apache, this looks like service httpd restart will issue a restart command to Apache. You can check to see if you are able to restart services this way by running which service. CentOS 7 uses this method by default, CentOS 6 has it available, and it is also available on other major operating systems.
  • An older method is to call an init script on the server, known as the upstart method. An upstart command looks like /etc/init.d/httpd restart, which will issue a restart command to Apache also. You can check to see if you can use the init scripts by listing the scripts inside the init.d directory with ls /etc/init.d/. CentOS 5 and 6 used this type of service control by default, as do other aging OSes. Since this is an older method, we won’t discuss it in this article.
  • Finally, on cPanel machines, there are service restart scripts provided by cPanel that begin with /scripts/restartsrv_. For instance, the module to restart Apache is /scripts/restartsrv_httpd. This script performs a clean restart of Apache. If your web server has cPanel installed, these scripts are available for use and will always use the proper restart method for your operating system. This method is particularly helpful when the service name can vary based on the engine in use, such as proftpd or pure-ftpd for the FTP client; both use /scripts/restartsrv_ftpd and cPanel selects the appropriate service automatically. You can list the available scripts by running ls /scripts/restartsrv_*.

 

Choosing a Script

As demonstrated above, all commands will result in the same action. Therefore, the script you use comes down to a mix of personal preference and OS support. This article will focus on the first method, systemd, and the third method, for cPanel servers.

The typical formulation for using systemd with the service binary looks like this:

Service Command

The command followed by the name of the service you want to affect, and then an option called the ‘usage flag’, which tells service what to do.

 

Usage Flags

Every service typically at the least can stop, start, restart, as well as status usage flags. However, some services have other usage flags that can be used to give more information about how the service performs.

The configtest usage flag for Apache is an excellent example of this. You can test the written configuration for errors without having to load it into Apache first. You can then verify whether the changes made to the Apache configuration might cause Apache not to start, and correct them, without affecting your sites.

Note
cPanel has a background daemon called chkservd, which a daemon that checks to see if specific services are running. If you stop a service that is monitored, like Apache, and chkservd finds out, it will assume the service died and will attempt to restart it. Keep this in mind if you stop any services from the command line, and if needed, turn off chkservd from inside of WHM before you start. Make sure to turn it back on when done.

Below are some examples of typical services that you might need to restart on your server, as well as all of their usage flags for systemd.

Apache

If you are making configuration changes to Apache from the command line, such as creating new include files or optimizations, restarting the service is necessary for the new configuration to be operational. Additionally, if Apache (or httpd) is causing undue load on the server, restarting it usually kills its child processes and starts over with new ones, alleviating memory usage.

# service httpd
usage: httpd {start|stop|restart|fullstatus|status|graceful|configtest|help}

The usage flags may not always make sense to you when printed on the command line. Here is a basic outline of what they mean for Apache. These same general descriptions can apply to other services that use the same usage flags (though some may be Apache-specific).

 

startstart httpd
startsslstart httpd with SSL enabled
stop

stop httpd

restart

restart httpd if running by sending a SIGHUP or start if not running

fullstatusdump a full status screen; requires lynx and mod_status enabled
statusdump a short status screen; requires lynx and mod_status enabled
gracefuldo a graceful restart by sending a SIGUSR1 or start if not running
configtestdo a configuration syntax test
help list the commands available

 

You would use any of the optional usage flags as an extra argument after the service name as described above, like so:

# service httpd status
httpd (pid  74669) is running…

The cPanel restart script is essentially the same as service httpd restart:
# /scripts/restartsrv_httpd
Waiting for “httpd” to restart gracefully …

 

Mail

On cPanel servers the default mail service is exim.  Configuration or include changes to exim will require a restart to take effect.

# service exim
Usage: exim {start|stop|restart|status}

 

On Plesk servers, the default mail service is qmail instead.

# service qmail
Usage: qmail {start|stop|status|reload|condrestart|restart}

 

SSH

Any change to the SSH configuration file (such as changing the SSH port) requires a restart to the server daemon to take effect. Restarting sshd does not normally break SSH connections, but if you do change the SSH port, make sure you have opened the right ports in your firewall and are ready to make a new connection if needed!

# service sshd
Usage: sshd {start|stop|restart|reload|condrestart|status}

 

FTP

On cPanel servers the default FTP program is pure-ftp.  Any configuration changes to pure-ftp will require a restart to take effect. The cPanel restart script is convenient in this instance, as we covered earlier, even if the FTP program changes through cPanel, the restartsrv_ftpd script will restart the right service.

# service pure-ftpd
Usage: pure-config.pl {start|stop|restart|condrestart|status}

# /scripts/restartsrv_ftpd

 

Mysql

Mysql is mostly often restarted for configuration changes. Some newer machines will use mariadb instead of mysql or mysqld, though MariaDB normally responds to service requests made through systemd for MySQL as well. Again, the cPanel restart script is handy for cPanel servers, because usage either mariadb or mysql, /scripts/restartsrv_mysql will restart the database engine.

# service mysql
Usage: mysql (start|stop|restart|reload)

# /scripts/restartsrv_mysql

 

Firewall

On managed Liquidweb servers, the firewall of choice is CSF. The CSF firewall interacts with the iptables service.  Any configuration changes made to CSF the service must need a restart for the changes to take effect. However, you should not use the systemd or init scripts for this. CSF has a special restart procedure:

# csf -ra

 

If you try to use the service command, CSF will warn you not to:

# service csf restart
This script should ONLY be used by the init process. To restart csf use the CLI command 'csf -r'

 

Cron

Within Linux, the Cron service controls the scheduled tasks that run on the server. Stopping the Cron service will result in schedule task to be skipped. Unlike other services, the cron service does not need a restart if there is an additional cron added; it is generally only restarted when there is a change to the system clock or timezone, or when crons are not running due to various reasons.

# service crond
Usage: crond {start|stop|status|reload|restart|condrestart}

 

DNS

The named service is the default nameserver daemon for cPanel servers. If you run a different daemon, like MyDNS or NSD, use these names instead of ‘bind’ below.

# service bind
Usage: named {start|stop|status|restart|try-restart|reload|force-reload}

# /scripts/restartsrv_bind