As technology evolves, it becomes necessary for developers to migrate servers. Whether it's upgrading to a more powerful server or downgrading to a more cost-effective solution, the process remains the same.
Recently, I have migrated my server, holding multiple projects based on WordPress, Nextjs, and Django.
I am sharing with you the steps that I followed.
Check the Node/Python Versions
The first step is to document the current Node.js and Python versions running on the existing server. Different applications may require specific major versions, so migrating to a new server with incompatible versions can cause applications to break.
You can check your Node version using node -v
and Python version with python --version
. Note these versions and make sure your new server can support them.
Review requirements.txt and package.json
Dependencies are external modules that your project relies on.
In Python projects, these are listed in a
requirements.txt
filewhile in Node. They're in the
package.json
.
When migrating servers, it's essential to reinstall these dependencies so your application continues to work as intended. Keep a copy of these files and use them to install dependencies on the new server.
Migrate Supplementary Services
In addition to the main web frameworks, apps often depend on supplementary services like databases, queues, caches, etc. Common ones include:
Relational databases (PostgreSQL, MySQL)
In-memory caches (Redis, Memcached)
Background job queues (Celery, RabbitMQ)
Search indexes (Elasticsearch, Solr)
Document all active services being utilized. During migration, ensure these services are properly set up on the new server and test their functionality before going live.
Audit File/Folder Permissions
Server permissions determine who can access what resources on your server. Apps need proper filesystem permissions to startup, read configurations, write logs, etc. Over time, permissions might diverge on an existing server from the defaults.
Before migrating, audit the permission levels required for key folders like:
The application codebase
Log directories
Writable temp file areas
Make a list of all users and their permissions from the current server and replicate it on the new one.
Match the Web Server Version
Web servers like Nginx and Apache turn app code into usable websites and APIs. Confirm the new server is running a compatible web server release.
For example, Ubuntu runs Apache by default. If apps require Nginx, you may need to manually install a newer version before migrating those sites.
Also, export and migrate any custom web server configurations that handle things like:
Custom headers
URL rewriting
Rate limiting
Virtual hosts
Adhering to the expected web server version avoids inadvertent issues.
Environment File
Environment files (.env) store sensitive information like API keys and database credentials. These files shouldn't be exposed publicly. During migration, don't forget to copy this file and check that it's correctly referenced in your application.
Ensure all required variables get ported from the old to the new server. Good options are:
Direct transfer of
.env
filesExporting/importing variables from a key/value store
Test that migrated apps pick up the configurations as expected post-move.
Review Cron Jobs
Scheduled cron jobs inevitably get added over time for ops tasks like database backups, log rotations, scheduled jobs, etc.
Document all cron jobs on the original server before moving. Transfer any custom scripts referenced over to the new server as well.
After migrating, review that scheduled jobs are firing as expected in the new environment. Troubleshoot any paths/permissions getting in the way.
Project Specific Services
Running apps in the background requires using process managers like systemd or PM2 in Node and gunicorn in Python.
Gunicorn for Python Projects
Gunicorn acts as a web server gateway interface (WSGI) HTTP server for Python web applications. If your Django projects use Gunicorn, ensure it's properly installed and configured on the new server.
PM2 for Node.js Projects
PM2 is a process manager for Node.js applications that allows you to keep applications running forever. If your NextJS projects use PM2, ensure itβs correctly set up on your new server.
Perform Database Migrations
Database migration is a critical aspect of server migration. Ensure data consistency by correctly backing up your database from the current server and restoring it to the new one.
For relational SQL databases, perform a database dump from the old server and import it into the new database. Review for errors and test data integrity post-move.
For in-memory stores like Redis, manually transfer data or leverage built-in migration capabilities.
For search indexes like Elasticsearch, many support native snapshotting of indexes to restore new clusters.
Validate that connections exist between migrated apps and databases post-transition.
Configure Load Balancers
In multi-server environments, load balancers distribute requests across app servers. When migrating servers:
Add the new server to the load balancer pool but disable traffic to it.
Migrate apps to the new server, and validate health checks pass.
Gradually shift traffic mix towards the new server.
Retire the old server once stable.
This ensures no downtime for end users. Review load balancer logs for errors during the migration process.
User Acceptance Testing (UAT): Putting the User Experience First
Before switching over to the new server, conduct comprehensive user acceptance testing (UAT) to ensure that all systems and applications are functioning as expected from the user's perspective. This UAT phase should involve testing all critical functionalities, including user authentication, data access, and performance.
DNS Cutover and Go-Live: Making the Big Leap
Once UAT is successfully completed, initiate the DNS cutover process, updating DNS records to point to the new server's IP address. Monitor the migration closely during this transition phase to address any potential issues promptly.
Top comments (0)