Tombstoning vs disabled user migration

[Dimitris Schizas]

We are currently in the planning stage of migrating our Jira and Confluence server to the cloud.
According to the documentation, disabled users should not count as active licensing seats during the migration.
However, during the user assessment stage, I noticed that disabled users in our directory were not marked as such in the Cloud Migration Assistant.There was not visual confirmation of the status of disabled users.
Instead, the only available explicit option was to use the tombstone flag, which retains activity but not identity.

Our goal is to migrate certain users to the cloud while preserving both their identity and activity, but without assigning them any product licenses.Is this handled automatically?

[Gerusa Lobo _e-Core_]

Hello @Dimitris Schizas,

If you disconnected the Active Directory, the users won't migrate correctly.

It is very important in a migration, migrate at least, all users related to projects and spaces, to have a minimum impact and preserve history and data in issues.

For example, if a user not migrate, all data related, as filters, boards, coundn't migrate.

To have a better migration I recommend, using a Migration Assistant, you select only users and groups related with projects/spaces, preserving group members.

In that way, only users and groups used in projets roles, permissions will migrate.

Also, In cloud you can configure the specifics groups to access to the products.

And, if you need, you can create/use a script to suspend the old/not active users migrated.

Best Regards,

Gerusa

[Dimitris Schizas]

Thank you, Gerusa, for your prompt response.

These users are not Active Directory users; they are native Jira and Confluence users.

Our migration plan involves migrating only a subset of users as Active Users—specifically, those who are responsive and can validate the success of the migration.

The reason for this is that we would like to validate the success of the migration before commiting to licensed products

Based on my interpretation of the diagram, migrating disabled users will not result in any data loss, as they will still be recognized as active users in the cloud, albeit not billable and with no product access.

My issue is that disabled users in my internal confluence don't get annotated as such in any part of the process making me worried that the migration will fail unless i acquire some licensed plan.

Best regards,
Dimitris Schizas

[Tankem Williams]

Hello @Dimitris Schizas 

I understand how frustrating your situation can be. To ensure a smooth Jira server > Cloud migration, I would recommend prioritizing a thorough cleanup before proceeding. Dedicate extra time to removing inactive users by first transferring their assets and reassigning any tasks to active users. The process becomes even more manageable if these inactive users are native to Jira and Confluence rather than being managed through Active Directory. Once the cleanup is complete, migrate only the users and groups associated with relevant projects and spaces while preserving group memberships.

best regards 

Tankem Williams

[Dimitris Schizas]

Hello @Tankem Williams

Thank you for your time assisting me.

My migration plan is:

I have 19 active users on confluence and jira server.

All of them eventually will be migrated to cloud.

For the first step of the migration i don't want to transition to a licensed service unless i am absolutely sure that the migration was a success.

In order to do that i plan to disable 9 of my users temporarily like Marge in the table in  User migration.

Then i migrate the users while still retaining the free tier. According to the documentation all the users will be available on the cloud but only the 10 NOT disabled will have product access.
Activity and ownership of pages projects and tickets will be preserved.

My only problem is that on the user assessment page although i have disabled the 9 accounts there is no visual indication that they are disabled and that no license allocation will take place upon the migration.
The only flag i have available to modify this behavior is the Tombstone flag which is not viable for my use case.

[Gerusa Lobo _e-Core_]

Hi @Dimitris Schizas 

You can disable before it or only give access for the products in cloud for a specific users.

You could prepare the products group access to have up to 10 users.

I suggest you configure a jira premium trial, start a sandbox, and proceed a test migration to sandbox, previously for the production migration.

Best Regards

[Ed Letifov _TechTime - New Zealand_]

Hello, @Dimitris Schizas 

Our goal is to migrate certain users to the cloud while preserving both their identity and activity, but without assigning them any product licenses.Is this handled automatically?

This is not handled automatically but is very easily achievable at no cost.

Please consider using our apps User Management for Jira and User Management for Confluence on both Data Center and Cloud. Export all your deactivated users on Data Center into CSV, and then after migration is done, once data is in Cloud, use CSV-based filtering by email to select the users that should be deactivated and then deactivate in bulk using one of these apps in Cloud.

As a Platinum Atlassian Solution Partner with Cloud Specialisation in New Zealand and Australia we do all this and use these apps routinely when we do Cloud migrations.

It is important to note that this is only possible to the users from the email domains that you have verified in Cloud and claimed i.e. those under your organisation's control. If some of these  users deactivated on DC are outside of your organisation – you should change their emails on DC before migration to some fake emails in your domain i.e. so you have control over them in Cloud after migration. If you need a ScriptRunner script for this bulk change – reach out to our support.

Do reconcile users between your Jira and Confluence – even if they are both connected to the same LDAP it pays to check that you don't have a stray user active in one app and deactivated in the other.

You should also reconcile your Cloud users against your DC users, paying attention to last login dates in Cloud – after all someone who has been deactivated on DC may have been active in Cloud (e.g. in Trello Free or Atlassian University or this very Community) for years – if you deactivate them after migration to match DC you will effectively cut off their Cloud access.

Also from experience, if you are planning to use ANY Identity Provider in Cloud – put a lot of effort into reconciling your user list coming from DC, with Cloud, and with the Identity Provider and change emails where required to "merge" identities to match across all 3 sources. The efforts to do it after migration are absolutely mind boggling, don't go there...

If you need any help – please feel free to reach out to our 24x7 support.