BMC Helix to JSM migration takes 4 to 12 weeks. The biggest risk is broken CMDB relationships. Plan for AQL-based CI mapping, JSM Assets rate limits of 1,000 req/min, and no native migration tool.
Migrating from BMC Helix ITSM to Jira Service Management has no native migration path from either vendor, requiring custom API scripting or a managed migration service for all data transfer. The fundamental challenge is a deep data model mismatch: BMC Helix stores incidents, problems, and changes across dedicated AR System forms with relational links and uses a hierarchical class-based CMDB, while JSM collapses all work into Jira Issues differentiated by Issue Type and Request Type and uses flat object schemas with AQL-based references in JSM Assets. Significant custom transformation work is required to rebuild CMDB relationships, map enumerated field values, convert BMC's multi-level CI hierarchies into JSM's flat schema constraints (120 attributes per object type, 2 unique constraints), and reconstruct SLA policies, approval workflows, and support group assignment rules from scratch.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Version note
This guide applies to BMC Helix ITSM 21.x and 23.x migrating to Jira Service Management Cloud. API endpoint patterns and form names may differ in older Remedy versions (pre-21.x). JSM Data Center has different API rate limiting behavior and does not include Assets in the same way as Cloud—this guide assumes Cloud as the target.
CSV import comment privacy risk
If you use Jira's CSV importer for service data, imported JSM comments mapped to "Comments body" become public. Atlassian also does not support mapping company-managed work types to team-managed work types during CSV import. CSV is fine for small closed-ticket archives. It is risky for Helix histories with mixed public and internal work logs.
JSM Assets billing implications
Premium plans include 50,000 objects. Enterprise plans include 500,000 objects. If your BMC CMDB contains more objects than your plan includes, additional objects incur per-object charges. Budget for this before starting the migration.
Jira Cloud backup limitations
Jira Cloud does not offer native project-level backup or snapshot. The built-in backup exports the entire site as a single JSON/XML archive. Before production migration, export your JSM project data via the REST API or use a third-party backup tool (e.g., Rewind, Revyz) so you can restore to a known state if rollback is needed.
BMC Helix AR-JWT tokens consume server-side session resources
Always POST to /api/jwt/logout when extraction is complete. Failing to do so can exhaust the session pool on busy instances. Tokens default to 3600-second expiry—refresh every 50 minutes during multi-hour extractions.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Scope the service model, not just the ticket table.
Objective Agreed scope across incidents, changes, problems, requests, CMDB and knowledge, with the CAB bought in.
Keep these open
-
Inventory every record type in BMC Helix ITSM
Count incidents, service requests, changes, problems, releases, knowledge articles and CI records. ITSM migrations fail on scope more than technique: the CMDB and the request catalogue are usually far larger and more entangled than the incident table everyone focuses on.
Data Profiler Get real record counts instead of estimating from memory -
Document the CMDB and its relationships
Map CI classes, attributes and — critically — the relationships between them. CI relationships carry your impact analysis, and they are the hardest thing to migrate faithfully because Jira Service Management almost certainly models them differently.
CI relationships rarely map one-to-one between ITSM tools. Losing them silently breaks impact analysis and change risk scoring.
-
Capture SLAs, OLAs and their calculation rules
Record every SLA target with its business calendar, pause conditions and escalation path. The rules matter more than the numbers: an SLA that counts pending time differently in Jira Service Management will report different compliance on identical data.
-
Review the request catalogue and its fulfilment workflows
Each catalogue item is a form plus an approval chain plus a fulfilment workflow. These are rebuilt, not migrated, and they are usually the longest lead-time item in the whole project.
COI & ROI Calculator Build the 36-month business case you will need for sign-off -
Take the migration through change management
The migration is itself a major change and needs CAB approval, a risk assessment and a documented rollback plan. Start this early — CAB cycles are measured in weeks and will otherwise set your go-live date for you.
Helpdesk Migration Planner Turn ticket volume into a dated BMC Helix ITSM → Jira Service Management timeline -
Build the business case and set the window
Model licence delta, implementation effort and the operational risk of running degraded. Choose a window that avoids change freezes, month-end and any regulatory reporting deadline.
Helpdesk Evaluator Sanity-check that Jira Service Management is the right target before you commit
BMC Helix ITSM → Jira Service Management specifics
- Licensing cost reduction
- BMC Helix ITSM carries high per-agent licensing costs, typically ranging from $100 to $200+/agent/month depending on module bundle and contract terms, with additional infrastructure costs for on-premises deployments. JSM Premium starts at $44.27/agent/month (annual billing, 50+ agents as of early 2025) and includes Assets (CMDB) at no additional object cost up to 50,000 objects. For a 200-agent team, this can represent $130,000 to $370,000+ in annual savings before accounting for infrastructure overhead.
- Atlassian ecosystem consolidation
- Organizations already using Jira Software, Confluence, and Opsgenie gain native cross-product workflows. When an incident escalates to a software bug, agents link a JSM ticket directly to a Jira Software development epic without third-party middleware. This eliminates the integration overhead required to keep engineering and support teams in sync.
- Modern agent experience
- Many teams find JSM's portal-first, Slack-integrated agent workspace faster to adopt than BMC Smart IT, particularly for engineering-oriented support organizations. Adoption timelines for new agents are typically 1 to 2 days for JSM versus 1 to 2 weeks for BMC Smart IT, based on the relative complexity of the interfaces.
Don't move on until
- Counts confirmed across every ITSM record type including CMDB
- Change-management implications reviewed with the CAB
- SLA and OLA targets documented with their calculation rules
02 Data Audit Audit the service data and the configuration data separately.
Objective Profiled exports for every record type, with CMDB integrity and audit-trail requirements resolved.
Keep these open
-
Export and profile every record type
Profile incidents, changes, problems, requests, knowledge and CIs separately — they have different shapes and different defects. Reconcile each export against the API count to catch pagination truncation.
Data Profiler Profile the BMC Helix ITSM export for nulls, outliers and type drift -
Audit CMDB integrity
Find CIs with no owner, no class, or relationships pointing at deleted CIs, plus duplicates from overlapping discovery sources. A CMDB is usually the least-maintained data in the estate and migrating its decay wastes the one chance you have to clean it.
Duplicate CIs from multiple discovery sources will multiply on load unless you dedupe before migrating.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Resolve audit-trail and retention requirements
Confirm with compliance how much history and which audit fields must be preserved, and whether a read-only archive of BMC Helix ITSM satisfies the requirement. In regulated environments this often changes scope materially.
Regulated environments frequently require the immutable original audit trail, which no migration can recreate — plan for an archive.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Validate structure and encoding of the exports
Check delimiters, encoding and embedded newlines. Incident work notes and change implementation plans contain long multi-line text and pasted logs, which is exactly what breaks CSV parsing.
CSV Validator Catch broken headers and ragged rows in the raw export -
Scan for PII and secrets in ticket text
ITSM tickets contain credentials, connection strings, internal hostnames and personal data pasted into work notes. Scan for both regulated data and secrets, and treat found credentials as a security incident in their own right.
Work notes commonly contain passwords and connection strings. Migrating them propagates the exposure into a new system.
-
Clean, normalise and produce masked test data
Normalise timestamps to UTC, standardise CI naming, trim whitespace, and generate a masked copy for the sandbox. Business-hours SLA calculations make timezone consistency non-negotiable here.
PII Masker Generate a safe copy for sandbox and vendor testing
BMC Helix ITSM → Jira Service Management specifics
- Under 5,000 records, no CMDB
- Native CSV export combined with JSM CSV importers.
- Mid-size, moderate customization
- API-based scripts with a dedicated engineer for 2 to 4 weeks.
- Incidents
- GET /api/arsys/v1/entry/HPD:Help Desk?offset=0&limit=500
- Problems
- GET /api/arsys/v1/entry/PBM:Problem Investigation?offset=0&limit=500
- CMDB CIs
- GET /api/cmdb/v1.0/instances/{dataset}/{namespace}/{className}?offset=0&limit=500
Don't move on until
- Every record type exported and profiled against API counts
- CMDB orphans and broken relationships quantified
- Audit-trail retention requirements confirmed with compliance
03 Field Mapping Map record types, state models, CI classes and approvals.
Objective A signed mapping covering record types, state machines, CI classes and relationships, and approval chains.
Keep these open
-
Map record types before fields
Establish how BMC Helix ITSM record types land in Jira Service Management — service requests may become a different object entirely, and incident/problem separation is modelled differently across tools. Get this wrong and every field decision downstream is built on sand.
Schema Mapper Opens pre-loaded with the BMC Helix ITSM → Jira Service Management field pair -
Map the state model and the impact/urgency matrix
Enumerate every state and transition, plus how priority is derived from impact and urgency. Tools derive priority differently, so a straight priority copy will disagree with the target's own calculation and confuse everyone reading a report.
If Jira Service Management derives priority from impact and urgency, migrating priority directly will produce records whose priority contradicts their own inputs.
-
Map CI classes, attributes and relationship types
Match each CI class and relationship type to a Jira Service Management equivalent and document every gap explicitly. Where no relationship type exists, decide whether to approximate, flatten, or park the data in an attribute — and record the impact on change risk scoring.
JSON to CSV Converter Flatten nested API responses into a reviewable sheet -
Map assignment groups, roles and approval chains
Build the group and user map including leavers, and map each approval chain to its Jira Service Management equivalent. Historical approvals usually cannot be recreated as live approval records — decide how you preserve the evidence.
-
Plan knowledge article migration
Decide how article bodies, categories, permissions and linked-incident references translate. Confirm whether internal links between articles and attachment references survive, or need rewriting after load.
-
Set load order and freeze the spec
Sequence users and groups, then CIs, then CI relationships, then tickets, then knowledge — CI relationships need both endpoints to exist. Version and sign off the spec before the pilot.
-
Request Types vs Work Types
In JSM, one work type can support many request types. If you skip this mapping step, the data may import correctly but the customer portal will still be wrong. Map request types separately from work types.
BMC Helix ITSM → Jira Service Management specifics
- Picklists and Enums
- BMC uses Selection fields with numbered values (e.g., Impact: "1-Extensive/Widespread", "2-Significant/Large"). JSM uses configurable select lists. Build a value mapping table before loading. Keep the original source value in a read-only custom field during UAT so you can audit the transformation.
- Date/Time
- BMC stores dates as epoch timestamps in some contexts. JSM expects ISO 8601 format. Convert during the transformation phase.
- Rich Text
- BMC Diary fields (used in Work Log notes) contain plain text with minimal formatting. JSM comments support Atlassian Document Format (ADF) for rich content.
- Required Fields
- BMC Helix ITSM incident creation requires First_Name, Last_Name, Impact, Urgency, Status, Reported Source, and Service_Type. JSM requires Summary and Issue Type at minimum, but project-specific required fields may differ.
- Assets References
- Use a unique CI key or reconciliation ID wherever possible for AQL mapping, not just a display label. Use the Object Mapping (AQL) column to enter AQL that maps the reference's label to a placeholder for the data locator. If you are mapping only one reference from the data, enter Label = ${Locator}. In production CMDB migrations, prefer stable keys over display names.
Don't move on until
- State and priority models mapped, including impact/urgency matrices
- CI classes and relationship types mapped with gaps documented
- Approval chains and assignment groups mapped to target equivalents
04 Test Migration Pilot the whole service model, including a change with approvals.
Objective A sandbox pilot where tickets, CI relationships, SLAs and approvals all behave correctly.
Keep these open
-
Build the Jira Service Management sandbox to match the target service model
Configure record types, states, SLAs, business calendars, assignment groups, CI classes and approval workflows before loading anything. In ITSM the configuration is the product, so an unconfigured sandbox tests nothing.
-
Pick a pilot slice spanning every record type
Include incidents at every priority, a change with a full approval chain, a problem with linked incidents, a catalogue request, connected CIs, and knowledge articles with cross-links. Coverage of types matters more than volume here.
-
Load in dependency order with full logging
Users and groups, then CIs, then relationships, then tickets, then knowledge. Log each request against its source ID so you can trace any failure without a full re-run.
-
Verify CI relationships and impact analysis
Confirm relationships survived and then run an actual impact analysis on a pilot CI, comparing the result to BMC Helix ITSM. Relationship counts matching while impact analysis returns something different means the relationship types mapped wrongly.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Reproduce SLA compliance on migrated records
Compare calculated SLA compliance on the pilot records against BMC Helix ITSM. Differences trace to business-calendar or pause-condition mapping and must be resolved before full load, since compliance reporting is often contractual.
SLA compliance is recalculated from loaded timestamps. Any approximation in timestamp or pause-state mapping shows up directly as a compliance variance.
-
Run a change through approvals and reconcile
Raise a change in the sandbox, take it through its full approval chain and implementation states, and reconcile the pilot batch on counts and fields. Then let service-desk agents work sample incidents before you sign off the pilot.
Don't move on until
- CI relationships verified intact for the pilot slice
- SLA calculations reproduce source compliance figures
- A change record runs end to end through its approval chain
05 Cutover Switch the service desk without losing an incident.
Objective All in-scope service data live in Jira Service Management, monitoring and email integrations repointed, desk operating normally.
Keep these open
-
Pre-load history and the CMDB ahead of the freeze
Load closed tickets, knowledge and the CMDB while BMC Helix ITSM stays live. The CMDB load in particular is slow and benefits enormously from happening outside the window.
Helpdesk Migration Planner Size the freeze window from Jira Service Management's real API limits -
Publish the runbook with CAB-approved abort criteria
A timed sequence with named owners, plus the rollback conditions the CAB signed off. In ITSM the rollback plan is a formal deliverable, not a verbal understanding.
-
Freeze BMC Helix ITSM and take the final delta
Stop new ticket creation, let the desk finish in-flight work, then export everything changed since the pre-load. Communicate the freeze across the whole organisation and staff a manual intake path for genuine P1s during the window.
A P1 incident raised during the freeze needs a documented manual path, or it will be worked in the old system and lost.
-
Load open tickets and the delta, then reconcile
Load open incidents, changes and requests, then verify counts and open-state accuracy before repointing anything. Open-state accuracy matters more than history here — it is what the desk works from at 9am.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint monitoring, email and integrations
Switch monitoring-tool integrations, email intake, self-service portal links and any orchestration or discovery connectors. Then fire a real alert through monitoring and confirm the incident it creates routes correctly.
Monitoring integrations still pointing at the old tool will create incidents nobody is watching.
-
Go/no-go and switch the service desk
Call the decision against the exit criteria with the change manager present, then move the desk with elevated support for the first shift. Keep BMC Helix ITSM read-only as the archive and rollback path.
BMC Helix ITSM → Jira Service Management specifics
- Ticket history is preserved
- as imported issues with full comment threads. Timestamps on migrated comments will show the import date unless you use the Jira Cloud migration API's created field override (available for issue creation but not comments).
- Customers care about request types, not issue types
- In JSM, request type is the customer-facing wrapper. If that wrapper is wrong, the migration will feel wrong to end-users even when the issue data is technically present.
- Comment privacy is visible immediately
- Customers only see public comments, while agents can see both public and internal comments. Your work-log mapping is part of change management, not just data loading.
- CMDB lookups work
- only if Assets objects were loaded and linked before agents start using JSM.
- SLA clocks reset
- Historical SLA compliance data from BMC cannot be imported into JSM SLA policies. Archive BMC SLA reports for audit purposes before decommissioning.
Don't move on until
- Historical load complete and reconciled before the freeze
- Monitoring, email and integration inbound paths verified live
- CAB-approved rollback point passed explicitly
06 Validation Prove service continuity, compliance and reporting.
Objective Evidence that records, CMDB, SLAs and workflows all survived, plus signed acceptance and a retained archive.
Keep these open
-
Reconcile every record type and the CMDB
Compare counts per record type and per state, CI counts per class, and relationship counts per type. Produce one report acceptable to both the CAB and your auditor.
Migration Validation Tool Reconcile BMC Helix ITSM and Jira Service Management record-for-record -
Re-verify CMDB relationships and impact analysis
Re-run impact analysis on a sample of critical CIs and compare with the pre-migration result. This is the CMDB equivalent of a field-completeness check and it is routinely skipped.
Data Profiler Prove field completeness held up through the load -
Tie SLA and service reporting to baseline
Rebuild SLA compliance, MTTR, first-time-fix and volume reporting, and compare to pre-migration figures for the same period. Explain every variance in terms of a specific mapping decision.
Business-calendar differences between tools will shift MTTR and compliance even when the underlying data is identical.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Test the full workflow layer
Fire every escalation, approval chain, notification, catalogue fulfilment workflow and automation with live records. Workflow is rebuilt from scratch, so nothing is proven until it has been observed running.
-
Confirm compliance evidence and audit archive
Re-scan for PII and secrets in loaded records, confirm retention configuration in Jira Service Management, and formally retain the BMC Helix ITSM archive that satisfies your immutable audit-trail requirement.
-
Close the change and sign off
Close the migration change record with actual outcomes, get written acceptance against the Discovery criteria, and schedule decommission after the agreed read-only retention period.
-
Record-count reconciliation
Compare total records per object type between BMC and JSM. A mismatch of more than 0.1% signals a pagination or filtering error in the extraction script.
BMC Helix ITSM → Jira Service Management specifics
- Field-level spot checks
- Sample 50 to 100 records per object type. Verify that status, priority, assignee, dates, and description match the source. Pay special attention to picklist/enum values that required transformation. Verify closed tickets remain in a closed state and do not trigger SLA breach notifications in Jira.
- Relationship integrity
- For every CI-to-Incident link in BMC, verify the corresponding issue link or Assets reference exists in JSM. This is the check most teams skip, and the one that causes the most post-migration support tickets.
- Agent UAT and privacy validation
- Have 3 to 5 IT agents perform their normal workflows in JSM using migrated data. Validate comment privacy with both an agent account and a customer account. Check that they can search for incidents, view CI history, and create new tickets without errors.
Don't move on until
- Reconciliation complete across all record types and CIs
- SLA and service reporting tie to pre-migration baselines
- Audit archive retained and acceptance signed
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
How BMC Helix Objects Map Jira Service Management
| BMC Helix ITSM field | Jira Service Management field | Notes |
|---|---|---|
| Incidents | HPD:Help Desk / HPD:IncidentInterface | Status values require enum mapping. BMC uses numeric status codes (e.g., "Assigned", "In Progress", "Resolved"). JSM uses configurable workflow statuses. |
| Problems | PBM:Problem Investigation | Known Errors are a sub-status in BMC. JSM has no native Known Error issue type; use a custom status or label. |
| Change Requests | CHG:ChangeInterface | BMC tracks Risk Level, Change Type (Standard/Normal/Emergency) as fields. Map to JSM custom fields. Map approval phases to Jira workflow transitions. |
| Service Requests | SRM:RequestInterface | BMC Service Request Definitions do not map to JSM Request Types 1-to-1. Manual mapping required. |
| Known Errors | PBM:Problem Investigation (sub-status) | This is a target-side design choice, not a native 1-to-1 match. Often paired with a linked knowledge article or workaround field. |
| Release Requests | — | JSM does not expose a first-class ITSM release object. Treat as a design decision. |
| Work Logs | HPD:WorkLog | BMC Work Logs contain structured fields (Work Log Type, Submitter, Time Spent). JSM comments are plain text with an internal/external flag. Time tracking requires a separate JSM field. |
| Configuration Items | BMC.CORE classes via CMDB API | Each CI class becomes an Object Type in a JSM Assets Object Schema. Relationships require AQL-based attribute mapping. |
| People / Contacts | CTM:People | BMC People records include Support Group assignments and functional roles (Incident Master, Change Coordinator) stored separately. Build an identity map before loading tickets. |
| Support Groups | CTM:Support Group | Group-level assignment rules in BMC must be rebuilt as JSM automation rules or SLA configurations. Helix support groups do not drop cleanly into JSM. |
| Knowledge Articles | KMS:Knowledge | JSM does not host articles natively. BMC Knowledge uses its own article lifecycle. HTML content must be transformed to Confluence storage format. |
| Attachments | Attachment fields on forms | BMC stores attachments as binary fields on AR System entries. Each must be downloaded via API and re-uploaded to JSM. JSM Cloud enforces a 250 MB per-file attachment limit (configurable per site). |
| Tasks | TMS:TaskInterface | BMC Tasks are parent-child linked to Incidents or Changes. JSM uses sub-task issue types or issue links. |
| SLA Definitions | SLM:ServiceTarget | SLA logic must be rebuilt in JSM. Historical SLA compliance data cannot be migrated; archive it separately. |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Incidents | medium | Incidents map to JSM Issue types conceptually, but status values require enum mapping from BMC's numeric codes to JSM's configurable workflow statuses, and associated work logs lose their structured metadata. |
| Configuration Items (CMDB) | high | BMC's hierarchical class-based CMDB with typed relationships must be entirely rebuilt as flat JSM Assets object schemas with AQL-based references, and multi-level CI relationship hierarchies cannot be imported directly. |
| Change Requests | medium | BMC Change fields like Risk Level, Change Type, and multi-phase approval workflows must be mapped to JSM custom fields and workflow transitions, requiring significant workflow redesign. |
| Work Logs | high | BMC's structured Work Log entries with typed fields, submitter data, and time spent cannot be migrated 1-to-1 into JSM's plain-text comments, resulting in loss of structured time tracking and log categorization data. |
| Service Requests | medium | BMC Service Request Definitions do not map 1-to-1 to JSM Request Types, and the distinction between JSM work types and request types requires a separate manual mapping effort for portal taxonomy. |
| Knowledge Articles | medium | Articles must be converted from BMC's knowledge format to Confluence storage format with HTML transformation, and BMC's article lifecycle states have no direct equivalent in Confluence. |
| Contacts / People | medium | BMC People records include Support Group assignments and functional roles stored separately, requiring a complete identity map to be built before any ticket data can be loaded into JSM. |
| SLA Definitions and History | high | SLA logic must be completely rebuilt in JSM as new policies, and historical SLA compliance data cannot be migrated at all—it must be archived from BMC before decommission. |
| Attachments | low | Attachments can be migrated by downloading binary fields via the AR System API and re-uploading to JSM, though this is time-intensive for large volumes and subject to JSM's 250 MB per-file limit. |
| Support Groups | medium | BMC Support Groups with their assignment rules do not map cleanly to JSM Groups or Organizations, requiring group-level routing logic to be rebuilt as JSM automation rules. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
CMDB Relationship Model Conversion
BMC Helix CMDB uses hierarchical class-based CI relationships with typed associations like BMC_HostedSystemComponents, which must be entirely rebuilt as flat AQL-based reference attributes in JSM Assets object schemas.
Three-Layer Target Model Mapping
BMC Helix tickets must be mapped simultaneously into three distinct JSM layers—Issues, Request Types, and Assets schemas—making a naive table-to-table copy impossible.
Work Log Structure Loss
BMC Work Logs contain structured fields including Work Log Type, Submitter, and Time Spent, but JSM comments are plain text with only an internal/external flag, requiring time tracking data to be mapped to a separate JSM field.
JSM Assets Attribute Limits
JSM Assets enforces a hard limit of 120 attributes per object type and 2 unique constraints per object type, requiring BMC CI classes that exceed these limits to be restructured or split before import.
Enum and Status Value Transformation
BMC uses numeric status codes and numbered selection field values across all ITSM modules that must be individually mapped to JSM's configurable workflow statuses and select lists through a comprehensive value mapping table.
Knowledge Base Format Conversion
BMC Knowledge articles use their own article lifecycle and HTML format, which must be transformed to Confluence storage format since JSM does not host knowledge articles natively.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
How long does a BMC Helix to Jira Service Management migration take?
A typical enterprise migration takes 4 to 12 weeks, including discovery, schema setup, script development, test migration, production migration, and post-migration QA. Small ticket-only moves with no CMDB can be done in 2 to 4 weeks. Add 2 to 4 weeks for environments with heavy CMDB customization or compliance requirements.
Can I migrate BMC Helix CMDB data to JSM Assets without losing relationships?
Yes, but each BMC CI class must be mapped to a JSM Assets Object Type, and every CMDB relationship must be rebuilt using AQL-based reference attributes. Multi-value references require separate import rows with merge-and-append settings. Load parent assets before child assets to avoid orphaned records.
Is there a native migration tool for BMC Helix to Jira Service Management?
No. Neither BMC nor Atlassian provides a native migration tool for this path. All migrations require API-based extraction from BMC and API or CSV-based loading into JSM. Third-party tools like Precision Bridge offer partial automation but still require mapping configuration and typically lack deep CMDB support.
What is the biggest risk in a BMC Helix to JSM migration?
Broken CMDB relationships. BMC Helix stores CI relationships in a deeply typed hierarchical model. If CIs load into JSM Assets without correctly mapped AQL references, CI-to-Incident links and CI-to-CI dependencies break silently. Fixing this after go-live is expensive and disruptive.
Is CSV export enough for a BMC Helix to JSM migration?
Usually not for production. BMC mid-tier report exports default to 2,000 records, no relational data is preserved, and Jira's CSV import path can make JSM comments public. CSV works for small closed-ticket archives. Use the API for anything larger or with mixed public and internal history.