You can use Redmine 1-Click as a safe update strategy: deploy a fresh Redmine stack on a new server,
migrate data from the old server, validate, and cut over with minimal downtime.
2. Migrate Data from Old Server to New Server
Perform migration in this order: freeze writes, dump database, copy files, import database,
run migrations, verify, and then switch traffic.
2.1 Put old Redmine in maintenance mode (or freeze writes)
- Announce maintenance window.
- Stop users from creating/updating issues during the final sync.
2.2 Export database from old server
Create a dump using your current database engine.
# PostgreSQL example
pg_dump -U redmine -Fc redmine_production > redmine.dump
# MariaDB/MySQL example
mysqldump -u redmine -p --single-transaction redmine_production > redmine.sql
2.3 Copy Redmine files and attachments
At minimum, copy attachments and custom assets from the old instance.
Typical paths: files/, plugins/, custom themes, and selected config files.
# Example using rsync from old to new server
rsync -avz /opt/redmine/files/ user@new-server:/opt/redmine/files/
rsync -avz /opt/redmine/plugins/ user@new-server:/opt/redmine/plugins/
2.4 Import database into new server
# PostgreSQL example
pg_restore -U redmine -d redmine_production redmine.dump
# MariaDB/MySQL example
mysql -u redmine -p redmine_production < redmine.sql
2.5 Run Redmine migrations and plugin migrations
cd /opt/redmine
RAILS_ENV=production bundle exec rake db:migrate
RAILS_ENV=production bundle exec rake redmine:plugins:migrate
2.6 Validate before cutover
- Login works and users/projects/issues are present.
- Attachments download correctly.
- Plugin functionality works as expected.
- Email notifications and background jobs run correctly.
2.7 Cutover DNS or reverse proxy
Point domain traffic to the new server only after validation passes.
Keep the old server available for rollback during a short observation window.
If your old server stays writable during migration, data drift can occur. Always perform a final sync window before DNS cutover.