It’s certainly not a fun process, but moving a website between servers sometimes becomes necessary. In fact, in recent years, it has become an even more necessary and popular task among many website owners and administrators. That’s because prices continue to decrease for basic shared web hosting, while demand increases among medium-sized and larger websites for virtual servers and dedicated server products. This follows a sort of natural progression online, where websites start with shared hosting products and then slowly “move up the ranks” through virtual and dedicated servers as they require a larger scaled operation. While it’s a great feeling to finally outgrow shared hosting, the process of transferring files can often lead to downtime if a move is not properly planned and expertly executed.
Luckily, there are some great ways to ensure that downtime during a server move is a thing of the past. A combination of control panel interfaces, careful planning, and advancements in DNS propagation technology have all combined to make it easier than ever to move a website from one host to another, or from one hosting product to an even better one.
Before the Move: Make Sure the New Server and Hosting Plan is Appropriate
One of the biggest debates that any web hosting customer faces when purchasing a new plan for their website is the choice between Linux and Windows-based servers, and the technologies that accompany each operating system. Open-source Linux operating systems are most commonly associated with things like PHP and MySQL, and those technologies are instrumental in running popular content management software solutions like WordPress. Windows servers, conversely, are more tightly associated with Microsoft’s own proprietary databases and programming languages. This includes the Microsoft SQL Server and programming languages like ASP.
The best way to prevent unexpected downtime and major technological hurdles during the transfer of files is to ensure that the Windows or open-source nature of any existing plan is maintained at the new host, or on the new server. Windows users will likely want to stick with a Windows-based plan when they move, and the same is true of Linux hosting customers. If a transition between either technology is required by a website operator, then an adequate planning and transition period must be allowed for. This will give the website time to transfer its database information, software solutions, and web designs, to new technology in advance. This kind of foresight is what makes a site resilient even as it shuffles between the major competing technologies offered at most web hosts.
Performing the Move: Create and Restore Website Backups Between the Old and New Servers
One of the great things about both cPanel and Plesk Panel is that they allow for the quick generation, download, and upload of full website and database backups. This makes it easy to create a tightly-compressed backup of website files at the old host, and then upload those files at the new host using the same directory structure. With backups generated within the administration area of the website, the compressed file is simply expanded onto the new server. This means that every file, directory, and subdirectory is perfectly moved from the old plan to the new one, without any manual moves required within an FTP client or file manager.
The same is true of databases within both Plesk Panel and cPanel. While databases are not backed up using the same site-wide file and directory backup process, they can be individually compressed and downloaded for easy transfer. Just like the file backup process, the restoration of these database backups will result in the exact replication of existing tables and cells, as well as the data contained within them. The only drawback of database backups is that they must be done in a case-by-case basis, and restored individually. There is simply no way to backup and restore all databases at the same time. That being said, however, the process is still exceedingly easy in most cases.
More Database Considerations: Ensuring Connections and Information Consistency During the Move
Generally, backing up a database and restoring its information to a new server is the easy part of the moving process. What is a bit more difficult is ensuring that the new database can “connect.” It’s also a bit challenging to prevent lost information as a database is often moved to the new server before the DNS propagates. There are a few easy ways to prevent this type of “crossed wires” when executing a successful, downtime-free website move.
First and foremost, website operators will need to pay careful attention to the database’s name, users, and passwords. The actual name of the database, such as “wordpress,” will be transferred during the restoration of a backup file. However, many hosts will prefix the database name differently. Some prefer to use no prefix, while others will prefix it with the account holder’s username or the primary domain name of the web hosting account. This change will cause applications like WordPress to “lose” the database connection. This, in turn, will lead to connection errors and an inability to display the website’s content, comments, and even the site’s design. Furthermore, usernames and passwords for each database are not transferred via a backup. They must be created and updated manually by the website’s administrator.
Once new users are created, and once the database name’s new prefix has been noted, every application that previously had database access will need to be updated accordingly. This means the manual editing of files like WordPress’
wp-config.php, and similar ones for other web applications that might be in use by a website administrator. Every database name will have to be changed to reflect the new prefix and, if there have been any changes in the username or password, those will need to be updated as well.
Maintaining Consistency: Closing Down Interactions and Edits on the Old Site
One of the keys to a successful website relocation is to ensure that there are no posts, comments, or other data, lost during the transition process. Because altering a DNS record can take between one and three days to fully process and propagate, this often means not posting new content or enabling new comments on the old website for a brief period of time. Instead, authors should focus on posting content to the new website (via an IP address, if necessary), allowing that content to appear to users only when they can see the new website. This not only prevents “crossed wires” and lost communication, but it also is a good indication of when the new website has begun to display to users instead of the site’s old version on the previous server.
Using popular content management solutions, and popular discussion forums, website administrators can close down things like new forum posts or comments on blog entries. This can be done only on the old website, and it can be enacted after the database has been backed up and transferred to the new location. Though it might be considered a minor inconvenience, disabling comments temporarily on the old site is the best way to ensure that all voices are heard and no feedback is lost during the transition.
Avoiding a Common Mistake: Do Not Cancel Old Hosting Before the New DNS Has Propagated
In the 21st century, virtually every web hosting company offers instant setup, or near-instant setup, with a new web hosting product. That’s a great convenience, and it means that the file transfer process can begin almost as soon as payment is processed on the new hosting product or web server. This leads a number of web hosting customers to do what they perceive to be the “responsible” and “affordable” thing. As soon as they receive notification that their new hosting product is setup, they’ll call their old host to cancel services. In some cases, they’ll wait to do this until after all files and databases have been transferred. Either way, however, canceling a hosting package before the DNS alterations have propagated is a major folly on behalf of website administrators.
One thing to keep in mind is that virtually every web hosting company will consider a request a hosting account to be an “immediate” or “urgent” request. To that end, they’ll often close an account as soon as the customer instructs them to do so, whether or not that account is in the middle or beginning of its current billing cycle. That can lead to serious problems for almost every website operator, as all files and databases become instantly inaccessible. It’s a common mistake, and it’s a big problem among those executing their first website move.
Instead of canceling a hosting plan at the exact moment that a new company sets up the new server, website administrators should be patient. There is really no distinct urgency when it comes to closing down an old web hosting account, especially because its files will soon be inaccessible to common internet users anyway. Leave this account open while the file and database transfer process proceeds. Continue to leave it open as the DNS propagates around the Internet. And leave the old web hosting account active and open for a few days after the move has been completed to the new server.
As with any major move — online or offline — there are sometimes things that have been forgotten in the old location. Whether it’s a missing database or email account, or even a missing file or directory, access should be maintained to the old server for at least an extra week. This will allow the website’s administrator ample time to ensure the integrity of the new website. It will also prevent any permanently lost files, which might otherwise lead to downtime, data loss, or visitor inconvenience.
The Key to a Well-Executed Move is Testing, Testing, Testing
Moving a website to a new server or hosting package isn’t necessarily difficult, but it is certainly quite tedious. Because large websites can often involve hundreds or thousands of files, and virtually countless database records, website administrators and authors should extensively text the new server before the domain’s DNS record is even altered to point to the new account. This is crucial to the overall success of the website, especially as it concerns preventing downtime and ensuring easy access to the site’s old and new content.
Be on the lookout for things like 404 error pages or resolution errors, as well as any error messages that might be thrown by a PHP, ASP, or database instance. Remember that moving files to a new sever can often cause their paths to change, and this can lead to misplaced data and a whole host of problems that, while easy to fix, are also intrusive and inconvenient.
It’s probably a good idea for at least one website administrator to go through each web application installed to the server and verify every single path and setting, ensuring that everything was properly carried over from the previous installation. In fact, in some cases, it might even be a good idea to install a “fresh” copy of each application like WordPress and major discussion forums, manually setting the options and reinstalling plugins. This eliminates any chance that the server’s old settings are having an impact on the software’s performance at the new web host or server setup.
Finally, Be Open About the Website Relocation Process with Readers
Some websites try to perform a server move “under cover of darkness,” making the entire process a secret. They figure that this is possible because they can expertly prevent downtime and lost data, and users will never know the difference. Of course, if any small thing goes wrong, users are caught off guard and they’re generally less than understanding.
Rather than performing a top secret website relocation, interact with readers directly and inform them of the upcoming transition process. Explain that any downtime would be against the odds, and that the site will likely not suffer any outages or modifications in its functions during the process. Ask them to be understanding during this time, and they likely will be. Open, honest communication, is the key to success in this area.
With all of the above bases covered, the website will be able to transition to its new environment with ease. Administrators will enjoy their better value, bigger space, and increased scalability, while users will appreciate a well-executed transition and a website that successfully grows to meet their demands.