Content
Migration Redmine 2.x › OpenProject 3.0
Disclaimer
My experience with Ruby applications is rather limited. Please feel free to suggest improvements to this process.
I ran through the process many times to refine it and it is possible that I have missed a step or that others will encounter different problems.
Environment setup
Install three new environments:
- Redmine (I was using 2.3.1.stable) - Create a duplicate of your existing Redmine installation, perhaps on a VM, with a copy of your data (make sure it is a new database with a COPY of your data)
- OpenProject 2.4 - Perhaps in another VM, or the same VM as your Redmine copy.
- OpenProject 3.0 - On your new host - I followed https://www.openproject.org/projects/openproject/wiki/Debian_Stable_with_MySQL_in_production
In each case, make sure the production environment works correctly with the sample data.
Migration Process
The basic principle is to
- Take a copy of the Redmine data
- Wind back the migrations on the Redmine data to a point that matches in the list of OpenProject 2.4 migrations
- Apply the OpenProject 2.4 migrations
- Copy the data to the new OpenProject 3.0 installation
- Apply the OpenProject 3.0 migrations
In practice there were a few wrinkles.
Migration Steps
1. Make sure your Redmine copy is up and running with the correct data
On existing Redmine production host
# mysqldump -p redmine > rm-20140311.sql
Copy the sql file to the new Redmine VM
Import the data to the new Redmine database
# mysql -p redmine < rm-20140311.sql
2. Find a common point in the list of mirations (in db/migrate) between Redmine and OpenProject 2.4
Each migration is a separate file and on close inspection you will find that
In my case this was 20110401192910_add_index_to_users_type.rb
3. Migrate down in redmine to the common point
In the redmine root directory (on the new redmine VM)
There were 34 subsequent migrations so
# RAILS_ENV=production rake db:rollback STEP=34
4. Copy the data to the new openproject 2.4 database
# mysqldump -p redmine > rm-migrate.sql # mysqladmin -p drop openproject24 # mysqladmin -p create openproject24 # mysql -p openproject24 < rm-migrate.sql
5. Run all migrations to bring it up to 2.4 level
In the new openproject 2.4 root directory
# RAILS_ENV=production rake db:migrate
I ran into a problem with some “NULL” values in the “possible_values” field of the custom_fields table. Fixed this by hand in mysql workbench on openproject24 and re-ran the migration.
6. Copy the data to the openproject 3.0 database
# mysqldump -p openproject24 > op24-migrate.sql
copy the sql file to the openproject 3 server, then, on the new openproject 3.0 server
# mysqladmin -p drop openproject (clear away any old data) # mysql -p -u root mysql> CREATE DATABASE openproject CHARACTER SET utf8; (did it this way because otherwise I got locale/collation issues) mysql> \q # mysql -p openproject < op24-migrate.sql
7. Run all migrations to bring it up to 3.0 level
In openproject 3.0 root directory, as the openproject user:
$ RAILS_ENV="production" bundle exec rake db:migrate
This ran until it complained about attachments.
I manually (using Mysql Workbench) removed 4 bad attachments, the coresponding legacy journal entries, one other bad legacy journal entry, and the one and only document from the database.
I also changed the locale field in custom_field_translations to en (was en-GB).
Again I ran
$ RAILS_ENV="production" bundle exec rake db:migrate
This then ran until I got
== MigrateQueryTrackerReferencesToType: migrating ============================ -- Update tracker references in queries rake aborted! An error has occurred, all later migrations canceled: undefined class/module Syck::/usr/local/rvm/gems/ruby-2.1.1/gems/delayed_job-3.0.5/lib/delayed/psych_ext.rb:135:in `rescue in resolve_class_with_constantize'
On investigation, I found I had to edit /usr/local/rvm/rubies/ruby-2.1.1/lib/ruby/2.1.0/psych/class_loader.rb by adding:
require 'yaml' YAML::ENGINE.yamler = 'syck' require 'syck'
Again I ran
$ RAILS_ENV="production" bundle exec rake db:migrate
This then ran to completion
I examined the work packages in the web interface and all looks good.
(I had to manually fix sone hardcoded URL references in Wiki pages that included the IP address of the old redmine server - removing “http://aa.bb.cc.dd”)
8. Copy the “files” directory over and flatten the structure
The files in redmine are organised hierarchically into years and months but openproject used a flat directory. The file names are however the same so just moving all the files from the subdirectories to the files directory itself is sufficient.
Hope this helps.
John Parker