Which fits an internal IT team that depends on JSM Assets?
If your internal IT team keeps its CMDB in Jira Service Management Assets and you are reviewing hosting options now that Data Center is being phased out, the question is less about ticketing and more about where your configuration data can live and who will run it. Jira Service Management fits teams that stay in Atlassian Cloud and want to keep their Assets, automation and marketplace integrations in one vendor's stack. iTop fits teams that need to run a self-hosted service desk, want a customizable CMDB with graphical impact analysis, and have the operating skill to maintain a PHP application on MySQL or MariaDB. Four drivers should decide the shortlist: agent count against the 10-agent limit of iTop Community, the Atlassian Data Center dates, the complexity of your Assets schema, and the skills you can staff in-house.
Start with agent count and schema. Count the agents who would work in the service desk and the console users who would only read the CMDB, then compare that number with the free tier, which covers up to 10 agents, and with iTop Atelier and Forge for larger teams, both sold per the Combodo pricing structure. Next, export a sample of your Assets object types and relationships and map each one to an iTop class. Object types with many custom attributes, multi-valued references or workflow-driven states need a proof of concept before you commit, because they are where the modeling effort concentrates. Ask Combodo to confirm how your Assets schema translates into iTop classes, relations and lifecycles, since the mapping is specific to your configuration and is not something a feature list can answer.
Then match the timeline to your Data Center date and your skills. Atlassian 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, so an existing customer has a defined window to plan. Confirm with your Atlassian account team which dates apply to your contract. For iTop, check the software requirements for PHP 8.2 to 8.4, MariaDB 10.6 to 11.8 and GraphViz, and confirm that someone on your team can patch the stack, manage backups and handle upgrades. If that skill is missing, budget for an implementation and support partner such as DeployOpen, scoped in writing before work starts, rather than assuming the software alone covers operations.
Which option fits which scenario
This table maps common situations to the option that fits best, whether that is Jira Service Management, iTop or a split approach. Read each row against your own CMDB depth, agent count, Atlassian dependencies and Data Center timeline, then confirm the open items with the vendors and in a proof of concept.
| Situation | Better fit | Why and what to confirm |
|---|---|---|
| Staying on Atlassian Cloud with Confluence and Jira apps in daily use | Jira Service Management | Cloud keeps the app ecosystem and vendor-run upgrades. Confirm which installed apps have an iTop equivalent before any move. |
| Data Center licenses must move off before the read-only date on March 28, 2029 | iTop, if the CMDB is central | Plan the migration early because Atlassian sets March 30, 2026 as the end of new Data Center sales. Run a timed test import of configuration items first. |
| CMDB with many relationships and impact analysis needs | iTop | iTop offers a customizable CMDB with graphical impact analysis and data consistency audits. Test your heaviest relationship chains against its data model. |
| More than 10 agents on a free tier | iTop Atelier or Forge, or JSM | Community is free for up to 10 agents. Above that, Atelier covers up to 50 agents and Forge covers more, each with a quote. Compare paid tiers against your current JSM seats. |
| Teams that want self-hosted control of ITSM with minimal customization | iTop or GLPI | Both run on your own servers. Choose iTop for relationship-heavy CMDB work and GLPI for broad inventory and a larger ITIL module set. |
| Customer-facing support as the main workload | Zammad | iTop is built for internal IT. Zammad covers multichannel customer ticketing better, so review it alongside iTop if both needs exist. |
| Multi-site federation of CMDB data across organizations | iTop | Data synchronization supports federation. Confirm the sync design with Combodo documentation and your network architecture. |
How iTop editions and AGPL-3.0 licensing change the decision
Combodo offers iTop Community free for up to 10 agents. The software is free to download and run, so the cost of Community sits in your own infrastructure, staff time and any extensions or outside help you choose to buy. For a small internal IT team, this tier is the first thing to test against your real ticket volume and CMDB schema.
- Agent ceiling: Community covers up to 10 agents. Count the people who work tickets, not everyone who submits one.
- Hosting: Community runs on your own servers, which means you pay for virtual machines, backups, patching and database administration.
- Growth path: Once the agent count passes 10, you move to a paid tier rather than staying on Community.
- Extensions: Add-ons are distributed through the iTop Hub, so check which ones your schema depends on and whether each one is free or paid.
- Support: Community users rely on the public project resources unless they buy a support contract.
Before you rely on Community, confirm with Combodo how the agent limit is counted and whether any extension you need is available under the same terms.
Combodo positions iTop Atelier for up to 50 agents and iTop Forge for more than 50 agents. Both are available on premises or as SaaS. The agent count is the main driver of the subscription, while the hosting choice decides who operates the platform. Teams in a JSM Assets migration should compare these paid tiers with their current per-agent Atlassian spend, using written quotes rather than estimates.
- Atelier: Covers up to 50 agents, a fit for mid-sized internal service desks.
- Forge: Covers more than 50 agents, so ask Combodo how it prices large or multi-site user bases.
- On premises: You host the software and carry infrastructure and operations costs, while the subscription covers the licensed product.
- SaaS: Combodo runs the instance, which shifts operations cost to the vendor but moves data hosting outside your own servers.
- Recurring versus one-time: Subscriptions recur each year, while migration, schema design and integration are usually one-time project work.
Ask for the agent definition, the tier price for your exact count, and whether the on-premises and SaaS prices differ.
iTop is licensed under AGPL-3.0, a copyleft licence. You can use, study and run iTop without paying a licence fee for the software itself. The obligations change if you modify the code, and the AGPL extends to network use, which matters for a service desk reached through a web browser. Legal review should confirm how the licence applies to your specific deployment and any custom code.
- Use without modification: Running an unmodified copy internally carries no source-sharing duty under the licence.
- Modified code: If you change iTop's code and make the modified version available to users over a network, the AGPL can require you to offer that modified source to those users.
- Custom modules: Ask counsel whether your customisations are modifications of iTop or separate programs that interact with it.
- Extensions: Confirm the licence on each extension from the iTop Hub, since they may carry their own terms.
- Documentation: Keep a record of every change you make, so you can answer licence questions during an audit.
Ask counsel to review your planned customisations against the AGPL-3.0 text before your build phase begins.
Combodo sells commercial support, training and consultancy for iTop. Support is optional, so a team can run iTop without it, but many regulated organisations want a contracted party to answer security fixes and upgrade questions. Support and consultancy are priced separately from the software, which makes them a recurring line item to plan for in your budget.
- Support contract: A subscription that sets response expectations, which you should confirm in writing before signing.
- Training: One-time or repeated courses for administrators and agents, depending on how many staff change roles.
- Consultancy: Project work for schema design, integration and upgrades, billed by scope.
- Hub extensions: Third-party extensions are distributed through the iTop Hub and may need their own review, licence check and maintenance.
- Independent options: An implementation partner such as DeployOpen can plan, harden and support iTop on your infrastructure, separate from Combodo's own services.
Request a written support scope from Combodo that names response times, covered versions and what happens to extensions during an upgrade.
Atlassian's Jira Service Management licensing is tied to Cloud subscriptions or Data Center licences. Atlassian ends sales of new Data Center subscriptions to new customers on March 30, 2026, and Data Center licences expire and become read-only on March 28, 2029. iTop changes the decision because its cost follows agent count and hosting model, not a Cloud or Data Center product line, and its licence is open source.
- Cost driver: JSM Cloud and Data Center costs also depend on users or agents, so compare the same headcount on both sides.
- Hosting choice: iTop lets you pick on premises or SaaS at each tier, while Data Center means running your own servers under Atlassian's licence.
- Deadline: Atlassian's March 28, 2029 read-only date sets a planning horizon for leaving Data Center.
- Lock-in: AGPL-3.0 code can be run by a different operator, which reduces dependence on one vendor's pricing.
- Assets: Map your JSM Assets schema to iTop's CMDB before comparing total costs, because the data model affects migration effort.
Build a side-by-side estimate using your current agent count, the dates above and written quotes for each iTop tier.
Where iTop data lives and what Atlassian's Data Center dates mean
iTop keeps every CMDB record, ticket and SLA definition inside the infrastructure you control. It is built with PHP on MySQL or MariaDB, so the application server and database sit in your cloud account, data center or air-gapped network, and the data stays there unless your own processes move it. Jira Service Management Cloud works differently: Atlassian hosts the product data, and residency depends on the terms and regions Atlassian offers for your plan. Confirm with Atlassian which data residency commitments apply to your tenant, which account data falls outside them, and how Atlassian handles the processing of personal data, including subprocessors, in the data processing agreement you hold.
The Data Center dates set the planning horizon. Atlassian ends sales of new Data Center subscriptions to new customers on March 30, 2026. Existing customers can buy licenses or expansions until March 30, 2028. On March 28, 2029, Data Center licenses expire and become read-only. An iTop project on a timeline your organization can actually execute should start with the Assets export, the CMDB schema design and a parallel run, well before the last purchase date. Ask your Atlassian account team which contract term and renewal options are still available to you, and whether a Data Center license bought before March 30, 2028 would fund a transition period on your side.
Involve your legal and procurement teams before the decision is made, not after. Ask them to confirm three things: whether the current Atlassian agreement and data processing terms still govern the data you would export, whether your regulators or internal policy require that configuration item data stay in named locations, and who in your organization owns the records once they leave Atlassian. The answers determine how much of the migration runs on your own servers and whether any hosting provider you choose needs its own data processing agreement. This page does not give legal advice, so treat these points as questions for counsel.
Hosting, identity and compliance implications
Moving from Jira Service Management to iTop changes where ticket, CMDB and user data sits and who keeps it running. The cards below cover the decisions that connect hosting, sign-in, audit and backup to the GDPR and NIS2 duties your organization already carries. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue any audit report or certification.
Data location and hosting model
iTop can run on your own servers, in your cloud account or in a data center you choose, or Combodo can host it as SaaS. Each choice decides which legal entity and jurisdiction hold CMDB records, ticket bodies and attachments. Ask Combodo, in writing, where its SaaS data is stored, which subprocessors it uses and where support staff access it from. Atlassian's Data Center end of sale and the read-only date in 2029 make this a timeline decision as well as a residency one.
Single sign-on options to confirm
Jira Service Management users often sign in through Atlassian Access or a corporate identity provider. Before you commit, confirm with Combodo and the iTop Hub which SAML or OpenID Connect integrations are available on your edition and whether they need a paid extension. Test how agent roles, customer profiles and group membership map from your directory into iTop profiles, because a mismatch there becomes an access control gap in the CMDB.
Audit trail and access logging
Auditors will ask who changed a configuration item, a change record or an SLA, and when. Confirm that iTop's change history covers every object type you need, that it cannot be edited by ordinary agents, and that logs can be forwarded to your SIEM. Compare this against the audit records you export from Jira today, since Jira Cloud backups do not capture everything. DeployOpen can document these controls and collect evidence, but the assessment outcome belongs to your independent auditor.
Backup and restore responsibility
On Jira Cloud, Atlassian runs backups through its backup manager, but that backup excludes Assets and automation rules. With iTop on your infrastructure, the backup of the MySQL or MariaDB database, the attachment store and the configuration files becomes your responsibility. Define a recovery point, test a restore of the CMDB and ticket history into a separate environment, and record the result. Confirm whether the supported database versions and the GraphViz dependency are covered by your backup tooling.
GDPR duties for personal data in tickets
Ticket histories and CMDB owner fields contain personal data about employees and contractors. As the controller, you must set retention periods, respond to access and erasure requests and document the processing. When you move data out of Jira, check that exports include user identifiers you can match to your records, and that deleted users and their references are handled consistently in iTop. Record the decisions in your processing register and agree on processor terms with any hosting or support provider.
NIS2 and operational resilience duties
If your organization falls under NIS2, the service desk and CMDB become part of the risk management and incident handling measures that management must approve and oversee. Document how iTop is patched, which versions you run and how change approvals are enforced, since iTop's change management module can support that evidence. Confirm your national reporting timelines and who in your organization triggers them, because the tool will only record what your process asks it to record.
What each option costs to run over time
This table breaks down what Jira Service Management and self-hosted iTop each cost across licensing, infrastructure, migration, support and staff time. Read each row for who is paid, whether the cost is one-time or recurring, and what moves it up or down. No prices appear here, so request written quotes from Atlassian, Combodo and any partner before comparing totals.
| Cost component | Who is paid, and for what | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Jira Service Management licensing | Atlassian, for agent and user seats on Cloud, or Data Center licenses on your own servers | Recurring (subscription or maintenance) | Agent count, edition, and whether you buy before Atlassian's March 30, 2028 cutoff for existing Data Center customers |
| iTop edition | Combodo, for Community (free up to 10 agents), Atelier (up to 50 agents) or Forge (more than 50 agents) | Free tier is zero; paid tiers are recurring | Number of agents and whether you choose on-premises or SaaS; confirm current terms in the quote |
| Server hosting | Your cloud account, data center provider or hardware budget | Recurring for cloud or hosting; one-time for hardware | Combodo suggests 2 vCPU and 4 GB for fewer than 200 tickets a month and under 20 console users; up to 8 vCPU and 16 GB for larger installs |
| Database and backups | Your team or your database provider, for MySQL or MariaDB licensing (if any), storage and backup tooling | Recurring | Choice of MariaDB (preferred by Combodo) or MySQL, plus backup frequency and retention you set |
| PHP, GraphViz and upgrades | Your administrators, for PHP 8.2 to 8.4 runtime, GraphViz and iTop version upgrades | Recurring effort | Version drift, extension count and how often you apply iTop releases; iTop 3.3.0 is the current major line |
| Migration services | A partner such as DeployOpen or your internal team, for moving Assets, tickets and SLAs out of Jira | One-time | Size of the Assets schema, volume of requests, and how much CSV reconciliation and data synchronization you need |
| Optional Combodo support and training | Combodo, for commercial support, training and consultancy | Recurring for support; one-time for training | Whether in-house staff have iTop experience and how complex your custom extensions are |
| Internal administrator time | Your own staff, for configuration, CMDB data quality, SLA tuning and user support | Recurring | Level of customization, number of integrations, and how well the CMDB is maintained after go-live |
What running iTop in-house requires
Running iTop in-house means your team owns the full stack. The application needs PHP 8.2 to 8.4 on the web tier, and the current iTop 3.3.x line requires that range, so confirm the PHP version on your hosts before you schedule the install. On the database side, iTop supports MySQL 5.7 or later and MariaDB 10.6 to 11.8. The iTop requirements page prefers MariaDB and discourages MySQL 8 for performance reasons, so the choice should be made at build time, not after data is loaded. The application also needs GraphViz for the graphical impact analysis, which is one of the features teams moving off Assets care about most. Add GraphViz to your server build and test an impact diagram before go-live.
Upgrades, backups and data quality are recurring work. Plan a repeatable path from the 3.2.x line to 3.3.x, rehearsed on a copy of production, with the database and the iTop configuration backed up first. Your backup job must cover both the database and the files that hold extensions and customizations, because a database dump alone does not restore a working instance. After each CSV import, check record counts, required fields and relationships against the source export, and schedule the data consistency audits that iTop provides so that broken links in the CMDB are found in a review, not during an incident. Patching of the operating system, PHP, the database and iTop itself, along with monitoring of availability and the scheduled jobs that drive SLA timers, stays with your team unless you contract it out.
Combodo sells commercial support, training and consultancy for iTop, and an implementation partner can take on parts of this work under a written scope. Ask Combodo or the partner which of the following they will carry: upgrade planning, patch rounds, monitoring setup, backup verification and audit reviews, and whether those are one-time tasks or a recurring agreement. Ask for the supported PHP and database versions in writing for the release you plan to run. Then decide who answers when a scheduled job stops or an upgrade fails at 2 a.m., since that answer determines whether the in-house effort is a few planned tasks or a standing on-call duty.
How a move from Jira Service Management to iTop unfolds
The sequence turns Jira Service Management's ticket history, Assets schema and service rules into an iTop instance that agents can run in parallel before the old service desk is switched off.
Inventory the Assets schema and request types
Your team lists every Assets object type, its attributes and relationships, along with the request types, queues, workflows and SLA goals agents use today. An iTop-side owner who knows the CMDB and an agent lead who knows daily work both take part. The output is a written map of what must exist in iTop and which fields are required, optional or no longer used. The step is done when the business owners have signed off the map.
Extract configuration items with the Assets CSV export
Using the separate Assets CSV export from Jira Service Management, your administrator pulls configuration items and their relationships into flat files, one set per object type. Because the Jira Cloud backup for cloud excludes Assets, this export is the only native route for that data, and it has to be run deliberately. The output is a set of CSV files checked against the inventory, with record counts compared to the source. Reconcile any gaps before moving on.
Extract automation rules and apps separately
Automation rules, third-party app configuration and other settings that a Jira Cloud backup leaves out need their own extraction. Your team documents each rule by trigger, condition and action, then decides whether it becomes an iTop workflow, a notification, a scheduled job or is retired. The output is a rule register with a target for every item. Confirm with the Atlassian documentation and your own admin console which settings each export actually covers, since the scope can change.
Rebuild the CMDB schema in iTop
iTop's customizable data model is set up to match the inventory: classes, attributes, relationships and lifecycle states for configuration items, along with contacts, teams and organizations. Your iTop specialist maps each Assets object type to a class and documents any type with no clean equivalent. The output is a tested schema on a non-production iTop instance, checked against sample records. Installation prerequisites, such as the supported PHP, database and GraphViz versions, should be confirmed against the iTop requirements before this work begins.
Import data and run synchronization checks
CSV import loads the configuration items, contacts and historical tickets into the rebuilt schema, and data consistency audits flag broken references, duplicates and missing mandatory fields. Where the CMDB has to stay aligned with another source, data synchronization is configured and tested. The output is an import log, an audit report with each issue assigned, and a reconciled record count for every class. Re-run imports until the audits are clean for the agreed scope.
Rebuild SLAs, change workflows and notifications
Your team recreates SLA definitions, escalation rules, incident and change workflows, approval steps and notification templates in iTop, using the register from the earlier step. Each rebuilt rule is tested with sample tickets that cover normal, breached and escalated cases. The output is a test record showing expected and actual outcomes for each rule. Rules that cannot be matched are documented as accepted changes for the service owner to approve.
Run iTop in parallel with the existing service desk
For a defined period, agents log new requests in both systems or in iTop only for a pilot group, and managers compare queue times, SLA results and CMDB lookups between them. Gaps found during this period are logged, prioritized and fixed in iTop before cutover. The output is a parallel-run report that the service owner accepts. The length of this period is set by your own risk assessment rather than by any fixed rule.
Cut over and retain Jira records for reference
On an agreed date, new requests move to iTop, the Jira Service Management queues are closed to new work, and a final export is taken and stored under your retention policy. Your team confirms user access, integrations, email routing and the knowledge base link. The output is a signed cutover checklist and an archive of the final exports. Keep the archive accessible long enough to answer audit and reporting questions, and confirm your retention obligations before the old instance is decommissioned.
Questions buyers ask before switching to iTop
What drives the cost and effort of moving from Jira Service Management to iTop?
The cost is driven by the work around the software more than by the licence. iTop Community is free for up to 10 agents, and iTop is AGPL-3.0 licensed, so the recurring items are infrastructure, your own staff time, and any paid support or extensions you choose. The main one-time items are the migration of request types, SLAs and the Assets schema, plus data extraction and testing. Costs rise with the number of configuration items, the number of custom workflows and integrations, and the number of agents you need to license. Ask any partner for a quote built from a written scope that lists each of these components separately, and ask which parts are one-time and which recur.
How long does a migration from JSM to iTop take?
No timeline is given here without a written scope, because duration depends on the size and shape of your data and on how much of your process you want to rebuild. The factors that set it are the number of configuration items in Assets, how many request types, approval flows and SLA rules must be recreated in iTop's customizable model, how many integrations need rework, and how much data cleanup your CMDB needs before import. Teams with a clean asset inventory and a short list of workflows usually finish sooner than teams with years of unmanaged custom fields. Ask for a phased plan with a pilot queue and a cutover date agreed in writing.
Can an internal team migrate to iTop without outside help?
Yes, an internal team can do it if it has the skills and the time, but the work is larger than a simple data export. Your team needs someone who can administer a PHP application on MySQL or MariaDB, plus people who understand your current ITIL processes well enough to redesign them in iTop. Combodo sells commercial support, training and consultancy for iTop, so you can buy only the parts you lack. Decide which tasks your staff will own, such as the CSV import of configuration items, and which you will hand to an outside implementer, such as data synchronization design and hardening.
What does the migration require from the business and from IT?
The business must confirm which processes, approvals and reports it actually uses, because a migration that copies JSM's configuration without that review carries old problems into the new system. IT must provide the export files, access to the JSM and Assets data, a test server, database administration, and time for testing and cutover. Name a process owner for incidents, changes and requests, and an Assets owner who signs off on the object schema. Without these named people, decisions about fields and SLA targets stall and the project loses weeks.
Can iTop fully replace JSM Assets?
iTop covers the CMDB role well, but full replacement depends on your schema and integrations. iTop's README describes a fully customizable CMDB, graphical impact analysis, CSV import, data consistency audits and data synchronization for federation. What you must verify is how your Assets object types, references and attributes map to iTop classes, and whether any JSM Assets automation or Atlassian app data is needed. Jira Cloud backups exclude Assets, so you should plan a separate Assets CSV export and test the import on a copy before you commit. Ask the implementer to show a mapping of every object type in your current schema.
When does the 10-agent Community limit become a problem?
The limit becomes a problem when your number of licensed agents goes above 10. iTop Community is free for up to 10 agents, iTop Atelier covers up to 50 agents and iTop Forge covers more than 50, each available on premises or as SaaS, per Combodo. Check how many people will hold agent roles, not how many use the portal, because the boundary is set by agents. If you are close to the limit or expect growth, price Atelier or Forge into the total cost of ownership before you choose, and confirm the current terms directly with Combodo.
How do the Atlassian Data Center dates affect the timing of a move?
Atlassian ends sales of new Data Center subscriptions to new customers on March 30, 2026, sets March 30, 2028 as the last date for existing customers to buy licenses or expansions, and on March 28, 2029 Data Center licenses expire and become read-only, per Atlassian's Ascend announcement. If you are on Data Center, the 2028 purchase deadline matters most if you plan to expand before leaving. A migration project usually runs in parallel with your current licence, so starting the scope early gives you room to test and avoid a rushed cutover. Confirm your own contract dates with Atlassian, since your renewal terms may differ from the general milestones.
How DeployOpen helps evaluate and move to iTop
DeployOpen plans, implements, customizes, integrates, hardens, backs up and documents self-hosted iTop inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. For a team that relies on JSM Assets, the first piece of work is usually an assessment of the CMDB: which object classes, relations and attributes are in use, how request types map to iTop's incident, change and service management modules, and which SLAs must survive the move. The assessment also tests the infrastructure choice against the sizing Combodo suggests, and it sets out the database and web tier design, including the MariaDB versus MySQL decision and the GraphViz dependency that must be installed on the server.
Engagements are fixed-scope. Before work starts, scope, deliverables, acceptance criteria and timelines are agreed in writing, so you can see what is included in the implementation, the CSV import and data synchronization work, the hardening, the backup routine and the operator documentation. Scope and quotes follow from that written assessment, not from a published price list, and DeployOpen does not publish a price list. Ask for the assessment deliverable itself as a line item, so that a go or no-go decision on iTop rests on evidence from your own data. Ongoing support, upgrades and continuous security testing are available as retainers, which matters because iTop 3.3.x and 3.2.x releases will need to be applied on your schedule.
DeployOpen is not a Combodo partner, reseller or certified provider unless that status is stated in writing, and it does not issue audit reports or certifications. Where your evaluation involves compliance evidence for iTop controls, DeployOpen prepares the systems, configuration and records, and your independent auditor reaches the conclusions. Before you commit, confirm with Combodo which edition, support level and extension set you need, since commercial support, training and consultancy are sold by Combodo directly.
