Moving to a Dedicated Server
Recently (in progress as of this writing) we moved our domains from a virtual private server (VPS) at LeaseWeb to a dedicated server at DreamHost.
This article talks about my experience, which may come in handy should you decide to acquire a dedicated server for yourself. It is not a checklist for you to follow because hosting companies have their own ways of doing things — from "you are on your own" dedicated servers to providing a nice control panel to help you maintain it.
Please note that some parts of this article are highly technical and assume you know what you are doing when moving to a dedicated server. The article slants toward an overview of what I did and skips over much of technical explanations.
When moving from one single-domain hosted or VPS account, to another similar account, and cPanel is integrated into your website, a feature some hosting companies make available is to let cPanel do the move. Overall, it does a pretty good job.
But this article is about moving to a dedicated server without that detail.
I did make a checklist for myself, which might help if you get involved in a move like this, but some of it may not apply to your situation and other steps you require might be missing. Our dedicated server has a non-cPanel control panel to do most of the usual maintenance things.
What I did was move one domain at a time.
The first domain to be moved had little traffic. I felt comfortable using it to become familiar with the site transfer process for this server.
The domain was moved over and the DNS changed. Then, an email box was created, along with a couple forwarding addresses, and the MySQL databases were created.
No problem.
We currently use Mailgun as a mailing service for sending Possibilities and other list email. We also use Mailgun for automated interaction email (signups and purchase acknowledgements are examples). So I set that up to make sure I know how to do it. No problem.
To test cron, I made a script that both updates a log and sends me an email every 10 minutes. No problem.
I had to change permissions of Perl CGI scripts to 755. It's easy to manually change file and directory permissions with most FTP software. Some hosting accounts, and perhaps also some FTP software, automatically set permissions of *.cgi and *.pl scripts to 755 when the files are uploaded. But this wasn't automatic. Before the scripts would run, I had to do the change manually.
Some setups could not be set up until after the DNS was changed — MySQL, Mailgun, SSL certificate, and some cron jobs.
MySQL and Mailgun were two that required work-arounds for our higher-traffic sites. The work-around for both was similar. I used the first domain that was transferred as an service domain for those functions. The databases and list mailing of the website being moved were pointed to that service domain. After the website's DNS was changed, the newly moved site got its own MySQL databases and Mailgun connections.
What gave me the most trouble was the PDF generator.
The VPS server had Calbre installed. But Calibre would not install at the new server.
After trying for most of a couple days, I found out the latest Calibre version can not do command line web page to PDF conversions. It requires a desktop interface. And the older version of Calibre, the one running on the VPS, could not be installed on the Linux version that the dedicated server was using.
A frantic search for a quality replacement was started.
I found one that would work, fPDF. I wasn't fully satisfied, but it would do.
Then I found mPDF. The mPDF software is satisfactory. It uses less memory than Calibre and seems to be faster.
After that, no more hurdles, at least as of this writing.
Because we have a number of websites, I made a rough checklist for myself.
The publishing of my checklist is not intended to be something for you to follow. Instead, it is intended to be something to help remember things you might need to do when you transfer to a dedicated server. It may be prudent to construct your own checklist.
For each domain:
-
Export MySQL databases from the VPS. Export as both SQL and CSV — the CSV as a cushion in case the SQL fails.
Ensure that the SQL file sizes are within the maximum file size for importing at the destination server. (If too large, try compressing the file. The *.sql.zip file might be small enough to import. If using phpMyAdmin, it will automatically decompress the compressed file.)
-
Download a fresh copy of the domain's public document directories from the VPS — the directories where the web pages and scripts are located.
-
Make a note of the cron schedules at the VPS.
-
Make a note of the mailboxes and forwarders at the VPS
-
Import the MySQL exports into the service domain's MySQL system.
-
Change Mailgun credentials to use the service domain for sending.
-
Change the MySQL authentication in the downloaded website files to use the service domain's MySQL system.
-
Create an account for the new domain at the dedicated server.
-
Upload the public documents files to the new domain's account.
-
Change file permissions of *.cgi and *.pl files to 755.
-
Create the mailboxes and forwarders.
-
Set up the cron jobs that can be set up before the DNS change.
-
Change the DNS at the domain's registrar.
-
Get the domain's SSL secure certificate installed (for https://... URLs).
-
Create MySQL databases for the domain and import the MySQL exports.
-
Change the MySQL authentication in the website files to use the domain's MySQL system.
-
Update the Mailgun credentials for the domain.
-
Complete setting up the cron jobs.
-
Test everything. Thoroughly.
Now, at the dedicated server:
The move was more work than the above would suggest. The MySQL engine version was upgraded. It required me to update some of the database definitions and accompanying PHP code.
The Perl interpreter version was upgraded. The main issue with it was that Perl no longer looks for modules in the directory where the script is running. Inserting these two lines below the top #!...
line of the Perl scripts that used same-directory modules let the modules be found.
use FindBin 1.51 qw( $RealBin ); use lib $RealBin;
The PHP version was also upgraded.
The VPS ran a 5.+ PHP version. On the dedicated server, it is 8.+.
The PHP version update required that I make a good number of changes to the PHP code I use.
Version 8+ had all forgiveness removed. As an example, the mail() function now requires "\r\n" between header lines where before it put up with "\n" by itself. Requiring everything to be written according to specs is a good thing, in general, but it required a lot of time coding and testing my scripts to complete the server move.
As noted, the move is still in progress as I write this. But I expect no additional issues.
(This article first appeared in Possibilities newsletter.)
Will Bontrager