@Evgeniy Makarov you already have two good answers;
- If you wish to do the migration, you will need to upgrade your Jira version to v7.6 and above, that way you can install Atlassian's plugin for migration - Jira Cloud Migration Assistant (JCMA).
- Note that, once you have JCMA, you still need to decide if you should migrate project by project or all at once If you are going to a brand new cloud site while you must go a project at a time if your site already has data that you wish to keep.
- Migration can be challenging if you have never done it before, it doesn't mean you cannot do it however, sometimes, you can get better value by either having an expert do it, or do it with their support. This is where Atlassian's Solution Partners come in.
- You are sure to find the right partner for your location, project size/budget, and long term support.
Ultimately you need to consider how to migrate Users and Group, Jira data (everything on your table above + filters and dashboards), Attachments, Plugins and any integrations. Not forgetting that you also need to plan and implement an upgrade before the migration.
All that said, Let me answer your question about the approach for migrating only active users;
Users - you have 179 users, 25 are active and you wish to only migrate your active users and wish to know how to do this.
- If you only migrate active users? Users carry with them the ownership of their Jira objects and history of their Jira activities like issues they created, comments they made of issues. Even when a colleague has left a team or company, there are reasons why you may want to preserve their history within Jira, not least for audit trail. To migrate only active users may mean migrating to cloud without reference the former users which may make it harder to quickly tell who did what when?
- Do you need to migrate only your active users? Some customers seek to only migrate active users because they are worried about security and license, let me touch on these;
- Security - when you migrate from self hosted to Cloud, inactive user should migrate without access. You should see their name or email address with (deactivated) after it. These accounts should not have product access with means the cannot get in to nor see what is in your cloud site (unless publicly available - that's another topic)
- License count - While it is good news that no product access mean the 'inactive' user accounts cannot enter your new Cloud site, it also means you do not pay a license for these accounts.
- Change in corporate user policy - another reason some customers do not like to bring inactive accounts is because they inactivated those accounts to duplicate these accounts into a new domain or want to have only one domain or only their AD UPN attributes come in etc. In this case, you may be better off doing a consolidation of the active accounts so you don't have double work to retrieve the old account history or lose it
- There are a number of other reasons but these three are most common in my experience
- How to migrate only your active users?;
- Consolidate the inactive user accounts into one generic account.
- Delete inactive users from your self hosted environment if using a local or delegated directory or remove upstream if using an active directory. I do not advice that you do this unless you must and you know what you are doing.
- Migrate all users then delete in/from Cloud site (or from AD if SCIM provisioning). Again, I do not advice this unless you know what you are doing and you must do it.
- Important:
- The uniques user identifier and key attribute of a user account in cloud is the email address. All accounts must have a unique email address to migrate to Cloud.
- Plan your migration and draft your plan and runbook
- Communicate your plan and the coming change widely and often
- Do at lease one test migration (do as many as you need)
- Update your runbook (including issues and resolutions/workarounds)
- Do a UAT migration (where you allow power users and other stakeholder to validate your migration). Encourage feedback and incorporate feedback into your runbook
- If you can, do one more migration - the aim is to have a near perfect migration end to end based on everything you now know and UAT feedback
- Then, Do it for real
Welcome to the group and Good luck
PS: If any of the above raised further questions please feel free to ask. And also feel free to ask about any other aspect of the migration that you may be unsure about.
If you would like a call to discuss this real time, I will be happy to help too.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.