Migrate from Jira Service Management to iTop: what the move involves
The move from Jira Service Management to iTop is mainly a rebuild, not a data copy. You recreate the CMDB, request types and SLAs in iTop's own model, then load configuration items and open tickets into it. If your renewal is coming up, or your Data Center estate is heading toward its end of sale on March 30, 2026 and read-only status on March 28, 2029, that is the timeline to plan against, and the rebuild is what determines whether you hit it comfortably.
Most teams run this with their internal platform or ITSM team in the lead, supported by an implementation partner for the schema design, integration and cutover. The internal team knows which services, owners and approval paths matter. The partner or Combodo's commercial consultancy can carry the iTop-specific modeling, the CSV import mappings and the data consistency audits. Effort rises with the number of object classes you need, the depth of your Assets relationships and how many request types carry approval logic. Risk concentrates in the CMDB: Jira's Assets object schemas do not map one to one onto iTop classes, so reference fields and discovery data need deliberate mapping before any bulk load.
Treat the first phase as a decision exercise. List each Assets object type, its attributes and the teams that depend on its relationships, then decide which iTop class, field or extension covers it. Confirm with your own environment whether iTop's CSV import and data synchronization cover the relationships you rely on, and test the load on a copy of real records. Ask any implementation partner to price the work from a written scope that lists the object classes, request types, SLA rules and integrations in writing, since those four items drive most of the cost.
Which Jira Service Management capabilities map to iTop and which need rework
This table compares the main Jira Service Management capabilities with what iTop's documented features cover for an internal IT service desk. Read each row as clean (a documented iTop equivalent), needs rework (the equivalent exists but the configuration, data or process must be rebuilt) or gap (no documented equivalent, so confirm before committing). The main takeaway is that the CMDB and incident, change and SLA handling map well, while automation rules and Atlassian apps need a separate check in your own environment.
| Capability | iTop position | Status | What to confirm or rebuild |
|---|---|---|---|
| Queues and request types | Helpdesk and incident management with customizable ticket classes | Needs rework | Recreate each JSM request type as an iTop ticket class or form, then map queues to agent teams and assignment rules |
| Incident and change handling | Incident management and change management are both listed in the iTop README | Needs rework | Confirm that your approval and state transitions can be expressed in iTop lifecycles before migrating open tickets |
| Assets and object schemas | Fully customizable CMDB with CSV import and data consistency audits | Needs rework | Export Assets as CSV, redesign object classes and relations in iTop, then load and audit the data before go-live |
| Service and contract management | Service and contract management is part of the iTop feature set | Clean | Check that your service catalog and contract records map field by field to iTop's service and contract objects |
| SLAs | Customizable SLA management is listed in the iTop README | Needs rework | Rebuild SLA targets, calendars and escalation rules in iTop, since a JSM backup does not carry them over |
| Impact analysis | Graphical impact analysis across the CMDB | Clean | Validate relations loaded from Assets so the impact views reflect real service dependencies |
| Approvals and automation rules | Not described in the iTop README | Gap | Inventory every JSM automation rule and approval step, then confirm equivalents with Combodo or in a test instance |
| Apps and Marketplace integrations | Extensions are distributed through the iTop Hub | Gap | List each Atlassian app in use and check whether a Hub extension or custom integration covers it |
| Reporting | Not detailed in the README beyond consistency audits and data views | Needs rework | Rebuild dashboards and KPIs from the iTop data model and confirm which reports need custom development |
Which exports carry the data and what the Assets CSV export covers
Jira Service Management data reaches iTop through several separate paths, and none of them moves everything in one step. The backup manager, the Assets CSV export and the integrations around the desk each carry a different slice, so the migration plan has to account for each one. Work through the cards in order before you map any field into iTop.
Backup manager contents
The Jira Cloud backup manager captures work items, comments, users and groups, and project configuration. Treat it as the base copy of your service desk history, not as a full migration package. Confirm with your Atlassian administrator which projects and request types are in scope, then keep a dated copy of the backup in your own storage before any transformation starts. Check that the archive opens and that ticket counts match the source before you rely on it.
Backup exclusions to rebuild
The backup leaves out automation rules, third-party apps and Assets. Each of these needs its own inventory before cutover. List every automation rule by project, record its trigger, condition and action, and decide whether iTop should replace it with a workflow rule, a notification or an external script. Apps often hold approval flows, forms or SLA calculations, so document what each one does and who depends on it.
Assets CSV export for CIs
Assets is exported separately from the work item backup, so configuration items need their own extraction. Export each object schema as CSV and keep the object type, attribute names and reference fields together. Relationships between servers, applications and services often sit in reference attributes that a flat file will not show clearly, so record them in a separate mapping sheet. Plan to load configuration items into iTop before tickets that reference them.
Attachment backup spacing
When attachments are included in a backup, Atlassian requires 48 hours between backups. Plan the export window around that interval. If the first attempt fails or needs a rerun, you lose a full day, so schedule a rehearsal backup early and a final backup close to cutover. Keep the attachment archive separate from the metadata so you can test re-linking attachments to tickets in iTop.
Email, SSO and monitoring feeds
Email intake, single sign-on and monitoring feeds that create or update tickets are integrations, not data, so no export carries them. List every mailbox that creates requests, every identity provider used for agent and customer sign-in, and every monitoring tool that posts alerts into the desk. For each one, decide whether iTop will receive it through its mail collector, an authentication connector or an API call, and confirm that option against the iTop documentation for your version.
Confirm the target data model
Before you run any export, decide how iTop classes will hold the data. Map Jira request types to iTop ticket classes, map Jira organizations and users to iTop persons and teams, and map Assets object types to iTop configuration item classes. Write this mapping down and have the service owners sign it off. Gaps found here are cheap to fix. Gaps found after import are much harder to correct across linked records.
How to sequence the migration from inventory to decommission
The sequence moves the service desk from Jira Service Management to iTop in stages, so each stage produces a checked artifact before the next one starts. Teams keep Jira running until iTop has passed a pilot and a parallel run, and only then retire it.
Inventory request types, queues, SLAs and automation
The service desk owner and a JSM administrator list every request type, queue, SLA target, escalation, automation rule and approval flow in use, including the ones nobody has touched in a year. Automation rules and connected apps are not in a Jira Cloud backup, so they must be recorded by hand from the project settings. The output is an inventory workbook with a row for each item, its owner, its monthly volume if the reports show it, and a yes or no on whether it must survive the move.
Map Assets schema to iTop classes
Using the Assets CSV export, the team maps each JSM object type and its attributes to an iTop class, attribute and relation. Object references, such as an application that depends on a server, need an explicit target in iTop, and inconsistent or duplicate records should be resolved before import rather than during it. The output is a field mapping sheet signed off by the CMDB owner, plus a list of records to clean or drop.
Build the iTop pilot and import through CSV
The platform team installs iTop on a small test instance that follows the requirements published by Combodo, with a PHP version and a MariaDB release within the supported range, and GraphViz present. The mapped CSV files are imported into a sample of configuration items, request types and SLA definitions, then the data consistency audit is run. The output is a validated pilot CMDB and a short log of rejected rows with the reason for each.
Test the pilot with real agents
A small group of agents works a set of recent incidents and service requests in the pilot, using the same categories, escalations and SLA clocks that JSM applies today. They check that impact analysis returns the expected dependencies, that notifications reach the right people, and that reports match the numbers in JSM for the same period. The output is a pilot sign-off listing each gap, its owner and whether it is closed or accepted as a known difference.
Run a parallel period with synchronization or re-import
Both systems stay open while new configuration items and requests are kept aligned, either through iTop data synchronization where the data sources support it or through repeated CSV re-imports on a fixed schedule agreed by the team. Agents record new work in JSM until the cutover date, and any change to the CMDB is checked in both systems. The output is a reconciliation report showing record counts and differences per object type, which must be clear before cutover is scheduled.
Execute cutover from a written runbook
The team freezes JSM intake, runs the final export and import, repeats the reconciliation, and switches the intake channels, email addresses and portal links to iTop. A rollback point is defined in advance so the team knows what would trigger a return to JSM. The output is a cutover runbook with timestamps, named owners for each action and the signed record of the final reconciliation.
Archive the JSM export and decommission
After a period of read-only operation agreed with the business, the team stores complete JSM exports, including attachments, comments and the Assets and automation documentation, in an archive the organization controls. Access to JSM is removed, and the subscription or Data Center licenses are closed through Atlassian's administration process. The output is an archive index with checksums and a decommission record that the CISO or IT owner signs.
How the migration differs by team size and starting point
A small internal team under the Community limit of 10 agents usually has a compact request history and a modest CMDB, so the migration is mostly a matter of exporting the right files, mapping fields and checking a few hundred records by hand. Because the Community edition is free, the cost driver is mainly the internal and partner time spent on mapping and testing, not licensing.
- Data volume: Export Jira Service Management work items and the Assets CSV, then compare row counts against the source before any import.
- Cutover window: A short freeze of new requests is often enough, but confirm the window with the people who raise and close tickets.
- Testing: Run a few representative request types end to end, including approvals and SLA timers, on a copy of the iTop instance.
- Hosting: Combodo suggests an all-in-one server with 2 vCPU and 4 GB of memory for fewer than 200 tickets a month and under 20 console users, so confirm your own load before sizing.
- Edition check: Confirm the agent count against the Community terms on combodo.com, since growth past 10 agents changes the edition.
Before you commit, ask whether the current agent count and expected growth still fit the Community edition.
A team of 50 or more agents on iTop Forge, or on Atelier for up to 50 agents, moves a larger ticket history, more console users and usually more customized request types. The migration is planned in stages, with separate test cycles for data, workflows and reporting, and the cutover needs agreed rollback steps.
- Data volume: Plan imports in batches and run data consistency audits after each batch, since a single large import is harder to verify.
- Cutover window: Schedule the freeze around change calendars and month-end reporting, and keep Jira read-only for a defined overlap period.
- Testing: Test SLA calculations, escalations and approval chains with agents from each queue, not only with the project team.
- Hosting: Combodo suggests separate web and database servers of up to 8 vCPU and 16 GB for larger installations, so size both tiers against measured load.
- Edition: Compare Atelier and Forge against the agent count, and ask Combodo for written terms for on-premises or SaaS delivery.
Ask for a written test plan that names who signs off each batch and the rollback decision point.
A team whose Assets schema has many object types, deep references between configuration items and linked requests needs more planning than the ticket count suggests. Jira Cloud backups exclude Assets, so the Assets CSV export becomes the main source, and references must be rebuilt in iTop's data model before any dependent records load.
- Data volume: Count configuration items, relationships and attachments by type, because flat CSV files lose the links that connect them.
- Cutover window: Import reference data (locations, owners, contracts) first, then configuration items, then requests, and allow time for each dependency check.
- Testing: Verify impact analysis graphs and relationship counts against the source, since broken references show up there first.
- Schema design: Use iTop's customizable data model to map each Assets object type, and decide early which fields are required.
- Synchronization: Confirm whether data synchronization is needed for other systems that feed the CMDB during the transition.
Before starting, ask for a written mapping of every Assets object type to an iTop class and a reconciliation report for each import.
What drives cost and duration in a Jira Service Management to iTop move
This table breaks the move into cost components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to scope a quote and to see where internal time will go before you commit to a timeline.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it |
|---|---|---|---|
| Discovery and data mapping | Internal ITSM owner and implementation partner | One-time | Number of Assets object types, custom fields, request types and reference links in JSM that must map to iTop classes |
| Assets schema rebuild in iTop | Implementation partner or internal iTop developer | One-time | Complexity of object schemas and references, plus any extensions taken from the iTop Hub |
| CSV import and cleanup | Internal data owners, with partner support | One-time | Data quality in the Assets CSV export, duplicate records, and how many relationships must be rebuilt by hand |
| SLA and request type configuration | Internal service owners and iTop administrator | One-time, then ongoing changes | Number of SLAs, escalation rules and approval paths that must match current JSM behavior |
| Hosting for small installs | Your infrastructure team or cloud account | Recurring | Combodo suggests 2 vCPU and 4 GB memory for fewer than 200 tickets a month and under 20 console users |
| Hosting for larger installs | Your infrastructure team or cloud account | Recurring | Combodo suggests separate web and database servers of up to 8 vCPU and 16 GB each, so split tiers add servers to run |
| Database choice | Your infrastructure team | One-time setup, recurring operations | iTop 3.3.x supports MariaDB 10.6 to 11.8, preferred over MySQL 8, which the iTop requirements page discourages for performance |
| Runtime prerequisites | Your infrastructure team | One-time setup, recurring patching | PHP 8.2 to 8.4 and GraphViz must be installed and kept supported |
| Vendor support or training from Combodo | Combodo, if you buy it | Recurring if subscribed | Confirm whether support, training or consultancy is needed and what the written quote covers |
| Internal testing time | Service desk agents and ITSM owner | One-time, repeated for each release | Number of request types, approval flows and reports to validate before cutover |
What usually goes wrong when Assets moves into iTop
Most failed Assets migrations lose meaning, not data. The rows arrive, but the relationships, automation, service levels and identities behind them do not. Each risk below has a prevention step to complete before the cutover.
CI relationships lost in flat CSV
A flat CSV carries one configuration item per row, so links such as an application depending on a database server are dropped unless you carry them separately. Import the objects first, then rebuild the relationships in iTop, where the CMDB stores them as typed links. Export the relationship list from JSM with stable keys, and check impact analysis on a few known services before cutover.
Duplicate or stale CIs
Assets often holds duplicates from discovery feeds, manual entry and earlier imports, and every duplicate you migrate becomes a record someone must maintain. Decide which source is authoritative for each class before importing. Retire decommissioned hardware using a last-updated date if your export includes one, then run iTop's data consistency audits after each load and clear the findings.
Automation and app behavior assumed to carry over
Jira Cloud's backup excludes automation rules, third-party apps and Assets, so none of them arrive in iTop by default. Teams often assume routing, notifications and approval steps moved with the tickets. List every rule and app in use, record what each one does, and rebuild that behavior as iTop triggers, notifications or workflow stages. Test each path with a sample request before go-live.
SLA calendars and escalations misread
A working calendar in the wrong time zone, a missing holiday or an escalation at the wrong threshold changes breach reports from the first day in iTop. Recreate each SLA with its calendar, priority mapping and escalation timing. Then compare breach times for a sample of historical tickets against the original JSM values, and have service owners sign off every difference before the new SLAs go live.
Attachments and comment history incomplete
Attachments are optional in the Jira Cloud backup, and Atlassian requires 48 hours between backups that include them, so plan that export as its own scheduled job. Comments are included, but their authors and timestamps must map to fields in the iTop import. Confirm on sample tickets that files and comment history are attached correctly before the old instance is retired.
User and team mapping errors
Agents, requesters and groups must map to iTop persons, teams and profiles. A wrong mapping routes tickets to the wrong queue or grants access that people should not have. Map each Jira group to an iTop team and profile before import, merge duplicate people across directories, and count the agents you will keep, since Combodo's Community edition is free for a limited number of agents.
What changes for agents, requesters and administrators after cutover
Agents and requesters should expect different request forms, navigation and reporting after cutover, so the pilot needs to test the actual workflows rather than assume JSM habits carry over. iTop's helpdesk and incident management, change management and service and contract management are configured through its data model, which means the request forms requesters see are only what your team has built or imported. Confirm with Combodo and in your own pilot which ticket fields, required attributes and form layouts you can reproduce, and which need custom work. Ask agents to run their most common incident and change scenarios end to end before go-live, and record every step that differs from Jira.
The CMDB and impact views are where the largest day-to-day change is likely to appear. iTop's README describes graphical impact analysis and a fully customizable CMDB, so an agent will navigate configuration items through relationships rather than through JSM's Assets object schema screens. Ask the pilot group to trace a real outage from a server to its dependent services and to a affected change, and check that the impact graph shows what they expect. Also confirm how data synchronization for federation is configured if you plan to keep another source of truth, since that decision affects who edits configuration items after cutover.
Administrators take on new recurring tasks. Run the data consistency audits that iTop provides on a schedule and treat their output as a standing work queue, since migrated CSV data often exposes broken references and missing mandatory fields. SLA reporting also moves to iTop's customizable SLA management, so confirm how your current response and resolution targets are expressed, how breaches are reported to managers, and who owns SLA definition changes. On the extension side, extensions are distributed through the iTop Hub, so set a review and approval process for installing and upgrading them, and confirm the extension versions against your iTop release before each upgrade.
Questions buyers ask before moving from Jira Service Management to iTop
How much effort does a move from Jira Service Management to iTop involve?
The effort depends mostly on how much structured data you need to carry over and how many request types, approval paths and SLAs you need to rebuild. The main drivers are the number of configuration items in your Assets schema, the number of active tickets and history you want to keep, the number of custom fields and workflows, and whether automation rules and apps must be recreated by hand. Each of these adds work on both the extraction side and the iTop design side. Ask any provider, including your internal team, to break the estimate into schema mapping, data import, request type and SLA rebuild, testing and cutover, so you can see which parts scale with your data.
What drives the cost of moving to iTop?
Costs fall into a few components: the iTop software itself, hosting and database servers, the people who design and test the migration, and any optional vendor support or training. iTop Community is free for up to 10 agents, while Atelier covers up to 50 agents and Forge covers more than 50, each available on premises or as SaaS, according to Combodo. Most one-time costs come from schema design, data mapping and testing. Recurring costs include hosting, patching, backups and support contracts. Ask for a quote that lists each of these separately and states who is paid for each item.
How long does a Jira Service Management to iTop migration take?
No fixed duration applies to every migration, so treat any single number with caution. The timeline depends on schema complexity, data volume, the number of integrations, and how many cutover rehearsals your change process requires. Atlassian's dates set the outer deadline: it ends sales of new Data Center subscriptions to new customers on March 30, 2026, and Data Center licenses expire and become read-only on March 28, 2029. If you run Data Center, plan the move against those dates and agree a written schedule with your provider before work starts.
Can our internal team migrate to iTop without outside help?
Yes, many internal teams can run the migration themselves if they have database and PHP administration skills, someone who understands the ITIL processes they depend on, and time to test. iTop's requirements include PHP 8.2 to 8.4, MariaDB 10.6 to 11.8 (MariaDB is preferred), and GraphViz. Combodo suggests an all-in-one server with 2 vCPU and 4 GB of memory for fewer than 200 tickets a month and under 20 console users. Consider whether your team has capacity to maintain the system after go-live, because patching, backups and upgrades recur. Combodo also sells support, training and consultancy if you want that help.
What does our team need to provide for the migration?
Your team needs to supply a current Assets export, a list of request types, approval rules and SLAs, access to the Jira Cloud or Data Center instance, and named owners who can sign off on data mapping. Jira Cloud's backup manager does not include Assets, automation rules or third-party apps, so Assets must be exported separately and automation logic must be documented by hand. Plan for subject-matter reviews of the configuration items and for test users who can validate tickets in iTop before cutover. Note that a provider can only map what you give them.
Can all of our Assets move completely into iTop?
Most Assets data can move, but not automatically in one step, and completeness depends on how your object schema and relationships map to iTop's classes. Atlassian's Assets CSV export is a separate export from the Cloud backup, so you need to extract it on purpose. iTop supports CSV import and data synchronization, which helps rebuild the CMDB, yet relationships, custom attributes and discovery data may need remapping. Run data consistency audits after import and compare record counts and key relationships against the source. Confirm the exact export format with Atlassian for your Assets version.
What happens to attachments and ticket history during the move?
Attachments and history need separate handling because Jira Cloud's backup manager includes attachments only when you select them, and Atlassian requires 48 hours between backups when attachments are included. Work items, comments, users, groups and project configuration are included in the cloud backup, but the backup is not a direct import format for iTop. Decide which history you need in iTop, such as closed tickets for audit, and which can stay in an archive. Confirm with your compliance owner how long records must be retained, and test that attachments open correctly after import.
How DeployOpen scopes, runs and supports an iTop migration
DeployOpen plans and implements self-hosted open-source platforms inside the client's own infrastructure, including iTop deployments for internal IT service desks. For a move from Jira Service Management, the work starts with a written scope that separates the Assets data, request types, SLAs and change records so each can be checked before cutover.
How we scope
- Inventory the Jira Service Management projects, request types, queues, SLAs and Assets object schemas that the iTop target must replace.
- Confirm the iTop edition and agent count against the Community, Atelier or Forge tiers before sizing the environment.
- Agree in writing which data moves, which is rebuilt by hand and which is retired, with deliverables and timelines set before work starts.
How we build
- Size the iTop server against the Combodo requirements, including PHP 8.2 to 8.4, MariaDB and GraphViz, inside your own cloud account or data center.
- Map Assets exports to iTop CSV import templates and run consistency audits on configuration items before loading production data.
- Rebuild request types, SLA rules and change workflows in a staging instance, then test incident handling and impact analysis with your own agents.
How we hand over
- Document the schema, import procedures, SLA definitions and admin tasks so your team can maintain the instance without DeployOpen.
- Deliver a cutover runbook covering the final data load, DNS and email routing changes, and a rollback path.
- Review the handover with your IT service owners and confirm which Jira records remain archived and where they are stored.
How we support
- Ongoing support, upgrades and backups can be covered by a retainer after go-live, including iTop version upgrades.
- Confirm with DeployOpen whether backups of the iTop database and attachments are part of the written scope or the retainer.
- Ask for a quote built from the written scope, which sets the cost of the migration and any follow-on support separately.
