What is the impact of setting "Tombstone" to true?

[chris sieverts]

I am starting the process of testing our DC to cloud migration and see that users with duplicate emails are not allowed. Two questions:

1. how are these considered duplicate emails? we have a number of users already in the cloud & DC which I would think would constitute duplicates but they aren't, on these 3 users (=6 dupes). FTR, only one is NLE, the other two remain legit emails.
2. what is the impact to setting the active users tombstone flag to 'true' in the Atlassian cloud? does it disable their accounts so that even though this is a test, the Atlassian cloud will disable them preventing their legitimate current use of cloud products?

Thank you!

[Trudy Claspill · Accepted solution]

Hello @chris sieverts 

When you use the Assess Users step of the JCMA process it is identifying duplicated emails based on looking only at the user accounts in your on-premise instance. That step is not comparing the on-premise users' emails to emails in accounts in Atlassian Cloud.

When the user and data are migrated to the Cloud, if there is an Atlassian Cloud account that already has that email address, then the data associated with that email address in the on-premise instance will be associated to the Atlassian Cloud account that has that same email address.

The impact of setting the Tombstone flag to true is that during the migration the issue activity/data related to the user is migrated but the user's identity is not retained. So, if there is an issue Assigned to that user, in Cloud the issue will show as assigned to Former User. This does not link to any actual Cloud user account. The same is true for comments authored by a user, and issue history entries that would indicate the user made some change to the issue.  This overrides association of the data to an Atlassian Cloud account that has the same email as the source on-premise user account.

The tombstone flag is used only by the migration process. It doesn't affect any user account that already exists in Atlassian Cloud.

I referred to this page for that information, plus my own experience migrating multiple on-premise Jira Data Center instances to Jira Cloud.

https://support.atlassian.com/migration/docs/customize-your-users-in-advanced-experience/

[chris sieverts]

Thank you Trudy for the insight and the link. that is a very helpful doc!

I ended up opening a case with support as well and I would be interested to hear your thoughts on their feedback:

Duplicated emails details:

When JCMA completes the preflight checks for email duplicates, it loads the list of all users from all active User Directories in whatever order of user directories may be configured on the product. From here, it then runs a distinct on the list by username and checks against this list for duplicate email addresses to return the results. In other words, two identical users that may exist in separate directories with the same username and email will be treated as one record.

So as long as this is the case, in which both records share an email address and a username (even though they may exist in different directories), JCMA will not flag the user records as duplicates. If there is a situation whereby the usernames are different across the directories OR if the email addresses are duplicated but the usernames are unique, JCMA will flag these records as duplicate email addresses since it perceives a different username as a separate user record.

This article will walk you through different ways to fix it as well in case you need help with this piece

Impact of Setting the Tombstone Flag to 'True':

Setting the tombstone flag to 'true' effectively deactivates the user's account. This means:

• Immediate Loss of Access: The user will lose access to all Atlassian Cloud products, including Confluence, Jira, and others. This is similar to deactivating an account, where the user cannot log in or use any services associated with their Atlassian account.
• Billing Implications: Billing for the deactivated account will cease, which can be beneficial if you are managing costs for inactive users.
• Data Retention: The user's personal data will remain within the Atlassian account services. This allows for the possibility of reactivating the account in the future if needed.
• Reactivation Possibility: An organization admin can reactivate the account at any time, restoring the user's access to the services.

It's important to note that this action does not delete the user's account or personal data permanently. If you are conducting a test, you can safely reactivate the account later without losing any data.

[chris sieverts]

After doing some further digging I think rather than using the "tombstone" option, leveraging merge is what I'm going to go with for the particular users we have as dupes.

Thank you again @Trudy Claspill !

[Trudy Claspill]

The functionality may have changed since last I used it.

As I recall we used the tombstone option only on users that did not already exist in Cloud. We specifically used it when we did not want a user in the on-premise instance to have a corresponding Cloud account created as part of the migration.