Migrating users from 1.9.19 to 3.1.2

Migrating users from 1.9.19 to 3.1.2

by Marjan Milošević -
Number of replies: 7

So, I dropped idea of migrating full site, but want to start from scratch with 3.x (and keep 1.9 running for existing courses, at least for some time). Can I avoid account recreation? What would you suggest?

Because of the password salting changes (improvements), I guess there is no way of keeping passwords. I even thought of MNET-ing these two sites.

Any best practice (if such is available) would be appreciated.


Average of ratings: -
In reply to Marjan Milošević

Re: Migrating users from 1.9.19 to 3.1.2

by AL Rachels -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Hi Marjan,

If you are wanting to move your users from Moodle 1.9 to Moodle 3.1 it can be done.

In Moodle 1.9, go to Users > Accounts > Bulk user actions. Select all your users (except admin) in the Users in list window then click, Add to Selection. Once all your users are shown in the Selected window, click on the down arrow by With selected user and choose Download, then click Go. Pick the format you want, I usually use ODS, but text and Excel formats are available.

Once the download is complete I usually open it in Libre Office Calc and inspect the file. If there are users I don't want, I delete them from the file. I then make sure the file is saved in CSV and encoded as UTF8.

Go to your new Moodle, Administration > Users > Accounts > Upload users. For Choose a file, pick the one you just saved, and click Upload users. I'll leave it up to you which settings you want to use. When the upload completes, you should see Upload users results page with all the new Moodle 3.1 users listed.

In reply to AL Rachels

Re: Migrating users from 1.9.19 to 3.1.2

by Marjan Milošević -

Hi, Al, thanks for answer!

The issue is that bulk download does not export the passwords. The alternative is to export directly from the database, however, I'm not sure how the new salting mechanism is going to be handled. 

Let's suppose I import the existing MD5 hashes into new mdl_user table. I guess the process of users visiting the new Moodle would be: entering password, Moodle generates per-user salt, hashes password and salt the concatented salt+pass using bcrypt -> this hash sure is not going to be same as the previous one.

I guess I could turn off the salting, import existing pure-hashes and then somehow make users changing it and switching to the regular per-user salt.

BTW, I would like to avoid standard e-mail password-reset mechanism.

In reply to Marjan Milošević

Re: Migrating users from 1.9.19 to 3.1.2

by Emma Richardson -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers

The way I normally handle this is that when I upload the users, I set all the passwords to changeme and then select to force a password change.  That way, you can send out a mass email informing users and they will be prompted to change their password on first login.

In reply to Marjan Milošević

Re: Migrating users from 1.9.19 to 3.1.2

by AL Rachels -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Hi Marjan,

Sorry about that. Since I have always used manual enrollment and I always assigned passwords to my students, I forgot about passwords not being included in the Moodle 1.9+ user download. I think your best bet is to do what Emma mentioned even though you want to avoid the password-reset.

As an alternative, you could experiment with directly exporting just one or two "test" students from your Moodle 1.9 and then see what happens with the salted password when you put it in your new Moodle. If it works and you are able to log in with the test students, YEAH! If it does not...back to using "changeme" as suggested.

In reply to AL Rachels

Re: Migrating users from 1.9.19 to 3.1.2

by Marjan Milošević -

Ok, so i tried to export one single row in order to test, It didn't work, since there is a mismatch in number of fields in mdl_user in 1.9 and 3.1.

So, I simply retyped in values for id, name and password directly in the 3.1 database. It did not work, the user cannot login. 

I found this code in auth:

function user_update_password($user, $newpassword) {

        $user = get_complete_user_data('id', $user->id);

        // This will also update the stored hash to the latest algorithm

        // if the existing hash is using an out-of-date algorithm (or the

        // legacy md5 algorithm).

        return update_internal_user_password($user, $newpassword);

    }

So, I hoped that Moodle would "see" that the old algorithm was used (there is a prefix in mdl_user table telling what hash is being used, if omitted, than no hash is used) and it would gonna let the user log in before the hashing is introduced. There is obviously something like that, but not exactly as I expect  ;)

I'll dig a little bit further.


In reply to Marjan Milošević

Re: Migrating users from 1.9.19 to 3.1.2

by Emma Richardson -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers

I can't see anyway the password import would work and it was encrypted with a different hash and moodle has no way to decrypt it.

How are you importing?  (Different number of fields? Sounds like you need to fix your csv file.)

In reply to Emma Richardson

Re: Migrating users from 1.9.19 to 3.1.2

by Marjan Milošević -

Well, I believe it could be done, but I am not so sure how hard I am supposed to work to get that: Moodle can detect if the password is old one. Then it can use old fashioned hash (MD5) with supplied password and it could be matched. The next issue is how to switch to new hash.

I exported one row of table mdl_user with mysqldump. I compared fields from 1.9 mdl_user and indeed it has fewer fields than 3.x, i.e. there is no descriptionformat, htmleditor and so on. That's another issue, however, I might overcome it more easily than one with the passwords.

Finally, I can skip all and do it the hard way (although at the moment I'm not sure which way will actually turn out to be the hard one ;)) and create new users or direct them to reset password via mail.