BMC Helix ITSM to Jira Service Management or Freshservice: when mid-market teams should leave
Short answer
Leave BMC Helix ITSM when the platform is bigger than the problem you are solving: a mid-market IT team, typically 15 to 100 agents, that uses mainly incident, request, change and a modest CMDB, struggles to staff Helix administration, and is not using the discovery, AIOps and ServiceOps depth Helix is built for. Stay if those operations capabilities are central to how you run IT, or if your customisations encode processes you cannot simplify. If you leave, Jira Service Management is usually the better destination when engineering already lives in Jira and you want ITSM and DevOps on one platform; Freshservice is usually better when you want the lowest admin effort, an ITIL-shaped product out of the box, and a quick rollout. On Nov 3, 2026, the Jira Service Management pricing page showed Standard at $21.50 and Premium at $55.28 per agent per month (monthly billing, default team size), and the Freshservice pricing page showed Starter $19, Growth $49 and Pro $99 per agent per month billed annually. BMC Helix pricing is quote-only through BMC Helix's pricing request form, so we give no estimate for it. Time the move to your renewal date, and plan four to six months for a clean migration.
Contents
- Who this guide is for
- The context: what BMC Helix is good at, and what changed
- When mid-market teams should leave, and when they should stay
- Understanding your Helix licence before you decide
- JSM or Freshservice: which destination fits
- What migrates, and what you rebuild
- A phased migration plan
- Risks and how to manage them
- Best for, and wrong choice when
- Frequently asked questions
Who this guide is for
This guide is for IT leaders and service managers at mid-market organisations, roughly 300 to 5,000 employees, who run BMC Helix ITSM (or an older Remedy estate that became Helix) and are asking whether it is still the right tool. You may have inherited Helix from a larger parent company, a previous CIO, or a time when the IT estate was more complex than it is today. You may have a renewal coming up. Or your Helix administrator has left and you have discovered how hard the role is to refill.
We compare two destinations that come up most often for teams of this size: Atlassian's Jira Service Management (JSM) and Freshworks' Freshservice. If you are considering ServiceNow instead, our BMC Remedy to ServiceNow migration guide and BMC Helix vs ServiceNow comparison cover that path.
Facts about BMC Helix come from the BMC Helix ITSM product page and the BMC Helix ITSM Suite service documentation. Prices for JSM and Freshservice come only from their official pricing pages, checked on Nov 3, 2026. BMC Helix is quote-only, so we give no price for it. Opinions about when to leave and which destination fits are ours, from running ITSM migrations, and are labelled as such.
The context: what BMC Helix is good at, and what changed
BMC Helix ITSM is the SaaS successor to BMC Remedy. The BMC Helix ITSM product page positions it as integrated, AI-driven service management with integrated discovery and AIOps, unified service and operations management, AI-driven incident clustering, change risk analysis, and Microsoft Teams ChatOps. Its listed ITSM capabilities include AI agents, service level management, configuration management (CMDB), asset management, Digital Workplace, dashboards and analytics, knowledge, incident and problem management, proactive problem management, change and release management, and Multi-Cloud Broker.
Those are real strengths, and they are aimed at complex enterprise environments. BMC Helix itself describes the target as "service and operations excellence in complex enterprise environments".
There is also corporate context. According to Montagu's announcement dated October 2, 2026, Montagu completed its acquisition of a majority stake in Helix through a carve-out from BMC Software, and "Helix is now a fully independent company", with funds managed by KKR retaining a minority stake. Ownership change is not a reason to migrate on its own, but it is a sensible moment to check your contracting entity, roadmap commitments and support arrangements, and to ask whether the platform still fits.
When mid-market teams should leave, and when they should stay
This is the decision that matters most, and it is not a feature comparison. In our experience, the teams that benefit from leaving Helix share most of the following signs. The teams that should stay share the opposite ones.
| Signal | Points to leaving | Points to staying |
|---|---|---|
| Processes in active use | Incident, request, knowledge, basic change; problem management light or absent | Mature problem, change and release with heavy volumes and audit requirements |
| CMDB and discovery | CMDB mostly end-user devices and key applications; discovery not used or not trusted | Discovery, service models and impact analysis drive daily operations |
| Operations integration | Monitoring and event management live in other tools | Helix operations management and AIOps are part of how you run IT |
| Admin capacity | No dedicated Helix administrator, or one person with no backup | A capable platform team or partner with Helix and AR System skills |
| Customisation | Old Remedy customisations nobody fully understands | Customisations that encode valuable, documented processes |
| Scope beyond IT | No plans to extend beyond IT, or other teams already on Jira | Helix is already used for HR, facilities or other lines of business you want to keep |
| Commercial position | Renewal coming with no clear growth in value | Recent multi-year commitment with ramp still to come |
The questions we ask in a first workshop
- Which Helix applications and modules do agents open in a normal week? (Ask the agents, not the licence list.)
- How many active fulfillers, and how many named versus concurrent licences?
- Which integrations would break operations if Helix went down tomorrow?
- Who can change a form, a workflow or an approval rule today, and how long does it take?
- What does the CMDB feed, and who trusts it?
Our view
If more than half of your Helix capability is unused and you cannot staff the admin role, a simpler platform will almost always serve a mid-market team better. If the operations side of Helix is genuinely in use, the right move is usually to simplify within Helix, not to leave.
Understanding your Helix licence before you decide
Your exit timing and your migration scope both depend on what you have bought. The BMC Helix ITSM Suite service documentation sets out the licensing terms for the BMC Helix ITSM Suite service. The points most relevant to a mid-market decision:
- ITSM Suite user licences are sold per named user or per concurrent user (SaaS). A concurrent licence is consumed from a shared pool when a user logs in and "is held for a minimum of one hour in case of inactivity".
- End users accessing through the BMC Helix Digital Workplace portal require only a Read licence type. Each named ITSM Suite licence entitles 100 named Digital Workplace Basic users, and each concurrent licence entitles 250.
- Each customer must have a minimum of three named user licences to carry out administrative activity, and BMC recommends administrators have a fixed licence.
- The suite includes Development, Quality Assurance and Production environments; additional environments are available for an additional fee. Non-production environments have the same licence capacity as production.
- BMC Helix Digital Workplace Advanced (including live chat) and BMC Helix Multi-Cloud Broker are optional add-ons for an additional fee.
- Customers can stay on a version no less than n-2 of the current BMC Helix ITSM version.
- The documentation states that licensing terms in your governing master agreement take precedence over the published description.
BMC Helix does not publish prices; its site directs buyers to a pricing request form. So the useful preparation is not a price estimate but a clear view of your contract: renewal date, notice period, licence mix (named, concurrent, read), add-ons, and any data export or transition assistance terms.
Pull these from your Helix contract now
- Renewal date and notice period for non-renewal or reduction.
- Named and concurrent licence counts, and actual peak concurrent usage.
- Add-ons (Digital Workplace Advanced, Multi-Cloud Broker, discovery, operations products).
- Any terms on data export, extended access after term end, or transition assistance.
- Whether other business units share the same contract.
JSM or Freshservice: which destination fits
Both are credible ITSM destinations for a mid-market team leaving Helix. They differ mainly in philosophy: JSM is a service desk on the Jira platform, flexible and developer-friendly; Freshservice is an ITIL-shaped product designed to work with little configuration.
| Jira Service Management | Freshservice | |
|---|---|---|
| Published price (checked Nov 3, 2026) | Free up to 3 agents; Standard $21.50, Premium $55.28 per agent per month (monthly billing, default team size); Enterprise via sales, annual only | Starter $19, Growth $49, Pro $99 per agent per month billed annually; Enterprise custom |
| Where ITIL processes sit | Premium adds advanced incident and problem management and change management, per the pricing page | Problem, change, major incident and release management are on Pro; SLA management and service catalog start on Growth |
| CMDB and assets | Assets included on Standard, Premium and Enterprise, with 5,000, 50,000 and 500,000 objects included; above that from $0.02 per object per month | Asset management licensed by Asset Units, sold in packs of 500 |
| Requesters and occasional users | Customers are free and unlimited, per the pricing page | Priced per agent; occasional agents via day passes from $3 |
| Deployment | Cloud; JSM and Assets also available as Data Center (self-managed) | SaaS only |
| Admin model | Very configurable; rewards Jira admin skills | Opinionated defaults; lower admin effort for standard ITIL |
| Best fit | Engineering-heavy organisations already on Jira, wanting ITSM and DevOps together | IT teams wanting fast rollout and low admin with ITIL out of the box |
Notes on reading these prices. JSM's price shown is monthly billing at the page's default team size; annual billing is tiered by user count. Freshservice's shown price is annual billing. Both vendors localise prices by region. Atlassian now presents JSM within its "Service Collection", which also includes Customer Service Management; its pricing page says each Service Collection user licence covers both JSM and CSM. Freshservice lists Freddy AI Copilot as a $29 per agent per month add-on on Pro and Enterprise.
Choose JSM when
- Your developers and DevOps teams already work in Jira, and you want incidents, changes and deployments linked natively.
- You have Jira administration skills in-house.
- You want the option of a self-managed Data Center deployment.
- Your request volume is high relative to agents, and free unlimited customers matter.
Choose Freshservice when
- You want ITIL processes to work with minimal design effort.
- Your IT team is small and does not want to become platform administrators.
- Speed of rollout is the priority.
- You value a single vendor packaging ITSM, asset management and optional ITOM features in tiered plans.
Match the plan to your Helix process scope
Teams leaving Helix are used to having problem, change, release and SLA management. On Freshservice, the Starter plan does not include SLA management or the service catalog, and problem and change management are on Pro. On JSM, change management and advanced incident and problem management are listed under Premium. Price the plan that matches the processes you actually run, not the entry price.
What migrates, and what you rebuild
A Helix exit is a redesign plus a data move. In our experience, the data move is the smaller part. Here is how the main objects usually map.
| Helix object | JSM destination | Freshservice destination | Approach |
|---|---|---|---|
| Incidents (open and recent closed) | Work items in a service project, with request types | Tickets (incidents) | Migrate open and a defined history window; archive the rest |
| Service requests and catalog | Request types and forms | Service catalog items | Rebuild; do not migrate the catalog as data |
| Change requests | Change work items with approval workflows | Changes (Pro and above) | Migrate open changes; rebuild change models and CAB |
| Problems and known errors | Problem work items | Problems (Pro and above) | Migrate open problems and known errors that still matter |
| Knowledge articles | Confluence knowledge base | Solution articles | Migrate after a content review; retire stale articles |
| CMDB CIs and relationships | Assets object schemas | Assets and CMDB (Asset Units) | Remodel classes; import a cleaned subset |
| People, groups, locations, companies | Users, teams, organisations; Assets objects | Requesters, agents, groups, departments, locations | Load from identity source where possible |
| SLAs and OLAs | SLA goals and calendars | SLA policies (Growth and above) | Rebuild from current agreements |
| Approvals, assignment and escalation rules | Automation rules and workflows | Workflow Automator and business rules | Rebuild; this is where most effort goes |
| AR System customisations | Redesign or drop | Redesign or drop | Decide per customisation; most should not be replicated |
Loading data into JSM
Atlassian's CSV importer can create work items in JSM Cloud from a CSV file. An Atlassian knowledge base article explains that to set the request type during a CSV import you map the column to the request type's ID rather than its display name. For CMDB data, the Assets import documentation describes CSV, JSON, Discovery and external imports into Assets; CSV files need a header row, objects are identified by the attribute set as the Label, and the expected date format for date attributes is MM/dd/yyyy unless you set another format in the import structure.
Loading data into Freshservice
Freshservice publishes a Freshservice bulk migration API article for its data migration partners. It describes bulk endpoints for tickets and notes that accept up to 50 records per request, an account-level limit of 10 requests per minute, attachments supplied as publicly accessible URLs with a maximum of 40 MB per entity, and a migration token in the request headers. During migration, email notifications for ticket assignment and CC are not sent, but Slack, Teams, business rules and workflows are not muted, so Freshservice recommends muting them before you start. Other entities use the standard public APIs.
Practical consequence
Rate limits shape the timeline. At 50 tickets per request and 10 requests per minute, very large ticket histories take a long time to load through the bulk endpoint. Decide early how much history you really need in the new tool, and archive the rest to a searchable store.
A phased migration plan
This plan reflects how we run Helix exits for mid-market teams. Timings are typical, not guaranteed; they depend on scope, data quality and how quickly decisions get made.
Phase 0: decide and align (2 to 4 weeks)
Run the usage workshop, confirm the destination, pull contract terms, set a target date ahead of the Helix renewal, and agree a history window for data migration.
Phase 1: design (3 to 5 weeks)
Design request types or catalog items, incident and change workflows, SLAs, groups and roles, the CMDB model, and integrations. Decide which Helix customisations to drop. Write the cutover plan.
Phase 2: build and data trial (4 to 6 weeks)
Configure the target tool, build integrations with identity, email, monitoring and chat, and run at least two trial data loads into a sandbox or test instance. Reconcile counts and spot-check records.
Phase 3: test and train (2 to 3 weeks)
User acceptance testing with agents from every group, training for agents and approvers, and a communication plan for employees on the new portal.
Phase 4: cutover and hypercare (1 to 2 weeks, then 4 weeks)
Freeze Helix changes, run the final delta load, switch email and portal routing, keep Helix read-only for reference during hypercare, and close out open items.
Cutover checklist
- Final delta export from Helix taken after the freeze.
- Notifications and automations muted in the target during the load, then re-enabled.
- Email channels redirected and tested end to end.
- Portal links in intranet, Teams or Slack updated.
- Helix set to read-only access for the agreed period.
- Reconciliation report signed off: counts by type and status, sample checks.
Risks and how to manage them
| Risk | Why it happens | Mitigation |
|---|---|---|
| Recreating Remedy-era complexity | Teams copy every form, field and status | Start from the destination's defaults and justify each addition |
| CMDB quality debt | Old CIs imported without review | Import a cleaned subset; rebuild relationships for key services only |
| Missed integrations | Undocumented scripts and email rules | Inventory integrations from Helix logs and network owners, not memory |
| Timeline collides with renewal | Decision made too late | Start at least six months before the notice date |
| Approver confusion | Approvals moved to a new tool without training | Short guides and an approver-only session |
| Loss of history | Only open records migrated | Agree an archive and how agents search it |
Best for, and wrong choice when
Staying on BMC Helix
Best for
Organisations whose IT operations depend on Helix discovery, AIOps and service models; teams with strong Helix skills; estates with documented, valuable customisations.
Wrong choice when
You use a fraction of the platform, cannot staff administration, and the renewal buys capability you do not use.
Moving to Jira Service Management
Best for
Engineering-led organisations on Jira; teams that want ITSM and DevOps linked; teams with Jira admin skills; organisations that want a Data Center option.
Wrong choice when
You want ITIL to work with minimal configuration and have no Jira administrators.
Moving to Freshservice
Best for
Lean IT teams wanting fast rollout, low admin and ITIL processes out of the box.
Wrong choice when
You need self-hosting, or your processes depend on deep custom data models that need a platform rather than a product.
Frequently asked questions
How much does BMC Helix ITSM cost?
BMC Helix does not publish ITSM prices; it asks buyers to submit a pricing request form. Its documentation says ITSM Suite licences are sold per named user or per concurrent user, with read licences for portal end users.
When should a mid-market team leave BMC Helix?
When most of the platform is unused, you cannot staff Helix administration, and you do not rely on its discovery, AIOps and service modelling. If those operations capabilities are central, simplifying within Helix is usually better than leaving.
Is Jira Service Management or Freshservice better for leaving Helix?
JSM suits engineering-led organisations already using Jira and wanting ITSM and DevOps together. Freshservice suits lean IT teams that want ITIL processes with low admin effort and a quick rollout.
How much do JSM and Freshservice cost?
On Nov 3, 2026, JSM listed Standard at $21.50 and Premium at $55.28 per agent per month on monthly billing at the default team size, with a Free plan for 3 agents. Freshservice listed Starter $19, Growth $49 and Pro $99 per agent per month billed annually, with Enterprise on a custom quote.
Can I migrate my Helix CMDB?
Yes, but remodel it rather than copy it. JSM Assets accepts CSV, JSON, Discovery and external imports. Freshservice manages assets in its CMDB licensed by Asset Units. Import a cleaned subset focused on services you actually support.
How long does a BMC Helix migration take?
For a mid-market team, four to six months from decision to cutover is typical in our experience, longer with heavy customisation or many integrations. Start at least six months before your Helix notice date.
What happened to BMC Helix and BMC?
According to Montagu's announcement of October 2, 2026, Montagu completed its acquisition of a majority stake in Helix through a carve-out from BMC Software, and Helix is now an independent company, with funds managed by KKR retaining a minority stake.