Migrating OJS Between Servers: Moving Database, Files & Code
Step-by-step server migration manual for OJS. Learn how to move databases, files_dir, and codebases between hosts with zero lost manuscripts and minimal downtime.
Real Problem
Server migrations frequently lead to broken article attachments, mixed-up character encodings, and lost manuscript submissions when journals are moved without proper read-only locks.
Practical Solution
Follow this battle-tested server migration pipeline: place source journal in maintenance mode, transfer database snapshots and files via SSH/rsync, configure target web servers, and perform low-TTL DNS cutover.
The Three Pillars of an OJS Migration
Every Open Journal Systems installation comprises three distinct components that must be transferred and synchronized with precision:
1. Relational Database: The MySQL or MariaDB database containing all metadata, user credentials, review assignments, and system settings.
2. The Outside-Webroot Files Directory: The repository storing unpublished manuscripts, revisions, and published galleys.
3. The Web Application Codebase & Public Assets: The PHP scripts, configuration files (config.inc.php), and public media (logos, CSS).
Pre-Migration Planning and DNS Preparation
To minimize cutover downtime, reduce your domain’s DNS Time-To-Live (TTL) to 300 seconds at least 48 hours in advance. This ensures that when the live IP address is updated, international traffic routes to the new server within minutes.
Step 1: Initial Bulk Data Synchronization (Pre-Migration)
Do not wait for the maintenance window to transfer hundreds of gigabytes of manuscript files. Execute a baseline transfer while the journal is operating normally:
rsync -avz --progress /var/ojs_files/ root@new-server-ip:/var/ojs_files/
Step 2: Entering the Migration Window
When ready for the final cutover, establish read-only protection on the source server to prevent new submissions during data export.
In Nginx on the source server, return a clean maintenance notice or block POST requests:
if ($request_method = POST) {
return 503;
}
Step 3: Final Incremental Database and File Synchronization
Dump the database with optimal compression:
mysqldump -u ojs_user -p --single-transaction --quick --default-character-set=utf8mb4 ojs_database | gzip > /backup/ojs_final.sql.gz
Transfer and import onto the new server:
scp /backup/ojs_final.sql.gz root@new-server-ip:/tmp/
ssh root@new-server-ip "zcat /tmp/ojs_final.sql.gz | mysql -u ojs_user -p ojs_database"
Run a final incremental rsync to sync files uploaded since the initial baseline sync:
rsync -avz --delete /var/ojs_files/ root@new-server-ip:/var/ojs_files/
Step 4: Target Server Configuration and Verification
On the new server, edit config.inc.php:
- Set base_url to the live journal domain.
- Verify database connection parameters.
- Verify absolute files_dir path.
Verify permissions:
chown -R www-data:www-data /var/www/ojs /var/ojs_files
chmod -R 755 /var/www/ojs
chmod -R 750 /var/ojs_files
Step 5: DNS Cutover and SSL Activation
Update your domain A record to the new server IP. Once DNS resolves, obtain a fresh Let's Encrypt SSL certificate using certbot --nginx and remove maintenance restrictions.
Step-by-Step Action Plan
Lower DNS TTL Records
Reduce domain TTL to 300 seconds (5 minutes) 48 hours prior to migration to enable rapid worldwide DNS propagation.
Provision Target Server Environment
Set up identical or modernized PHP, MySQL/MariaDB, and Nginx configurations on the destination server.
Initial Bulk File Synchronization
Run rsync to transfer the large outside-webroot files directory while the source journal remains live.
Activate Maintenance Mode & Final Sync
Lock the source journal in read-only mode, dump the final database state, and run an incremental rsync for new files.
Update DNS & Cutover Live Traffic
Point the domain A record to the new server IP, issue SSL certificates, and deactivate maintenance mode.
Questions People Usually Ask
How do I prevent authors from submitting papers during migration?
Enable maintenance mode by placing a maintenance banner or redirecting write traffic in your web server, or set installed = Off temporarily to prevent any database updates on the old host.
Will migrating to a new server break our registered Crossref DOIs?
No. As long as your journal domain name and article URL structures remain identical, all registered DOIs will continue resolving seamlessly.
What is the fastest way to transfer a 200GB OJS files directory?
Use rsync with SSH compression: rsync -avz -e "ssh -c [email protected]" /var/ojs_files/ user@newserver:/var/ojs_files/.
Moving Your Journal to a Faster Server?
AcademiaTech manages end-to-end OJS server migrations with zero data loss, guaranteed DOI link continuity, and zero editorial disruption.