❓Legacy Field Types: The Migration Blocker Nobody Planned For

[#1]

JSM Assets Migration · JCMA Legacy Field Types Unsupported · Jira Data Center to Cloud · Assets Migration Blocker

Every Jira admin knows what a legacy field type is. It's the older attribute format inherited from Insight — the CMDB product Atlassian acquired from Riada in 2020 — that your team has been using for years because it worked and nobody had a good reason to change it.

Here's what almost nobody knows until they're mid-migration: JCMA flags these field types as unsupported in its own migration log — and then reports a successful migration anyway. The gap between those two facts is where enterprise JSM Assets projects go wrong.

What JCMA's migration log actually says

JCMA's migration log explicitly flags three legacy Assets custom field types as unsupported. These are the exact log entries:

"Assets object (single) (legacy)" — the custom field type is not supported via migration. The configuration for this field will not be migrated and any items that reference it, such as workflow schemes and filters, may no longer work.

"Assets object (multiple) (legacy)" — the custom field type is not supported via migration. The configuration for this field will not be migrated and any items that reference it, such as workflow schemes and filters, may no longer work.

"Assets referenced object (multiple)" — not supported via migration. Configuration will not be migrated and workflow schemes and filters may no longer work.

The suggested fix in each case: recreate the field manually in Cloud and use CSV import to update the issues post-migration.

For a single field on a small instance, that is workable. For an enterprise schema that has been running on Insight since it was a Riada Marketplace app — with dozens of legacy field types, hundreds of object types, and years of reference relationships built on top — it is not a fix. It is a months-long manual reconstruction project that nobody budgeted for.

Community experience from May 2026 confirms this pattern. In a documented JCMA Assets migration (beta), basic Asset field types were successfully migrated with values retained in tickets, but legacy Asset field types and reference Asset field types were not supported. The migration completed. Parts of the schema did not.

Before you even get to field types: the JSM Premium blocker

There's a step that comes before field type migration that enterprise teams are now hitting unexpectedly. JCMA's preflight check blocks migration with the error "Your cloud subscription doesn't support Assets" — even when no JSM Assets entities have been selected for migration. The fix requires ensuring the JSM Premium license is enabled on the target Cloud tenant before migration can proceed.

If your target Cloud environment is on JSM Standard, the Assets migration won't run at all. Confirm your target plan tier before scoping migration timelines — discovering this at cutover is a preventable delay.

What a legacy field type actually is — and why three specific types break

Legacy field types are older attribute constructs inherited from Insight, designed for a data model that does not have a direct equivalent in the current Cloud field type architecture.

Enterprise instances that have been using Assets since the Riada era often carry large numbers of these fields. One documented community case describes an environment with 12,000 users, 300 Assets fields, and 250 multi-level reference fields. For environments at that scale, "recreate manually in Cloud" is not a workaround — it is a full re-implementation project.

The three unsupported types fail for different reasons:

"Assets object (single) (legacy)" and "Assets object (multiple) (legacy)" — used to link Jira issues directly to Assets objects. When these aren't migrated, the field may no longer appear correctly on the Jira issue, filters that query this field return zero results, and automations that depend on it stop working or produce incomplete results.

"Assets referenced object (multiple)" — the reference field variant. When this doesn't survive migration, the object-to-object relationships it supported break — even if the referenced objects themselves migrated correctly. An issue showing "Server: Dell PowerEdge R740 | Location: Frankfurt DC" now shows nothing because the field type that held the link no longer exists in a form Cloud can resolve.

Other legacy Insight-era attribute types — older text, numeric, and reference-style attributes that have no direct Cloud-native equivalent. These don't fail visibly — the data simply has nowhere to land in Cloud's attribute type system. Empty field, no error, no warning.

For the full breakdown of each failure mode in detail — schema mapping failure, relational integrity failure, and attribute constraint failure — see our complete guide to migrating JSM Assets legacy field types.

🤔 What CSV export doesn't solve

JCMA's suggested workaround is to export as CSV and re-import after migration. Links between Jira fields and Assets objects must be created manually in the new Assets Cloud instance. Automation rules must be recreated using Automation for Jira — a different automation engine from the Assets automation layer in Data Center, which means rules cannot be directly ported. Object history is not migrated through any native Server/Data Center to Cloud Assets migration path.

CSV export moves values. It does not move field type definitions, attribute constraints, or relational structure. For a legacy field type with no Cloud equivalent, exporting data is only useful if you have first decided what Cloud-native type to map it into — which is a design decision, not a data export task.

For Jira-issue-to-Assets-object links specifically, CSV migration requires mapping user references from email addresses to Account IDs, since Cloud uses Account IDs for user identification. For hundreds of legacy fields across thousands of issues, this belongs in the project plan — not the post-go-live cleanup list.

👌🏻 The better workaround: convert before you migrate

The approach that worked in the documented May 2026 community migration: identify unsupported Assets field types in advance, convert them into supported types before migration runs, and update all references — JQL queries, workflow post-functions, automations — since field type conversions are not automatically reflected in dependent configurations.

This is materially better than post-migration CSV reconstruction for three reasons. The conversion happens on Data Center where you have full access and visibility. The dependent references — JQL, automations, workflow post-functions — can be updated and tested in the live environment before cutover. And the migration itself carries correctly-typed fields rather than requiring reconstruction in Cloud under go-live pressure.

The conversion process requires knowing, in advance, which legacy field types you have and what supported Cloud-native type each one maps to. That is the audit step that most teams skip — and the step that makes everything else manageable.

✅ The correct approach before migration runs

1. Identify every unsupported field type in your environment. Run JCMA's preflight check in a test migration to surface the exact field names and custom field IDs flagged as unsupported. Do this before the production migration, not during it.

2. Convert supported types on Data Center before migration. For types that have a Cloud-native equivalent — primarily "Assets object (single) (legacy)" and "Assets object (multiple) (legacy)" — convert them to supported types on Data Center and update all dependent JQL queries, automations, and workflow post-functions to reflect the new field configuration.

3. Map types with no Cloud equivalent. For legacy types with no direct Cloud equivalent, make the design decision about which Cloud-native attribute type best fits the historical data. Document this decision before migration runs.

4. Run a test migration to validate the conversion. After converting field types on Data Center, run a complete test migration to a Cloud sandbox. Validate that filters return expected result sets, automations fire correctly, and Jira issue views show correct object references. Do this before production.

5. Back up before anything moves. Every production migration should begin with a full encrypted backup of the Assets environment — schemas, object types, objects, attributes, reference relationships. This is both the rollback point and the validation baseline for the post-migration integrity check.

How Twinit handles legacy field types

Insight Assets Backup & Migration supports migration of all Asset field types, including Basic, Legacy, and Reference types — overcoming the limitations of JCMA (beta).

Twinit's migration approach treats legacy field types as a distinct migration task rather than a post-migration cleanup problem. The Insight Assets Migration Assistant maps Cloud-equivalent types where they exist — including the three types JCMA flags as unsupported — and flags the remainder for documented review rather than silently dropping them. Object IDs and reference relationships are preserved through the migration package so Cloud-side restoration has a valid baseline to reconnect to.

Every migration begins with a full encrypted backup before anything moves. For legacy field type migrations specifically, that snapshot is also the documented record of pre-migration state that compliance teams will ask for if reconstruction work is audited later.

Georgian Card migrated over 214,000 issues and a fully integrated Assets CMDB with live banking system integrations — zero downtime, 100% Assets relationships preserved. Legacy field type mapping was audited and converted on Data Center before the test migration ran, because discovering gaps in production was not an option.

Before you hit migrate 👀

Legacy field types are a blocker because JCMA does not attempt them and reports migration complete either way. The gap between those two facts is where enterprise projects stall — and it does not announce itself until users start filing tickets about empty fields and broken automations.

The fix is an audit and a pre-migration conversion on Data Center. Find every unsupported field type using JCMA's own preflight check. Convert what can be converted. Map what can't. Document every dependency. Run the test migration and validate before production.

None of that is complicated. All of it has to happen before the production migration — not after.