Which open-source alternative replaces Freshservice for internal IT
For internal IT, the open-source option that most directly replaces Freshservice is GLPI, which covers ITIL incident, problem, change and service level management, asset inventory, configuration management, knowledge base and contract management under GPL-3.0. Where the need is simpler ticketing for a smaller help desk, Zammad is the lighter choice, licensed under AGPLv3. Most teams that leave Freshservice for internal IT end up needing GLPI for the service desk, assets and CMDB, and Zammad only if they also want a separate, simpler queue for end-user requests. Teams usually start looking for alternatives at a renewal, after a pricing or packaging change, when data must stay in a specific jurisdiction, or when the service desk history and asset records are becoming hard to move. Each of these is a reason to examine exit terms before the renewal date, not a verdict on the product. Confirm with your Freshservice account team what its current terms say about data retention after cancellation and in what format data can be returned, and compare that against the self-hosted scope you would own. Your own renewal quote is the only reliable source for what you pay today.
The export question comes first. Freshservice account administrators can export the full service desk from Admin, Account, Export, and the data arrives as XML at the registered agent email address. That XML export is the starting point for any migration, so confirm with your administrator that the export is available on your plan, which agent address will receive it, and how large the file will be before you plan the import. Decide early whether asset records and CMDB relationships will come across in that export or need to be rebuilt in GLPI, because that determines how much of the migration is data mapping and how much is manual inventory work. When you test a GLPI and Zammad setup, run a pilot with a copy of recent tickets, two or three real asset classes and one approval workflow. Check how incident, change and problem records keep their links, and how the service level targets you rely on are rebuilt. Ask your implementation partner for a written scope that lists the modules in use, the import method, the parts of the history that will be kept as archived records, and the testing sign-off criteria before any production cutover.
GLPI, Zammad and what each one is for
Freshservice covers service desk ticketing, asset tracking and IT workflows in one product, so replacing it usually means splitting those jobs across tools. GLPI takes the ITIL, asset and CMDB side, while Zammad handles the ticketing queue where simpler service desk work happens.
GLPI as the ITIL and asset core
GLPI is free IT management software released under GPL-3.0. It covers ITIL incident, problem, change and service level management, along with asset inventory, configuration management, a knowledge base and contract management. For a Freshservice replacement, it is the component that holds your asset and configuration data. Check how your current asset types, relationships and approval flows map onto GLPI's item types before you commit.
Teclib' as GLPI's maintainer
GLPI is edited and maintained by Teclib', which also runs GLPI Network, a hosted cloud offering with a free 45-day trial. Self-hosting means your team or a partner owns upgrades, plugin compatibility and database backups. Ask Teclib' or your implementation partner which support options exist for your deployment model, and who is responsible for each upgrade path.
Current GLPI release line
GLPI 12.0.0 was published on October 7, 2026. Before migrating, confirm which release your target environment will run, whether the plugins you need support it, and how your organization will test the upgrade path. A version pinned during planning should be rechecked at cutover, because release notes and compatibility details can change between planning and go-live.
Zammad for agent ticketing
Zammad is ticketing software licensed under AGPLv3, and its source code is owned by the Zammad Foundation, independent of Zammad GmbH. It fits teams who mainly need a shared queue, email handling and customer-style ticket workflows. Because the AGPLv3 license applies to network use, confirm with your legal team how it applies if you modify Zammad and make it available to users.
Freshdesk migrator in Zammad
Zammad includes a built-in migrator for Freshdesk, which matters if your Freshservice estate also holds support tickets from a Freshdesk account. The migrator works only on a new instance, runs all or nothing, and accepts one source per migration. Plan for a separate import step for each source system and test with a copy of the export before cutover.
The trade-off: Zammad is not a full ITSM suite
Zammad is a ticketing tool, not a full ITSM asset and CMDB suite. It will not replace GLPI's inventory, configuration management or contract tracking, so pairing it with GLPI is a design decision you should make early. Ask which Freshservice asset and change workflows will need GLPI and which can stay in a ticket queue.
Freshservice capabilities mapped to GLPI and Zammad
This table maps the main Freshservice capabilities to GLPI, which covers most ITIL and asset needs for internal IT, and to Zammad, which handles ticketing and customer-style request flows. Coverage is marked full, partial or to confirm, so you can see where a GLPI plugin, configuration or custom work will be needed. Use the table as a starting checklist, then test each row against your own workflows before deciding.
| Freshservice capability | GLPI | Zammad |
|---|---|---|
| Incident and request management | Full: ITIL incident and request tickets with categories, assignment and SLA tracking | Partial: strong agent ticketing and email intake, less suited to ITIL-style request catalogs |
| Problem and change management | Full: ITIL problem and change modules are included in the core product | To confirm: Zammad has no dedicated ITIL change workflow, so plan a separate process or tool |
| Service level management | Full: SLA definitions and escalation rules are part of ITIL support features | Partial: SLA and escalation rules exist, but confirm they match your targets |
| Asset inventory | Full: hardware, software and license inventory is a core GLPI function | null: not a Zammad function, so keep assets in GLPI or another inventory tool |
| CMDB and configuration relationships | Partial: GLPI covers configuration items and relations, confirm the depth you need against your data model | null: no configuration management database in Zammad |
| Knowledge base | Full: built-in knowledge base linked to tickets | Full: knowledge base with public and internal articles |
| Approvals | To confirm: approval steps depend on ticket validation and configuration, test them against your process | To confirm: approval flows are not a standard built-in, check the current release |
| Workflow automation and integrations | To confirm: rules engine covers many cases, but Freshservice-specific automations and integrations need checking against GLPI plugins and your environment | To confirm: triggers and webhooks cover common cases, but Freshservice-specific integrations need testing in your environment |
| Self-service portal and reporting | Partial: self-service portal and standard reports, confirm dashboards meet your reporting needs | Partial: customer portal and reporting, confirm report coverage for your KPIs |
What Freshservice's full XML export carries into the new platform
Start by treating the export as a source to be parsed, not a backup to be restored. An account administrator runs it from Admin, Account, Export, and Freshservice delivers the full service desk as XML to the registered agent's email address. That single file is the only complete copy you will get in one piece, so store the original untouched, record its checksum, and confirm the arrival date with whoever receives the email before any parsing begins. Plan the work as a schema inventory: list every top-level element and repeating record the file contains, then decide which of them map to GLPI objects such as tickets, followups, tasks, solutions, computers, monitors, software, network equipment, contracts, users, groups and locations. Elements with no GLPI equivalent need a documented decision, either a custom field, a linked document or an archive kept outside GLPI.
Field-by-field mapping is where most of the effort sits. Ticket status, priority, urgency and impact values in Freshservice rarely match GLPI's ITIL values one for one, so build a translation table and have a service desk lead sign it off. Requester, agent and group references must resolve to GLPI users, groups and entities, which means deciding in advance how departed staff and shared mailboxes are handled. Timestamps, time zones and SLA fields need test records checked by hand, and custom fields need a target in GLPI or a written reason for dropping them. Ask a Freshservice administrator to confirm, in writing, how the export represents attachments (embedded, linked or omitted), whether ticket conversation history and activity logs are complete, and how asset-to-ticket and asset-to-user relationships are expressed. Those three points decide whether your CMDB relationships survive the move or need rebuilding, so test them on a sample before you commit to a full import.
Which option fits your Freshservice use
If your Freshservice use centers on change approval, problem records, service levels and a maintained inventory of hardware, software and contracts, GLPI is the closer fit. GLPI is free software under GPL-3.0 and covers ITIL incident, problem, change and service level management, asset inventory, configuration management, knowledge base and contract management. Its asset and configuration model is where it has the most to offer compared with a ticket-first tool.
- Change control: Confirm that the change approval flow, CAB steps and risk fields match your process before you assume a direct mapping.
- Asset inventory: Check how discovery and reconciliation with your endpoints will be done, since GLPI's inventory depends on how you collect data.
- Configuration relationships: Map which configuration items link to which services so the CMDB reflects your environment.
- Contract tracking: Verify that renewal dates and license records can be imported from your current export.
- Customer-facing queues: Expect more configuration work if you mainly need fast, conversational ticket handling.
Before committing, ask a vendor or your own admin to walk through one real change request and one asset lifecycle in a test instance.
If most of your Freshservice volume is queue-based request handling with light workflows, such as password resets, access requests and general help requests, Zammad is usually the simpler fit. Zammad is licensed under GNU AGPLv3 and is developed with the community under the Zammad Foundation. Its agent interface is oriented around tickets, channels and fast triage, which keeps day-to-day operation lighter than a full ITSM configuration.
- Agent workflow: Zammad keeps the ticket view central, which suits agents who work from a queue rather than from change or problem records.
- Channels: Check which inbound channels you need, such as email, and confirm how each is configured in your instance.
- Migration path: Zammad's built-in migrator supports Freshdesk, Kayako, OTRS and Zendesk, but not Freshservice, so you will import from a Freshservice XML export through a custom process.
- Operational footprint: Fewer modules usually means less administration, but confirm the reporting you need.
- Escalation: If your process grows into change control, plan for GLPI alongside Zammad.
Ask for a sample migration of a few representative tickets before you commit to a full cutover.
When the driver is where data must be stored or who may administer it, both options can run in your own cloud account, data center or air-gapped network, because both are self-hosted. The residency question then shifts to where your hosting partner and any hosted vendor services operate. Zammad GmbH offers hosted plans in German data centers, but that is a separate choice from running Zammad yourself, and GLPI Network is a hosted offering from Teclib'.
- Self-hosted control: Running either platform inside your own infrastructure keeps the data under your administrative control.
- Hosted vendor options: Zammad's hosted plans run in German data centers, and GLPI Network is hosted by the GLPI publisher. Confirm the location for each if you consider them.
- Air-gapped networks: Both platforms can be deployed without internet access, but confirm update and package delivery methods with your team.
- Backups and exports: Decide where Freshservice exports and backups are stored during and after migration.
- Access control: Document which administrators can read tickets and assets, since both tools store personal data.
Request written confirmation of data locations from any hosted vendor you consider.
Cost-driven moves depend on how you compare total cost, not license fees alone. Both GLPI and Zammad are free to download and run, so the recurring costs come from infrastructure, administration, support contracts and the work of migration and configuration. Zammad GmbH sells support contracts for self-hosted installations named Business, Enterprise and Corporation, and those are optional.
- One-time costs: Migration planning, data mapping, testing and configuration are typically the largest up-front items, and they depend on the volume and complexity of your data.
- Recurring costs: Hosting, storage, administration time, patching and any support contract recur each year.
- Support contracts: Zammad's Business, Enterprise and Corporation tiers are optional for self-hosted installations, so compare them against in-house support capacity.
- Cost drivers: Customizations, the number of integrations and the amount of history you migrate usually move the total the most.
- Quote request: Ask any implementation partner for a written scope listing deliverables, assumptions and the exclusions for your data.
Compare the full scope in writing, not only the platform licenses.
What running GLPI or Zammad costs compared with a subscription
This table sets the Freshservice subscription against the cost components of running GLPI or Zammad yourself, marking which items are one-time and which recur. Read the recurring rows first, since they set the long-term difference, then the one-time rows, which usually decide the first year. No Freshservice or DeployOpen prices are shown, so request written quotes for each line.
| Cost component | Who is paid | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Freshservice subscription | Freshservice (Freshworks) | Recurring | Agent count, plan tier and add-ons; confirm current terms directly with the vendor |
| GLPI or Zammad software | No license fee (GPL-3.0 and AGPLv3) | None for the software itself | Choice of edition and modules; confirm any paid add-ons you need |
| Infrastructure (servers, storage, backups) | Your cloud provider or data center | Recurring | Ticket and asset volume, attachment storage, high availability and backup retention |
| Implementation and scope | Implementation partner or internal team | One-time | Number of ITIL processes, integrations and approval flows; agree the scope in writing before work starts |
| Data mapping and export | Implementation partner or internal team | One-time | Freshservice XML export format, custom fields, assets and relationships that need reshaping |
| Migration and parallel run | Implementation partner or internal team | One-time | Number of records, cutover window and how long both systems run side by side |
| Support contracts | Zammad GmbH (Business, Enterprise, Corporation) or Teclib' (GLPI Network or support) | Recurring, optional | Support tier and response expectations; request each vendor's current terms and what they cover |
| Internal skills and operations | Your staff or a retained partner | Recurring | Team familiarity with Linux, databases, upgrades and patching; retainers can cover this in part |
What you give up when leaving Freshservice and the usual workarounds
Leaving Freshservice trades a vendor-run service for software you operate. The gaps below cluster around hosting, integrations, automation and data migration, and each one has a workaround that the migration plan should budget for and test before cutover.
Vendor-hosted operations
Freshservice runs the application, upgrades and backups for you. Self-hosting GLPI moves patching, database maintenance, TLS certificates, backups and monitoring to your team or to a partner under a written scope. Workaround: define the operating model before selecting hosting, including who applies GLPI releases such as 12.0.0, how restores are tested, and who is on call. Ask any partner to put these duties in the statement of work.
Native vendor integrations
Freshservice ships connectors for many SaaS tools that IT teams use for identity, monitoring and procurement. Those connectors do not carry over automatically. Inventory every integration that writes to or reads from the help desk, then decide for each whether GLPI offers a plugin, whether an API call is enough, or whether the flow should be retired. Confirm each plugin's maintenance status before relying on it.
Out-of-the-box automation
Freshservice's routing rules, approval flows and SLA timers are configured in the product and often grow unnoticed over years. GLPI covers ITIL incident, problem, change and service level management, but the rules must be rebuilt as GLPI business rules and workflows. Workaround: export the current rule set, classify each rule as keep, simplify or drop, and rebuild in stages, starting with the highest-volume queues.
Full-fidelity migration from the XML export
Zammad's built-in migrator covers Freshdesk, Kayako, OTRS and Zendesk, but not Freshservice. The Freshservice XML export must be parsed and mapped to GLPI's data model by custom scripts, covering requesters, agents, groups, tickets, assets and attachments. Workaround: write a mapping specification, run test imports into a non-production GLPI instance, and reconcile record counts and sample tickets before any cutover.
Asset and CMDB history
Freshservice asset records often carry relationships, custom fields and audit history that a flat export may not preserve. GLPI's inventory and configuration management can hold this data, but relationships must be mapped explicitly. Workaround: decide which asset attributes are required for active operations, load those first, and keep an archived copy of the original export for audit reference.
Staff training and change management
Requesters, agents and approvers all change their daily screens and habits. Parallel running, short cheat sheets and a defined cutover window reduce the risk of tickets being lost between systems. Workaround: run both systems for a defined period, route new tickets to one system only, and agree in advance on how open tickets are closed or moved.
How to move from Freshservice to GLPI in phases
This sequence moves internal IT from Freshservice to GLPI without a single risky cutover. It starts with an inventory of what the service desk actually does, then builds a verified GLPI model, proves it with one team, runs both systems side by side, and closes with a documented decommission and retention plan.
Inventory workflows, assets and integrations
The IT operations lead, with a Freshservice administrator and a representative from each requesting group, lists every ticket type, approval path, SLA rule, automation, asset class, and connected tool such as monitoring, identity or procurement. Record which items are actively used and which exist only as legacy configuration. Done means a signed-off inventory that maps each workflow to an owner and a target GLPI feature, with gaps flagged for a decision.
Run the full XML export
A Freshservice account administrator runs the full service desk export from Admin, Account, Export. The data arrives as XML at the registered agent email address, so confirm that mailbox is controlled by the team and not by a departing employee. Store the original file read-only with a checksum and a recorded export date. Done means the archive is verified, opened, and confirmed to contain tickets, assets, and related records before any mapping work begins.
Map records to GLPI itemtypes and tickets
The platform engineer builds a field-by-field mapping from the XML structure to GLPI ticket, problem, change, asset and CMDB itemtypes, including requesters, groups, categories, statuses and custom fields. Decide how historical tickets are stored, whether as closed tickets or as archived knowledge, and how relationships between assets and tickets are kept. Test the mapping on a sample extract in a non-production GLPI instance. Done means a written mapping document that the service desk lead has approved, with each unmapped field given a disposition.
Pilot with one support team
Move one team, such as a single site or a single service queue, onto GLPI for new requests. Train the team on the GLPI workflow, configure its SLA and approval rules, and confirm that notifications reach requesters. Collect defects and missing steps in a shared log for two review cycles. Done means the pilot team has closed real requests in GLPI, the open defect list is triaged, and the team lead accepts the workflow for wider rollout.
Operate a parallel run
Keep Freshservice open for all other teams while the pilot runs, and define which system is authoritative for each queue. Reconcile ticket counts, asset records, and SLA reporting between the two systems at regular checkpoints. Verify that integrations such as monitoring alerts and identity provisioning send data to the correct platform. Done means the reconciliation reports match within agreed tolerances and no integration is still writing to Freshservice by mistake.
Execute the cutover
Schedule a cutover window agreed with the business owners, load the remaining active records from the verified mapping, and switch the requester portal, email routing and integrations to GLPI. Freeze new Freshservice ticket creation at the start of the window and confirm the final delta load. Done means every queue has a named owner in GLPI, the final reconciliation is signed off, and the rollback procedure has been tested and documented.
Decommission Freshservice with data retention
Once the cutover is stable, set Freshservice to read-only, cancel the subscription only after the contract terms are confirmed, and keep the verified XML archive under the retention rules set by your compliance and legal teams. Confirm with your security team how the archive is encrypted, who can access it, and when it is deleted. Done means the retention schedule is approved, access to the archive is restricted, and the decommission is recorded in the change log.
How much effort, time and internal skill does a Freshservice move need?
Can our IT team move off Freshservice without an outside partner?
Yes, a team with Linux server administration, database and web application experience, and an owner for ITIL process design can run the move in-house, but the work is larger than a data import. The export itself is simple: a Freshservice account administrator runs the full service desk export from Admin, Account, Export, and the XML arrives at the registered agent email address. The harder parts are standing up GLPI or Zammad, mapping ticket fields, assets and approval flows, and validating the result. Ask yourself whether you have spare capacity for several weeks of project work and an engineer who can own the platform after go-live. If not, a fixed-scope implementation partner is a reasonable option to weigh against the cost of delay.
What makes a Freshservice migration take more or less effort?
Effort scales with the things you have configured in Freshservice, not with the number of exports you run. The main drivers are:
- Asset volume and data quality: a large, well-maintained asset register loads faster than one with duplicate or stale records that must be cleaned first.
- Custom workflows: each custom approval, routing rule or change process must be redesigned in GLPI or Zammad.
- Integrations: every connected monitoring, identity or HR system needs a new connector or a rebuilt feed.
- Parsing the XML: the export is a structured file that your team or partner must map to the target data model, and field mapping is usually the largest single task.
Confirm the volume of each category with a short inventory before you request a scope.
What skills does the internal team need for a GLPI or Zammad migration?
The team needs four kinds of skill. Platform administration covers installing, configuring and patching the application on your own servers. Database and data engineering covers reading the XML, transforming it and validating row counts and relationships. Process ownership means someone who can decide how incidents, changes and assets should behave under ITIL-aligned practice. Security and operations cover access control, backups, logging and monitoring. Most organizations have the first and last covered and borrow the middle two. Check which of these you can staff for the duration of the project and who will maintain the platform after it goes live.
Does GLPI or Zammad need a paid support contract to run?
Neither needs a paid contract to install or run. GLPI is free software under GPL-3.0 and is edited by Teclib', which also offers GLPI Network, a hosted cloud service with a free 45-day trial. Zammad is licensed under AGPLv3 and its source is owned by the Zammad Foundation. Zammad GmbH sells hosted plans in German data centers and support contracts for self-hosted installations named Business, Enterprise and Corporation. A support contract is optional, but it changes who answers when production fails. Ask each vendor what response commitments each tier includes, and whether they cover your version, your hosting model and your environment before you choose.
How long does a Freshservice move typically take?
No duration is supplied here, so treat any number you hear with caution. Timelines depend on the size of your asset estate, the number of custom workflows, the integrations to rebuild, how much data cleaning is needed, and how many approval rounds your change board requires. A practical approach is to plan in phases: discovery and data export, target design, a pilot with a subset of teams, cutover and a parallel-run period. Ask any implementation partner to break the timeline into these phases in the written scope, and ask your own team to estimate each phase separately.
What should a written scope for a Freshservice migration include?
A written scope turns estimates into commitments. It should state which Freshservice data sets are in scope, including tickets, assets, CMDB relationships, knowledge articles, contracts and users. It should name the target platform and version, the hosting environment, the integrations to rebuild, the workflows to redesign and the acceptance tests for each. It should say who performs data mapping, who validates results and who owns the cutover. Include backup and rollback steps, documentation, training and the handover to your operations team. Finally, state what is excluded, such as historical attachments or third-party app data, so there are no surprises at go-live.
Does Freshservice data carry over cleanly into GLPI or Zammad?
Core ticket and requester data usually carries over with mapping work, but fields, statuses, SLAs and automation rules rarely map one to one. Freshservice's XML export gives you the raw record set, so your team or partner must decide how each structure lands in the target model. Test with a representative sample before loading the full history, and confirm with each vendor which import paths exist for your version. Built-in migrators in Zammad cover specific source systems and have stated limits, so check the documentation for your source before relying on them.
Can DeployOpen run the migration as a fixed-scope project?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen does not issue audit reports or certifications, so any compliance evidence still needs an independent assessor.
Keeping ITSM data inside your own boundary
Self-hosting GLPI or Zammad keeps your ticket history, asset records and CMDB data inside the boundary you already control: your cloud account, your data center or an air-gapped network. The application server, database and file storage all run on infrastructure your team or your implementation partner operates, so no ticket content or inventory record leaves that environment unless you configure an export or integration to send it. For a Freshservice replacement, the practical first step is to map where each data class currently sits, including attachments, audit logs, email integrations and the registered agent mailbox that receives the XML export, and to confirm the target environment can hold all of them.
Moving the data is not the same as being able to show how it is protected. A compliance assessor will still ask for access control evidence: a documented list of administrator, agent and read-only roles, the approval trail for granting them, and periodic reviews that remove leavers. GLPI and Zammad both offer role-based permissions, but you must confirm the exact profile and group settings in your chosen version and record them as configuration baselines. Backups are a second area. Test a full restore into a separate environment, not just a backup job that reports success, and keep the restore results as evidence.
Change records are the third area, and they are where ITSM data becomes evidence about your own controls. GLPI covers change management and configuration items, so the change history for the platform itself, including upgrades, plugin installs and configuration edits, should be kept in the same system or in a controlled repository that the platform owner can produce on request. Be clear about what DeployOpen does here: it prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or attestation. Ask your auditor which evidence formats they accept before you design the retention scheme.
How DeployOpen scopes, migrates and supports the replacement
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Freshservice replacement, we start from a written scope that covers the GLPI service desk, asset inventory and CMDB, and the export you take from Freshservice.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which Freshservice modules, assets and workflows move to GLPI and which stay out.
- We confirm whether Zammad is in scope for end-user ticketing, based on your request volume and channels.
- A quote follows from the written scope, so ask for line items for each deliverable.
How we build
- We install and configure GLPI in your cloud account, data center or air-gapped network.
- We map the Freshservice XML export to GLPI tickets, assets, users and categories, and document each mapping.
- We test imported records, approval flows and service level rules against a sample of real-world ticket types from your environment.
- We run security testing on the deployed platform, covering applications, APIs and infrastructure.
How we hand over
- You receive documentation of the configuration, integrations, backup routines and the mapping decisions made during migration.
- Cutover steps and a rollback plan are written down before the Freshservice account is retired.
- We prepare the controls and evidence that your compliance assessor may ask for, without issuing any audit report.
- Your team is trained on administration tasks so day-to-day operation does not depend on us.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrades to new GLPI releases are planned and tested in a non-production copy before they reach production.
- Backups and restore tests are scheduled under the retainer, so you can confirm recovery works.
- Ask in the quote which support hours, response paths and upgrade windows the retainer includes.
