nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

If we are cloning complete vm in new azure infra and all apps are cloned and later we apply license

khushboo_puri

If we are cloning complete VM in new azure infra and all apps bamboo bitucket jira confluence cloned along with VM.and later we apply license will data be corrupted?

Accepted answers

All comments

Matthew Sinclair

Atlassians usual MO is licensing is not intrinsically tied to data.

If anything Data has a timer on when its purged - but that usually applies to clouds - not on-prem.

Odds are you would not be able to access data until licensing are applied.

We (My org) have an DC Instance that is currently expired - data is still present - just hard to reach.

khushboo_puri

No we have organization split...so we are cloning all vms of old organization to new organization and cloning will bring data of all apps in new infra so we apply license there will data be corrupted?

Matthew Sinclair

Educated Guess - you only need (an) additional license(s).

In other words you won't be able to reuse the license as its already in use on the main instance.

Best way to know for sure is to contact Atlassian Support to know for sure.

https://www.atlassian.com/company/contact/purchasing-licensing?redirectSource=sac-wac-redirect#/

Data is just Data - access to the product is the issue.

Germán Morales

Hi khushboo_puri,

Adding to Matthew Sinclair's answer: applying the license isn't really where the risk is. With a full VM clone for an org split, the problems usually come from the clones still behaving like the old org's instances. Before you start them in the new infra:

Change the Server ID on the cloned Jira, Confluence and Bitbucket. Every clone keeps the original's ID, and application links rely on it, so linked apps can end up pointing at the wrong instance. Changing it breaks the existing application links, so plan to re-create them afterwards.
Isolate the clones from the old org: outgoing mail, webhooks, CI triggers and application links can all still point at the original systems.
Double-check that each clone uses its own copied database, never the old org's.

Atlassian's guides: Change the server ID for Jira, Cloned Confluence with a new server ID, Server ID for cloned Bitbucket instances

For the licensing side of the split, Matthew's link to Atlassian's licensing team is the right place, since the new org will need its own licenses.

Matthew Sinclair

Big fat agreed here.

I was making the presumption you (the OP) had already considered the usual hazards of cloning and focusing on the main question in terms of licensing - so def be sure to look this over and consider these steps before you focus on licensing.

Arkadiusz Wroblewski

Hello @khushboo_puri

One important thing I'd add: applying new licenses shouldn't corrupt your data, but cloning running VMs can.👀🫣

If databases and application home directories aren't captured consistently, you risk data corruption, especially with Bitbucket repositories.

Atlassian explicitly warns about this:
https://confluence.atlassian.com/bitbucketserver104/data-recovery-and-backups-1822591807.html

I'd recommend taking consistent backups, testing the clones in isolation, and only then enabling integrations.

Best,

Arek🤠🧙‍♂️

Joseph Chung Yin

@khushboo_puri

In addition to what others suggested, one thing you also need to look into is the actual data ownership between your two different orgs, so data can only be accessed by org is not present/retained in the new env. Of course that is beside the cloning process, but it is always good to look into it if data ownership/access is important to your env.