BMC Helix to Jira Service Management Migration: The Complete Guide

Why Enterprise IT Teams Migrate from BMC Helix to Jira Service Management

A BMC Helix to Jira Service Management migration (also commonly searched as a BMC Remedy to JSM migration) moves all ITSM data—incidents, problems, changes, service requests, CMDB/assets, work logs, knowledge articles, and attachments—from BMC's AR System platform into Atlassian's JSM Cloud ecosystem.

Teams move for three concrete reasons:

1. 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.
2. 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.
3. 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.

If you are evaluating JSM against other enterprise ITSM platforms, see our ServiceNow vs Jira Service Management Architecture Guide for a detailed comparison.

What Makes This Migration Non-Trivial

You are not mapping one ticket table to another. You are converting Helix tickets and CMDB classes into three distinct JSM layers simultaneously: issues, request types, and Assets schemas. That three-layer model is what makes a naive table-to-table copy impossible.

Two architectural differences drive most migration complexity:

• Data model mismatch. Incident Management gets users up and running after disruptions, and Problem Management determines the root cause and corrects it by using BMC Helix ITSM: Change Management processes. BMC Helix stores these across dedicated AR System forms (HPD:Help Desk, PBM:Problem Investigation, CHG:ChangeInterface) with deep relational links. JSM collapses all of them into Jira Issues differentiated by Issue Type and Request Type, with a fundamentally different relationship model. Critically, one JSM work type can back many request types, so portal taxonomy is a separate mapping decision from workflow design.
• CMDB architecture. BMC Helix CMDB uses a hierarchical class-based model with namespaced CI classes (e.g., BMC.CORE/BMC_ComputerSystem) and typed relationships like BMC_HostedSystemComponents and BMC_MemberOfCollection. Jira Assets uses a schema-based structure that requires significant setup before you can start tracking assets. JSM Assets uses flat object schemas where relationships are defined through AQL-based attribute references, not class inheritance. Each BMC CMDB relationship type must be mapped to a JSM Assets reference attribute with custom AQL.

The integration surfaces are also completely different. Helix relies on interface forms such as HPD:IncidentInterface_Create, PBM:ProblemInterface_Create, and CHG:ChangeInterface_Create, plus separate work log and association forms. JSM request creation uses a service desk ID, a request type ID, and request field values in a single payload. You cannot port one pattern to the other without a transformation layer.

How BMC Helix Objects Map to Jira Service Management

The mapping table below covers the core ITSM objects. Every row includes the real BMC Helix AR System form name and the corresponding JSM target.

Field-Level Mapping and Data Type Transformations

BMC Helix AR System fields use internal numeric Field IDs, not human-readable names, at the API level. BMC Helix uses internal Field IDs. While the script uses the useLabels feature to try and fetch human-readable names, you should verify the specific Field IDs for 'Status', 'Assigned Group', and 'Workaround' in your specific deployment.

Key transformation rules:

• 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.
• 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.
• 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.
• Status Reason fields: A BMC Helix Status_Reason may not exist in your new Jira workflow. Map legacy status reasons to a custom text field to preserve historical context.

What Data Cannot Be Migrated 1-to-1

Be honest with stakeholders about these known limitations:

• Multi-level CMDB relationship hierarchies. BMC Helix supports arbitrary depth CI relationships (Server → Virtual Machine → Application → Service). Jira Assets doesn't support importing multi-value object references through CSV. When you use a delimiter like || or comma, the importer only reads the first reference and ignores the rest. Multi-value references require separate import rows with merge-and-append settings.
• 120 attributes per object type. After 30th of September 2024 we will be introducing a new limit of 120 attributes per object type (which also includes any attributes inherited from a parent object). BMC CI classes with more than 120 attributes must be restructured or split before import.
• 2 unique constraints per object type. After 31st of October 2024 we will be introducing a limit of 2 unique constraints per object type.
• SLA history and compliance data. JSM does not accept imported SLA records. Archive BMC SLA reports before decommissioning.
• BMC workflow and filter logic. AR System active links, filters, and escalations do not export. Rebuild equivalent automation in JSM automation rules.
• Audit log entries. BMC AuditLogSystem records cannot be imported as native JSM audit entries. Convert to issue comments with original timestamps or archive externally.
• Approval and CAB history. Approval chains need workflow redesign and, in most cases, separate archival of source evidence.
• Support group behavior. Helix support groups involve assignment rules, queues, and routing logic that must all be rebuilt in JSM.
• Knowledge article lifecycle. BMC Knowledge articles have their own review and publish states. Confluence has a different publishing model. Categories and lifecycle states require manual re-mapping.

