Solving the Data Fidelity in DC Archival

Cloud Migrations
, , , ,
1

Hello Developers,

We’re exploring the long-term feasibility of archiving compliance-critical data locked in legacy DC plugins without clear cloud migration paths.

We’d love your perspectives on three challenges:

  • Fidelity: How do you approach 1:1 preservation of data and UI for non-Atlassian software in archives spanning 10–20 years?

  • Privacy Paradox: How do you reconcile GDPR “Right to be Forgotten” requests with immutable/static archives?

  • Workarounds: Have you been asked to build reverse-syncs, database snapshots, or other custom archival bridges?

If you’ve navigated “Long-lived DC” or “Hybrid” roadblocks, let’s connect. Your insights will help shape Atlassian’s archival posture.

Drop a comment or DM me—I’d love to learn how we can partner with you.

2

Hi Abhishek,

We have also been asked to provide such a long-term-archive and given customers the go to find a solution even if it comes to providing 100% DC promo codes in the future.
But we told the customers to talk to Atlassian about this scenario and I appreciate your efforts to find a good solution.

“no clear path to cloud” is often blocked by features not provided by Atlassian. For us, just to name a few:

  • DC to Forge Cloud Confluence Macro Storage Format conversion => no automatic conversion and mapping of DC macro format to Cloud format
  • For our other app we are currently developing workarounds to map customfield contexts from DC to Cloud by projects. Because there is no customfield context id mapping provided by Atlassian (for years….)

About the Fidelity Challenges:

  • How can you expect a Marketplace Partner to support their Apps - they cannot sell due to end of life of DC - for 10-20 years and provide e.g. security updates.
    • Will there be special “long term archive”-licenses we get paid for to support these DC installations?
  • As long as Atlassian does not introduce breaking changes with every major release and the long-term archive would live in an air-gapped environment Java Software just works for ages.
  • My wish: Come to an end with this many breaking changes with Jira 11 / Confluence 12 and provide API wrappers and compatibility libs for Marketplace Partners that wrap the Breaking Changes (As you have done in the past).

About the Privacy Paradox:

  • Let’s assume the DC App only stores data within the customers ecosystem (ActiveObjects and PluginSettingsFactory) then it is the customers responsibility to work out these challenges. As long as the apps provide some kind of way to delete data, which they usually do.
  • GDPR usually states max 6 months until data has to be deleted once it is not needed anymore. The usual approach would be to anonymize all the PII data BEFORE the long-term-archive becomes immutable.
  • For most App Vendors this should have zero impact and is a customer responsibility.
  • Most partners would simply need to deactivate their tracking and in most cases that would be enough.
  • For data stored outside the customers ecosystem (remote database) the customer would somehow find a solution with the Marketplace Vendor individually.

About Current Workarounds:

  • We have not been asked yet.
  • But as stated we have to work on a lot of workarounds the other way DC→CLOUD.

That are just my thoughts on this matter.

Cheers,

Bernhard

3

Hi Bernhard,

Thank you for the incredibly candid feedback. This is exactly the kind of “ground truth” we need as we evaluate the feasibility of an archival path.

You’ve touched on a few critical points that I’d like to dig into:

  • The “Maintenance” Burden: Your point about supporting apps for 10–20 years on EOL platforms is a major consideration. This is why we are currently exploring a static/immutable snapshot approach. If the archive is a “frozen in time” record rather than a live, unpatched server, it reduces the security/update pressure on you as a partner.

  • API Stability: I hear your frustration regarding breaking changes (Jira 11/Confluence 12). Part of our research is determining if an archival solution should exist outside of the active application lifecycle to avoid these exact compatibility hurdles.

  • Data Fidelity: The mapping issues you mentioned (Macro storage formats/Custom Field IDs) are exactly the “fidelity gaps” that make a move to Cloud so difficult. An offline archive would theoretically allow a customer to move “clean” data to Cloud while keeping the “complex/broken” app data accessible in its original DC state.

  • Commercials for Partners: You raised a valid point about “long-term archive” licenses. We are looking at whether there is a model where both Atlassian and Partners are compensated for the value this provides to the customer.

As we move forward, would you be open to a brief chat? I’d love to understand what a “minimal effort” archive would look like from your side—essentially, what is the bare minimum you need from us to ensure your app data remains readable in a long-term archive?

Best,
Abhishek

4

Hi,

Good to hear. Since our apps do not have so much „own“ data and we are a very small vendor with limited resources maybe you can discuss this further with some representatives from big partners. I currently have very much to do with working our apps toward A4A requirements and have no time slots at the moment.

But I will watch this thread and comment on it.

Cheers

Bernhard

6

Thank You, have taken your recommendation.