Upgrade to Kimai 2 from v1

This documentation covers all necessary steps to migrate from Kimai 1 to Kimai 2.


Before starting with the migration, please read the following FAQs:

  • Data from the existing v1 installation is only read and will never be changed
  • Data can only be imported from a Kimai installation with at least v1.0.1 and database revision 1388 (check your configuration table)
  • User-specific rates are not yet supported in Kimai 2, but
    • fixed-rates and hourly-rates for projects and activities are imported
    • fixed-rates and hourly-rates and total rate for timesheet entries are imported
  • Customers in Kimai 2
    • are only used for recording, they cannot login and no user accounts will be created for them
    • have a country code, which can be set during import or edited afterwards (Kimai v1 doesn’t know the country)
    • have a currency code, which can be set during import or edited afterwards (Kimai v1 only knows one global currency)
  • You have to supply a default password, which will be used for every imported user(!)
    • due to security issues we cannot import the original passwords
    • let your users reset it afterwards with the Password reset function
  • The import will fail, if a user from v1 has either an empty email OR the same email is used for multiple users
  • Data which was deleted in Kimai v1 (user, customer, projects, activities) will be imported and set to invisible
    • if you don’t want that, you have to delete all entries that have the value 1 in the trash column before importing
  • Groups import
    • The import will skip groups that have no members.
    • The import will always assign a teamlead to the project. If none of the users in Kimai v1 was assigned as the teamlead, the first member of the group is assigned as teamlead during import.
    • The groups that were trashed in Kimai v1 are not imported into Kimai 2 as hidden/trashed teams are not supported.

Install Kimai

You have to install Kimai, please read the documentation first. You can install it on the same server, but remember that you have to meet the server requirements (see downloads page).

After Kimai 2 runs properly, the actual migration takes place, by importing the data from your Kimai 1 database into Kimai 2. You have to have SSH access to your server, as you will use a command shipped with Kimai 2, which will pull the data into the configured database from your .env file.

The database does not have to be on the same server and the database user (for the Kimai 1 tables) needs only read access.

Database import

See the help for the import command and all its arguments by executing:

bin/console kimai:import --help

A full command would look like this:

bin/console kimai:import-v1 "mysql://user:password@" "db_prefix" "password" "country" "currency" --timezone="timezone" --language="language" 

The fields country and currency are optional and will be set to DE and EUR if not given. The flags timezone and language are used for imported users, in case they didn’t set it in Kimai 1 (you should update the preference in Kimai 1 before importing, if you work across different timezones).

It is recommended to test the import in a fresh database. You can test your import as often as you like and fix possible problems in your installation. A sample command could look like that:

bin/console doctrine:schema:drop --force && \
bin/console doctrine:schema:create && \
bin/console kimai:import-v1 "mysql://kimai:test@" "kimai_" "test123" "CH" "CHF" --timezone="Europe/Zurich" --language="ch"

That will drop the configured Kimai database schema and re-create it, before importing the data from the mysql database at on port 3306 authenticating the user kimai with the password test for import. The connection will use the charset latin1 and the default table prefix kimai_ for reading data. Imported users can login with the password test123 and all customer will have the country CH and the currency CHF assigned.

Problems and solution

Kimai 1 was written a long time ago, when MySQL was lacking proper UTF8 support and foreign keys (in shared hostings). While migrating dozens of customers installations I stumbled upon some recurring problems, that can be solved with some SQL commands.

Broken character

Many Kimai 1 installations have broken special character (like german umlauts or other language specific non-ascii characters) in the database.

This problem does not show up in the frontend og Kimai 1, as the database connection is using a different collation then the database. But you can see these problems, when you query the database directly (eg. with a tool like phpMyAdmin).

You can fix these broken entries (mainly timesheet descriptions) with SQL statements like these:

SELECT * FROM `kimai2_timesheet` WHERE description like "%ü%"; 

They cannot be fixed automatically by Kimai 2, but changing them is then just a matter of rewriting these SQL queries:

UPDATE `kimai2_timesheet` SET description = REPLACE(description, "ü", "ü") WHERE description like "%ü%"; 
UPDATE `kimai2_timesheet` SET description = REPLACE(description, "ä", "ä") WHERE description like "%ä%"; 

User accounts without email

Find and update all users, that have no email address:

select * from kimai_users where mail = '' or mail is null;
update kimai_users set mail = concat(name, '@example.com') where mail = '' or mail is null;

Reset password for testing

Update an account with a new password in your Kimai 1 database:

UPDATE kimai_users SET password = md5(concat('your-salt', 'new-password', 'your-salt')) WHERE userID = XYZ;