Drupal hosting doesn't have to be expensive

An acquaintance recently asked me if I could transfer a Drupal site he owns from one hosting provider to another. The reason for the move was twofold: the old hosting was too expensive for the site's needs, and it used a version of Linux that would soon no longer be supported.

The new hosting costs significantly less, about 40 times less, to be precise. The old hosting charged $240 per month, while the new one is just $5.99 per month. Why the original developers chose such an expensive hosting, I can only guess.

Maybe they were familiar with how that hosting worked and found it easiest to use, or perhaps they were connected to the hosting provider as an agency. They might have overestimated the site's traffic, expecting millions of daily users, or there could be another reason entirely. Whatever the reason, the cost was too high, so I agreed to help transfer the site to the new hosting.

Unfortunately, the site wasn't in Git nor did it have any CI pipeline set up, so I had to transfer everything manually. The plan for the future is to put the project in Git and set up GitLab CI to streamline operations.

1. Transferring files

Since both hostings support SSH access, it was straightforward to transfer the Drupal code and other files like images, videos, and documents using rsync. This is the quickest option because files are copied directly from server to server.

Example of pushing the entire directory with rsync from the old to the new server:

rsync -avz -e "ssh -p NEW_SERVER_SSH_PORT" httpdocs/ NEW_SERVER_SSH_USERNAME@NEW_SERVER_IP_ADDRESS:/home/USERNAME/domains/example.com/public_html

Before running this command, you need to generate an SSH key on the old server and then add the public key to the new server's authorized_keys file. After that, you can establish an SSH connection from the old to the new server.

2. Transferring the database

I exported the database using Drush on the old server and then sent it to the new server via rsync. Then, I imported the database on the new server using the MySQL command line tool. I couldn't use Drush initially because it was installed globally on the old server, so until I configured Drush to be installed in the project itself, I didn't have access to Drush.

Exporting the database using Drush:

drush cr && drush sql-dump > DATABASE_DUMP_NAME.sql

Example of pushing the database with rsync from the old to the new server:

rsync -avz -e "ssh -p NEW_SERVER_SSH_PORT" DATABASE_DUMP_NAME.sql NEW_SERVER_SSH_USERNAME@NEW_SERVER_IP_ADDRESS:/home/USERNAME/domains/example.com/public_html

Importing the database using the MySQL tool:

mysql -uUSERNAME -pPASSWORD --host=HOST --database=DATABASE_NAME --force < DATABASE_DUMP_NAME.sql

Make sure to replace the placeholders written in uppercase with your values.

3. Updating DNS

Once the Drupal site was transferred to the new server, the client checked to ensure everything was identical to how it was on the old server. Aside from a few minor details, everything worked fine. To access the new site before changing the DNS, we just modified the local hosts file and added entries like:

xx.xxx.xx.xx example.com
xx.xxx.xx.xx www.example.com

where xx.xxx.xx.xx is the IP address of the new server.

What about performance?

The new hosting has 200GB of storage space instead of the 300GB that the old hosting has, but the amount of memory and CPU power are very similar. In any case, the resources are sufficient for the normal functioning of this Drupal site. So, in terms of performance, there was no difference after the site migration. The site continued to work as it did before, without any slowdowns or performance degradation.

Not all Drupal sites need to be hosted on expensive managed or unmanaged platforms. While the new hosting may lack deployment tools like Platform.sh or Pantheon have, these are unnecessary for a presentation site that rarely changes. Each project should be evaluated to determine the appropriate hosting type; choosing an overkill solution blindly doesn’t make sense.

What about monitoring?

A downside of using an unmanaged service is that it lacks built-in tools for monitoring server resources by default; you have to set up monitoring separately. Even managed services probably don't offer detailed stats, and some might not provide any at all. For example, if we look at Platform.sh monitoring, it seems pretty basic and doesn't give a lot of information. Plus, it only provides stats for the last 8 hours, which isn't ideal if we want to track system load over a longer period. I haven't looked deeply into it—there might be a setting somewhere for adjusting how long stats are kept—but that's not really the main issue right now.

For server monitoring, I use one of the best open-source solutions available: a combination of Prometheus and Grafana. This setup provides insight into all the granular details I need. Plus, I can configure it to retain statistics for as long as I want.

An additional benefit of Grafana is the ability to send notifications through email, Slack, and many other channels. You can set up alerts for every detail you want to monitor. For example, on my wife's e-commerce site, which has a 40GB disk limit that sometimes fills up due to various processes I won’t get into now, the most important alert I configured is one that notifies me on Slack when disk usage exceeds 85%.

In the end, everything was completed relatively quickly and without major issues. There's no need to pay for expensive, unnecessary services when moving the site to a new server is straightforward. During the transfer, it’s important to be careful to ensure everything is transferred accurately, especially when there's no Git repository or CI pipeline set up. Client testing plays a crucial role, as they know the site best and can easily spot any issues.