Atlassian Data Center End of Support: What Actually Happens to Your JSM Assets After 2029

[#1]

🛑 The Elephant in the Room

Most Data Center transition conversations stop at "you need to migrate by [date]." 📅 Almost none answer the question DC admins actually lose sleep over: what happens to my Assets schema specifically — the years of object types, relationships, and automations built on top of it. 

This is a breakdown of what's actually at stake for JSM Assets migration, and what your migration plan needs to account for that general DC transition guidance won't tell you.

📊 Where Things Stand

Data Center products move into read-only mode by March 28, 2029. ⏳ New Data Center app submissions ended in December 2025, and new Data Center sales to first-time customers close in March 2026. Existing customers can still renew or expand until March 2028. 🛒

These are commercial milestones, not penalties — but they signal where active investment is going: Cloud. ☁️

Assets is one of the most structurally complex objects in the Atlassian ecosystem to move, and most migration guidance treats it as an afterthought to the Jira project migration. 🏗️ This is the gap Twinit specializes in closing — we're the go-to for complex JSM Assets migrations specifically because this is where general migration approaches fail. 🎯

Why Assets is the Long Pole in Your DC-to-Cloud Tent

Jira issues, users, and basic workflows migrate fairly predictably. Assets schemas don't: ❌

• Object schemas are relational, not flat. An Assets schema is a network of object types, attributes, and references — not a list of fields. Migration tooling has to preserve that web, not just the data points inside it.
• Legacy and reference field types break for different reasons. Legacy field types have no direct Cloud equivalent — they fail because the field type itself can't map. Reference field types fail because the object-to-object relationship didn't survive migration, even if the field itself did. Insight Assets Cloud Migration Assistant handles these as separate migration tasks rather than one blanket field pass — because they need different fixes.
• Automations and filters depend on the schema being intact. If an automation references an attribute that didn't survive migration cleanly, it breaks silently — discovered only when a workflow stops firing in production.
• Request types and customer portals lean on Assets fields directly. If those configurations don't transfer, customers hit broken submission forms on day one. 💥

⚠️ What "After 2029" Actually Means for Unmigrated Assets Data

Once active support ends, you lose more than patches — you lose vendor support for the environment your Assets data lives in:

• No security patching, which becomes a compliance issue fast under GDPR, DORA, and HIPAA.
• No bug fixes, so existing schema quirks become permanent.
• No vendor path to a fix if something breaks.

Every month on unsupported DC infrastructure is a month of accumulating risk against a schema that's already hard to move correctly. 📉

🕳️ The Migration Gap Most Teams Don't See Coming

Jira Cloud Migration Assistant (JCMA) handles core Jira data well — but it does not migrate Assets schemas, objects, or attributes at all. Not partially. Out of scope entirely. 

Atlassian's official workaround is manual CSV export/import, which loses object hierarchy, icons, dependencies, and relational structure for any schema with real complexity. This is exactly the gap Twinit built Insight Assets Cloud Migration Assistant to close.

🚫 Things JCMA doesn't attempt at all:

• Assets object schemas, object types, attributes, and objects 📦
• Legacy field types 🧱
• Reference field types 🔗
• Assets automations ⚙️
• Pre-migration Assets backup 💾

Things that migrate but break because Assets isn't there:

• Filter configurations referencing Assets fields 🔍
• Request type configurations built on Assets fields 📋
• Workflow conditions, validators, and post-functions tied to Assets 🔄

For any JSM instance with a schema built over more than a year or two, multiple items from both lists will be in play. 🔥

📋 What a Complete Assets Migration Plan Requires

As complex migration experts, this is the standard Twinit builds every Assets migration plan around:

1. A pre-migration backup and discovery pass — full schema snapshot plus test migrations to validate object counts and references before the production run. This is the step our app runs automatically before any migration starts.
2. Separate handling for legacy and reference field types — validated against the source schema, not assumed to map automatically.
3. A rebuild plan for Assets-dependent automations, filters, and request types — its own migration task, not a side effect of the Jira migration.
4. Post-migration integrity verification — object counts, relationships, and references checked against the original backup, with an audit trail for sign-off.

💡 The Takeaway

The DC transition timeline is a deadline. Assets migration complexity is the actual project. 🏁 Teams that plan for the schema, automations, and request-type dependencies up front avoid the go-live surprises that come from assuming JCMA will handle Assets — when it doesn't handle Assets at all. 👋

[__ Jimi Wikman]

@Salome Ivaniadze Twinit this is a great article on a topic many are sleeping on.

Great work on this one!

[Salome Ivaniadze Twinit]

@__ Jimi Wikman Thank you so much! I really appreciate that. It's definitely a topic that deserves more attention, especially as more organizations move to the cloud. Hopefully, it sparks more conversations and collaboration across the Atlassian ecosystem. 🚀