Migration Approaches: CSV Export vs API vs Managed Service

There is no native one-click migration path from BMC Helix to Jira Service Management. Neither BMC nor Atlassian provides a built-in migration tool. Every approach requires extraction, transformation, and loading.

Decision shortcuts:

• 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.
• Enterprise with CMDB, 100K+ records, compliance requirements: Managed migration service.

For a complete list of preparation steps regardless of your chosen approach, review our Jira Service Management Migration Checklist.

API Limits and Throughput Planning

The migration usually succeeds or fails on API behavior, not on mapping spreadsheets. You need to plan around two completely different integration surfaces.

BMC Helix Extraction

BMC Helix exposes user management through its AR System REST API at https://<tenant>.onbmc.com/api/arsys/v1/entry/User. Authentication uses a proprietary AR-JWT token scheme, not standard Bearer, obtained by POSTing credentials to /api/jwt/login; the response body is a raw JWT string, not a JSON object.

The same /api/arsys/v1/entry/{FormName} pattern applies to all ITSM forms:

• Incidents: GET /api/arsys/v1/entry/HPD:Help Desk?offset=0&limit=500
• Changes: GET /api/arsys/v1/entry/CHG:ChangeInterface?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

Rate limit thresholds are not publicly documented and are configurable per tenant, meaning behavior can differ across environments with no standard Retry-After header to rely on. Pagination is offset-based with no cursor mechanism.

The AR System REST API does not return a total record count in its response. Pagination must continue until a partial page is returned. The default value is 500 for the CMDB API page size. For ITSM form queries, the practical extraction approach is to set limit=500 or limit=1000 per page and increment the offset until fewer results than the limit are returned.

BMC does not publish numeric rate limits; throttling is governed by server-side thread pool and Max Entries configuration parameters with no rate-limit response headers and no Retry-After support, making backoff logic harder to implement reliably.

BMC also offers a Simplified REST API for supported use cases, but it works on core forms and does not execute interface-form workflow. That makes it attractive for read-side discovery and dangerous to assume for every write-side use case. For CMDB extraction, use the Graph Walk query when relationships matter more than flat attribute dumps.

JSM Loading

Jira Service Management has two distinct rate limiting systems relevant to migration:

1. JSM Issues API (Jira Cloud REST API): Jira Cloud uses a points-based model to measure API usage. Instead of simply counting requests, each API call consumes points based on the work it performs. Write operations cost 1 point each. With standard quotas, you can typically create 1,000 to 2,000 issues per hour before approaching limits.

2. JSM Assets API: All endpoints are rate-limited to 1,000 requests per minute per instance with a total limit of 10,000 requests per minute per instance. Currently no information is provided when rate limiting is triggered (HTTP 429 response) to the client making the requests as to when they should continue sending requests. Your migration script must implement its own backoff logic with no guidance from the server.

Throughput Math

Think in calls per object, not objects per minute. If an Assets object needs one POST to create, one reference lookup, and one relationship update, a 1,000 requests/minute cap becomes roughly 330 objects per minute before retries—approximately 20,000 objects per hour in a clean run. Relationship-heavy CMDB loads will be slower.

