Prior to release the Mattermost 3.0 upgrade process was tested on deployments of around 500 and 1000 users in different early adopter communities and the upgrade procedure ran smoothly.
Since the 3.0 release a wide range of deployments have also upgraded without significant issues, and we wanted to share the process from one of the largest we’ve seen, with over three thousand user accounts, two hundred teams with the largest team being over twenty-five hundred accounts.
The upgrade went smoothly, and fewer than 20 users (0.6% of accounts) contacted the administrator with support questions.
Here’s the process used:
- The largest team, which was also the most active, was selected as the “default team” to preserve when duplicate accounts were renamed.
- The administrator posted a message in the Town Square of active teams (see sample below)
- The database was backed up and the 3.0 upgrade procedure followed.
- The upgrade process took around 30 minutes. The database upgrade happened in under a minute the bulk of the time was migrating approximately 3000 profile pictures stored in S3 to new locations (downloading each image from S3 then re-uploading it). The migration of profile pictures was needed due to significant refactoring done in the Mattermost 3.0 release.
- Users with duplicate email accounts received emails with instructions on how to combine accounts that were merged (see 3.0 upgrade guide for example).
- Per the instructions posted by the administrator in Town Square, users who had questions about the procedure contracted the administrator. Out of over three thousand accounts fewer than 20 people had questions.
Here is the posting made in Town Square by the IT admin as an example:
The {NAME OF SERVER} server is being upgraded to Version 3.0, which lets you use a single account across multiple teams.
We will proceed using {NAME OF DEFAULT TEAM} as our ‘primary’ site. This means all accounts in {NAME OF DEFAULT TEAM} ({SERVER URL}/{URL OF DEFAULT TEAM}
) will not be affected by the upgrade, so that we minimize impact on the team with most users (2500+).
In particular, if you are only using {NAME OF DEFAULT TEAM} in {NAME OF SERVER}, no steps need to be taken and you may safely ignore the instructions below
Users who created duplicate accounts (either username or email) across teams will need to take steps to unify accounts:
- The duplicate email of an account on the
/default_team
team will change toemail+default_team@company.com
. You can use this new email address for login. - The duplicate username of an account on the team site
/default_team
will change tousername.default_team
to avoid confusion with other accounts.
As a result of these updates, your account on {NAME OF DEFAULT TEAM} now has a unique email address and username and is considered your “primary” account.
RECOMMENDED ACTION: (if you belong to teams other than {NAME OF DEFAULT TEAM})
It is recommended that you login to your teams used by your duplicate accounts and add your primary account to the team and any public channels and private groups which you wish to continue using.
This gives your primary account access to all public channel and private group history. You can continue to access the direct message history of your duplicate accounts by logging in with their credentials.
Steps have been take to minimize the impact of any one particular user to smooth out the process. The long-term benefits of multi-team single sign-on are significant, as this means each user has one set of credentials, one place to configure all account settings, and a more streamlined sign-up and team joining process across the 200+ teams that have so far been created in {NAME OF SERVER}.
SUPPORT:
For any questions, message me here or in {NAME OF DEFAULT TEAM}, or email at {EMAIL_OF_ADMIN}