What Happens to Your Assets Legacy Fields When You Hit Migrate

[#1]

If you're responsible for a mission-critical JSM environment, you already know the feeling. Someone says "we need to move to Cloud" and your first thought isn't excitement - it's a quiet inventory of everything that could go wrong.The Assets schema your ITSM operations run on. The automations nobody fully documented. The legacy field types that somehow still work and nobody wants to touch.Migration guides tend to gloss over this layer.

They talk timelines and licensing. They rarely get into what actually happens to your JSM Assets schema when you hit migrate - and what it takes to get it right.

That's what this guide is. Not the five-step overview. The real deep dive, written by a team that has run these migrations for enterprises where failure wasn't an option.

📖 Grab drink of your favor, This one's worth reading before you start.

Why legacy field types are the hardest part of any JSM Assets migration

Legacy field types are older attribute types inherited from Insight, the original Assets product before Atlassian absorbed it into Jira Service Management. They predate the current Cloud field type system - and that naming reflects a real technical gap: many of them have no direct Cloud equivalent.

This creates four distinct failure modes during JSM Assets migration - not three:

• Schema mapping failure. Legacy field types can't always be mapped automatically to a Cloud-native attribute type. When the mapping doesn't exist, the field either fails to migrate or migrates as a blank attribute with no data - silently, with no error in the migration log.

• Relational integrity failure. Legacy fields often underpin reference relationships - object-to-object links that make Assets more than a flat list of records. When the field type doesn't survive migration cleanly, the relationship breaks too, even if the referenced object itself migrated correctly. The issue reference in Jira points to an object that now has no valid field context to resolve against.

• Attribute constraint failure. Jira Cloud enforces stricter attribute validation rules than Data Center. Fields that were permissive on DC - accepting values that technically violated field constraints - will fail validation on Cloud import. This is particularly common with legacy text and numeric field types that have accumulated non-standard data over years of use.

• Object history loss. This one doesn't break silently - it's simply gone. Object history cannot be migrated from Assets for Data Center or Server to Assets for Cloud at all. For enterprise teams with compliance or audit requirements, the absence of historical object data post-migration is a gap that needs to be documented and communicated to stakeholders before migration starts, not discovered afterward.

💡 None of the first three failures are visible until after migration. They surface as empty fields, broken issue references, and automations that stop firing. For enterprise environments, discovering this post-production is an operational incident, not a migration cleanup task.

What JCMA does with legacy field types

Jira Cloud Migration Assistant does not migrate Assets schemas, objects, or attributes - Assets migration is entirely outside its scope. Atlassian's official workaround is manual CSV export/import, which loses the field type definition, attribute constraints, and relational structure the moment it runs. Additionally, links between Jira fields and Assets objects must be created manually in Cloud, and automation rules must be recreated from scratch - the CSV approach carries objects but not the connections between them.

Two specific legacy types are partially recoverable via manual Cloud configuration: "Assets Referenced Objects" and "Asset Object (legacy)" can be mapped to Cloud equivalents with proper object schema configuration. Every other legacy type requires a case-by-case assessment of whether a Cloud-native equivalent exists and, if not, a remapping decision. This assessment is what most JSM Assets migration guides skip - and it's the step that prevents silent failures downstream.

For a full breakdown of every category JCMA doesn't migrate, see JCMA vs Insight Assets Migration Assistant: the complete comparison.

A correct legacy field type migration process

Step 1: Pre-migration schema audit

Before any migration tooling runs, conduct a complete audit of your Assets schema specifically looking for legacy field types. Categorize every attribute by type - basic, legacy, or reference - and for each legacy field type document the specific type, the objects using it, the Jira issues referencing those objects, and any AQL queries, filters, or automations that depend on the field.

Also document every Jira field-to-Assets-object link in your environment - these must be recreated manually post-migration regardless of which tooling you use, so a complete map before migration starts saves significant reconstruction time.

Migration tooling executes the migration. It cannot make the architectural decisions about how legacy types map to Cloud equivalents. Those decisions require human review before tooling runs - not after.

Step 2: Encrypted backup before anything moves

Every production JSM Assets migration should begin with a complete encrypted snapshot of the Assets environment: schemas, object types, objects, attributes, reference relationships, and attachments. This backup is the rollback point if something goes wrong and the validation baseline after migration completes.

JCMA does not create a pre-migration Assets backup. CSV export is not a backup - it loses the structural information needed to recover from a migration failure, and it captures no object history data whatsoever.

Step 3: Test migration to a sandbox environment

Never migrate legacy field types directly to production. Run a full test migration to a Cloud sandbox instance and validate that legacy field types render correctly in the Cloud Assets UI, object references in Jira issues resolve to the correct objects, AQL queries return expected result sets, and automations dependent on Assets attributes fire correctly.

One specific issue to flag before the test migration runs: archived objects in Data Center are migrated as active, unarchived objects in Cloud because the archive feature is currently unavailable in Cloud. Identify all archived objects and decide pre-migration how their status should be handled - this decision cannot be made retroactively without significant manual rework.

Step 4: Map legacy-dependent automations, filters, and Jira field links

Legacy field types frequently underpin critical workflow logic. Document every automation referencing a legacy field attribute, every AQL filter querying a legacy field value, every Jira workflow post-function tied to an Assets object attribute, and every Customer Portal request form surfacing a legacy Assets field.

Critically, also map every link between a Jira custom field and an Assets object - these connections do not migrate through any standard tooling and must be recreated manually in Cloud. The more of these you document before migration, the less reconstruction work lands on your team post-go-live.

Post-function logic tied to Assets is not available in Cloud at all - it requires rebuilding using Jira Cloud's native automation engine. For a detailed breakdown of how Assets filter configurations specifically behave post-migration, see our Assets filter configuration migration guide.

Step 5: Phased migration for complex or long-running projects

For environments where the migration window extends over weeks or months - common in large enterprise instances - a phased approach significantly reduces data drift risk. Migrate schemas initially to validate structure and field type mapping, then re-run the process to bring over newly added or updated objects before final production cutover. This keeps the Cloud-side schema current with the Data Center source without requiring a single high-risk cutover of everything at once.

Step 6: Production migration with integrity verification

After test migration validates the schema and dependency mapping, production migration should include an automated integrity check comparing the migrated environment against the pre-migration backup - object counts, relationship maps, field values, and issue-level reference counts. This verification report is the evidence your stakeholders and compliance team need before production sign-off

☄️ How Twinit closes the JCMA gap

At Twinit, we built two apps for the JSM Assets migration layer JCMA doesn't cover.

Insight Assets Migration Assistant (listed on Atlassian Marketplace ) installs on the Server or Data Center instance, packaging schemas, object types, objects, attributes, and all field types - legacy and reference - for migration.

Insight Assets Backup & Migration runs on the Cloud instance, managing restoration, field type mapping, and validation - AES-256 encrypted, EU/US data residency or BYOK, with an Assets Backup Vault accessible even if Cloud is unavailable.

Together they address all four legacy field type failure modes: schema mapping (field type translation with flags for types needing manual decisions, not silent failures), relational integrity (object IDs and references preserved so Cloud-side restoration has something valid to reconnect to), attribute constraint handling (validation pre-checked before production migration runs), and a pre-migration backup that creates the snapshot object history audit trails depend on.

🌴 What to remember

Legacy field types are a migration blocker precisely because JCMA doesn't attempt them and CSV export strips the structural context that makes them work. A complete JSM Assets migration treats legacy field type coverage as a discovery question to answer before migration starts - not a cleanup task to handle after production go-live. The migration process isn't complicated if you plan for it. It's only complicated if you assume standard tooling handles it and discover the gap in production.