At a sustainable pace of 800 requests per minute (leaving 20% headroom below the 1,000 limit), and assuming each CI requires 1 POST plus 1 to 2 reference-linking requests, expect roughly 250 to 400 CIs loaded per minute, or approximately 15,000 to 24,000 CIs per hour. A CMDB with 100,000 CIs takes approximately 4 to 7 hours of uninterrupted loading.

For issue creation, plan for 1,000 to 1,500 issues per hour including comments and attachments (each attachment requires a separate multipart upload). A realistic enterprise migration involving 1 million tickets and 3 million comments will take over 48 hours of continuous API processing. You must plan for delta syncs to capture records updated during this processing window.

Step-by-Step BMC Helix to JSM Migration Process

The order of operations matters. Loading records in the wrong sequence creates orphaned references that are expensive to fix. Load reference data before transactional data to prevent broken foreign keys.

Step 1: Freeze the Target JSM Model

Finalize the company-managed project structure, request types, workflows, custom fields, Assets object schemas, and SLA policies before the first full export. Do not start extraction against a moving target. Team-managed project import limitations are real and worth verifying up front—CSV import does not support mapping company-managed work types to team-managed work types.

Step 2: Extract and Map Users, Groups, and Enums

Extract all People records and Support Groups from BMC Helix. Build identity maps and enum lookup tables (statuses, priorities, categories) before touching tickets. Create corresponding users in Jira and assign them to the correct Jira Groups. If an incident references an assignee who does not exist in Jira, the API will reject the ticket creation request.

Allocate time for agent training on JSM. Agents accustomed to BMC Smart IT or the classic Remedy console will need 2 to 4 hours of guided walkthrough on JSM's queue-based workflow, keyboard shortcuts, and Assets lookup panel. Plan a 30-minute "day one" reference guide and a follow-up Q&A session in week one.

Step 3: Extract Data from BMC Helix

Authenticate and paginate through each form:

import requests
 
BASE_URL = "https://your-instance.onbmc.com"
 
# Step 1: Get AR-JWT token
token_resp = requests.post(
    f"{BASE_URL}/api/jwt/login",
    data={"username": "svc_migration", "password": "your_password"}
)
token = token_resp.text  # Raw JWT string, not JSON
 
headers = {"Authorization": f"AR-JWT {token}"}
 
# Step 2: Paginate through incidents
all_incidents = []
offset = 0
limit = 500
while True:
    resp = requests.get(
        f"{BASE_URL}/api/arsys/v1/entry/HPD:Help Desk",
        headers=headers,
        params={
            "offset": offset,
            "limit": limit,
            "fields": "values(Incident Number,Status,Description,Impact,Urgency)"
        }
    )
    entries = resp.json().get("entries", [])
    all_incidents.extend(entries)
    if len(entries) < limit:
        break
    offset += limit
 
# Step 3: Logout to release server session
requests.post(f"{BASE_URL}/api/jwt/logout", headers=headers)

Repeat for changes (CHG:ChangeInterface), problems (PBM:Problem Investigation), work logs (HPD:WorkLog), and CMDB CIs via /api/cmdb/v1.0/instances/{dataset}/{namespace}/{className}.

Step 4: Clean and Transform

• Normalize status values using your mapping table.
• Convert BMC epoch timestamps to ISO 8601.
• Deduplicate records (BMC environments with long histories often contain duplicate entries from import/export cycles).
• Flatten multi-value fields that JSM does not support natively.
• Separate public work logs from private work logs to set the correct internal/external comment flag in JSM.

Step 5: Build Assets Schemas and Load CIs

Create the target Object Schemas and Object Types in JSM Assets first. Load the primary CI objects via CSV import or Assets REST API. Once the base objects exist, run a secondary pass to build relationships using AQL-based reference attributes. Use stable source keys (CI ID or reconciliation ID) for AQL mapping rather than display labels.

If a BMC CI has 15 nested child assets, you must create the parent asset in JSM first, create the children, and then update the children with the AQL reference to the parent. Failure to follow this exact sequence results in orphaned assets that do not appear in dependency graphs.

Step 6: Load Issues in Dependency Order

Load records in this sequence to prevent broken references:

1. Issues (Incidents, Problems, Changes, Service Requests) via Jira REST API using /rest/api/3/issue or /rest/servicedeskapi/request. Store the original BMC record ID in a custom Jira field for auditability.
2. Comments and Work Logs as issue comments, respecting the internal/external flag. Public source history becomes public comments. Analyst-only history becomes internal notes.
3. Attachments uploaded to their parent issues or Assets objects. Load only after the parent record exists.
4. Issue Links connecting related incidents, problems, changes, and CIs.

for record in batch:
    try:
        push(record)
    except RateLimitError as err:
        sleep(err.retry_after or next_backoff())
        retry(record)
    except TransientError:
        retry(record)
    except ValidationError:
        write_dead_letter(record)

That retry pattern is boring on purpose. What breaks migrations is usually missing replay logic, missing dead-letter logging, or no way to re-run only the failed slice.

Step 7: Rebuild Relationships

BMC Helix relationships (incident-to-CI, incident-to-problem, change-to-CI) must be re-created using JSM issue links and Assets object references. This is typically the most error-prone step. Log every failed relationship creation for manual review.

Step 8: Delta Sync and Cutover

Run a delta sync to capture records created or updated during the bulk load window. If your cutover window exceeds a few hours, consider using BMC's Helix Integration Service for real-time ticket synchronization during the transition period. Keep BMC Helix as the system of record until sign-off and final delta replay.

What a Failed Migration Looks Like

To illustrate why the steps above matter, here is an anonymized composite drawn from common migration failure patterns:

Scenario: A 300-agent organization migrated 180,000 incidents and 45,000 CIs from BMC Helix to JSM Cloud. The team loaded CIs and incidents in parallel rather than sequentially. Result: 12,000 incident-to-CI links (approximately 7% of total) failed silently because the referenced CI had not yet been created at the time of issue link creation. The JSM REST API returned 201 Created for the issue itself but dropped the invalid asset reference without an error. The team discovered the broken links three weeks post-go-live when agents reported that incident records showed no associated CIs. Rebuilding those 12,000 links required a dedicated engineer for 11 working days—effectively a second mini-migration.

Root cause: No dependency ordering, no post-load relationship validation, and no dead-letter log for failed link creations.

Lesson: Always load CIs before issues. Always validate relationship counts post-load. Always log failed link creations to a dead-letter queue for replay.

Timeline, Phases, and Resourcing

Total: 4 to 12 weeks for most enterprise environments. A small ticket-only migration with no CMDB can be done in 2 to 4 weeks. Add 2 to 4 weeks for environments with heavy CMDB customization, multiple companies/tenants, or compliance requirements.

Multi-Tenant BMC Environments

BMC Helix environments with multiple companies or tenants (common in managed service providers) require a separate mapping and loading pass for each tenant. Each tenant's data must be routed to the correct JSM project or organization. If your BMC instance serves 5 companies, expect the discovery and mapping phase to take 3 to 5 weeks instead of 1 to 2. User identity mapping is particularly complex because the same person may exist in multiple company contexts in BMC.

Phased vs Big-Bang vs Incremental

• Big-bang: Migrate everything over a weekend maintenance window. Works for organizations with fewer than 50,000 total records and a clean, well-documented BMC environment.
• Phased: Migrate tickets first, then CMDB, then knowledge. Lower risk, but requires running both systems in parallel for 2 to 4 weeks.
• Incremental: Continuously sync new records during the transition period. Only viable if you build or buy a real-time sync connector, such as through Helix Integration Service.

Risk Register

Before deciding what data to bring over, read our Help Desk Data Migration Playbook: What Data to Move and What to Leave Behind.

What Agents and End-Users Notice After Go-Live

During a well-executed migration, agents experience 0 to 4 hours of read-only downtime on BMC Helix while the final delta load runs. The actual downtime depends on the number of open tickets requiring delta sync, the volume of records modified during the bulk load window, and your API throughput rate.

After cutover:

• 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.
• Saved views and dashboards must be rebuilt. BMC Smart IT views and Helix Dashboards do not export to Jira dashboards.

During the cutover weekend, configure BMC Helix to forward incoming emails to the new JSM mail handler. This ensures no customer requests are lost while DNS records propagate. Keep the BMC Helix instance in read-only mode for 30 days post-go-live to give agents a safety net for reference.

End-User Change Management

Notify end-users 2 weeks before cutover about the new portal URL and any changes to request categories. If your BMC portal used a custom domain, configure a redirect to the JSM customer portal. Prepare a one-page visual guide showing how common actions (submit a request, check ticket status, approve a change) map from the old portal to the new one. The most common post-migration complaint from end-users is not missing data—it is not finding the right request type in the new portal.

Compliance and Audit Considerations

Organizations subject to ITIL audits, SOC 2, or ISO 27001 controls need a complete record of incident lifecycle states. Migrate all status transitions as comments with timestamps to maintain an auditable trail in JSM. If auditability requires original timestamps and authors, preserve them in custom fields or archived exports—do not assume that recreating the ticket recreates BMC-native audit behavior. For SOC 2 and ISO 27001, document the migration itself as a change record with before/after evidence, as auditors may ask for proof that no records were lost during the transition.

How to Validate a BMC Helix to JSM Migration

Do not rely on UI spot checks to validate a migration. Run programmatic validation across four layers:

1. 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.
2. 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.
3. 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.
4. 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.

Check attachment integrity by downloading 50 random files from Jira and verifying they open correctly.

Build a rollback plan before go-live. If validation fails on more than 5% of records, it is faster to delete the JSM project data and re-run a corrected migration than to patch records individually. Remember that Jira Cloud does not offer native project-level restore—your rollback plan must account for this by scripting a project wipe or using a pre-migration site backup.

For a structured testing checklist, see our Help Desk Data Migration QA Checklist.

Build In-House or Use a Managed Migration Service

When In-House Works

• Your BMC environment is vanilla: no custom forms, no CMDB, under 20,000 records.
• You have a Python/Node engineer available for 3 to 6 weeks with no competing priorities.
• You are moving mostly incidents and service requests.
• You are comfortable with the risk of 1 to 2 re-migration cycles if something breaks.
• Estimated in-house engineering cost: 160 to 480 hours at your loaded engineer rate.

When In-House Fails

• BMC environments with a mature CMDB (10,000+ CIs across 20+ CI classes) require weeks of AQL mapping, testing, and relationship validation. The CMDB mapping layer alone typically accounts for 40% of total migration effort.
• Custom AR System forms with non-standard field IDs break generic migration scripts silently.
• BMC does not publish numeric rate limits; throttling is governed by server-side thread pool and Max Entries configuration parameters with no rate-limit response headers and no Retry-After support, making backoff logic harder to implement reliably.
• The hidden cost is not the first load. It is the 3 to 5 re-migration cycles, each taking a full day, when edge cases surface that the initial mapping missed: broken CMDB relationships, extended downtime during cutover, and records that need to be re-migrated when API rate limits cause silent failures.

Where a Managed Service Adds Value

A managed migration service provides pre-built extraction connectors, field-mapping libraries for BMC ITSM forms, and validated relationship-rebuilding logic for CMDB data. The primary value is in reducing re-migration cycles from 3–5 down to 0–1, which compresses the timeline and eliminates the extended downtime that results from discovering mapping errors in production.

Managed migration services for BMC Helix to JSM typically cost $30,000 to $150,000+ depending on record volume, CMDB complexity, number of custom forms, and compliance documentation requirements.

ClonePartner has completed ITSM migrations involving complex CMDB relationship rebuilds and custom field transformations. The team handles the BMC AR System API extraction (including non-documented rate limit behavior), JSM Assets AQL mapping, and end-to-end validation. For a deeper look at JSM capabilities post-migration, see our Ultimate Jira Service Management Guide for 2026.