Migrate your osTicket data
Open-source PHP helpdesk ticketing system for small teams who want full server control and zero per-agent licensing fees.
In its favor
Why people choose osTicket
The signal that keeps osTicket on the shortlist. Sourced from G2, Capterra, and customer scoping calls.
Free and open-source with no per-agent or per-ticket licensing fees, making it a zero-cost starting point for IT teams evaluating helpdesk software before committing budget elsewhere.
Fully self-hosted on a standard LAMP/LEMP stack, giving sysadmins complete control over the server environment, data residency, and customisation without vendor lock-in.
Highly customisable ticket forms, workflows, and SLA rules through the admin panel without requiring code changes for most configuration needs.
Active open-source community and commercial support package available, providing a path from free试用 to paid assistance when the team grows.
Lightweight PHP application that runs reliably on modest hardware and is straightforward to deploy on a VPS or existing web server.
No built-in live chat or real-time messaging channel, forcing teams to cobble together third-party chat integrations or manage chat separately from the ticketing workflow.
Limited scalability for high-volume environments — teams handling hundreds of tickets per day report performance degradation and lacking advanced routing or queue management.
Reporting and analytics are basic at best; there is no native dashboard with trend visualisation, SLA compliance charts, or agent performance metrics without third-party plugins.
Community-only support on the free tier means no guaranteed response time, and the commercial support package is priced as a separate annual subscription.
Teams outgrow the feature set as they scale — absence of built-in asset management, contract tracking, or advanced automation pushes organisations toward purpose-built ITSM platforms.
Reasons to switch
Why people leave osTicket
The recurring reasons buyers give for replacing osTicket. Presented as facts, not knocks.
Platform scorecard
Strengths, weaknesses, and where osTicket fits
Grades across six dimensions, plus a SWOT-style view of where the platform shines and where it falls short.
SWOT — strengths, weaknesses, and use-case fit
Strengths
Weaknesses
Where it works
Where it struggles
Pricing tiers
osTicket pricing overview
osTicket's core application is free and open-source. Commercial support is sold as an annual subscription priced per agent seat, covering email support, premium plugins, security patches, and guaranteed response times. There are no per-ticket or per-user licensing fees for the open-source edition.
Free (Open Source)
Tier 1 of 3
Free
What's included
Need help selecting your Helpdesk?
Book a free 30 minute consultationPricing is informational. FlitStack AI does not bill on osTicket's schedule — see our quote-based pricing →
What gets migrated
osTicket object support
Object-by-object support for osTicket migrations. Per-pair details surface during scoping.
Tickets
Fully supportedTickets are the primary object in osTicket. They include a rich-text Thread, Custom Fields, SLA Plan assignment, Department, Help Topic, and status/priority metadata. We migrate Tickets 1:1 with their thread as a single conversation record, preserving timestamps, status, and priority.
Users (End Users / Customers)
Fully supportedUsers submit tickets and are stored with name, email, phone, and organisation linkage. We map Users to the destination's contact/customer object. osTicket allows users with no Organisation, which we flag for explicit orphan handling during the mapping phase.
Agents (Staff / Operators)
Mapping requiredAgents are staff members who receive and respond to tickets. osTicket assigns agents to Departments and Teams with granular per-department permissions. We map Agents to the destination's agent/staff object but flag non-transferable permission scopes that require manual reassignment after migration.
Organisations (Companies)
Mapping requiredosTicket Organisations represent companies that Users belong to. The relationship is loosely enforced — a User can exist without an Organisation. We preserve Organisation names and link them to User records, but note that not all destination CRMs model Organisations as a first-class entity.
Custom Fields
Mapping requiredCustom Fields are configurable per ticket and user forms. osTicket stores them as typed fields (text, boolean, date, list, etc.) with different visibility rules for agents vs. users. We map Custom Fields by type and apply them to the corresponding destination object, noting where the destination field type does not match.
Attachments
Mapping requiredosTicket stores attachments separately from the ticket thread record and links them by attachment ID. We extract attachment records alongside the ticket thread, re-link them in the destination, and note any file size or type restrictions the destination imposes.
Departments
Mapping requiredDepartments control ticket routing and agent permissions in osTicket. They have email routing addresses and SLA plan associations. We map Departments to the destination's queue/team or department entity, but per-department SLA assignments require manual configuration post-migration.
SLA Plans
Mapping requiredSLA Plans define response and resolution deadlines tied to ticket priority. osTicket allows multiple SLA plans assigned by department or help topic. We migrate SLA plan names and time windows as a custom configuration step, since most destination platforms model SLA differently.
Help Topics
Mapping requiredHelp Topics are ticket categories that drive routing and SLA assignment. They are a first-class object in osTicket but are typically modelled as Tags or Categories in other platforms. We map Help Topics to Tags in the destination, preserving the original topic label on each ticket.
Ticket Threads (Conversations)
Fully supportedThe Thread is osTicket's internal conversation record — one per ticket, containing all internal notes and user responses in a merged chronological log. We split the thread into discrete message records in the destination, preserving the agent vs. user author attribution and internal/public flag.
| Object | Support | Notes |
|---|---|---|
| Tickets | Fully supported | Tickets are the primary object in osTicket. They include a rich-text Thread, Custom Fields, SLA Plan assignment, Department, Help Topic, and status/priority metadata. We migrate Tickets 1:1 with their thread as a single conversation record, preserving timestamps, status, and priority. |
| Users (End Users / Customers) | Fully supported | Users submit tickets and are stored with name, email, phone, and organisation linkage. We map Users to the destination's contact/customer object. osTicket allows users with no Organisation, which we flag for explicit orphan handling during the mapping phase. |
| Agents (Staff / Operators) | Mapping required | Agents are staff members who receive and respond to tickets. osTicket assigns agents to Departments and Teams with granular per-department permissions. We map Agents to the destination's agent/staff object but flag non-transferable permission scopes that require manual reassignment after migration. |
| Organisations (Companies) | Mapping required | osTicket Organisations represent companies that Users belong to. The relationship is loosely enforced — a User can exist without an Organisation. We preserve Organisation names and link them to User records, but note that not all destination CRMs model Organisations as a first-class entity. |
| Custom Fields | Mapping required | Custom Fields are configurable per ticket and user forms. osTicket stores them as typed fields (text, boolean, date, list, etc.) with different visibility rules for agents vs. users. We map Custom Fields by type and apply them to the corresponding destination object, noting where the destination field type does not match. |
| Attachments | Mapping required | osTicket stores attachments separately from the ticket thread record and links them by attachment ID. We extract attachment records alongside the ticket thread, re-link them in the destination, and note any file size or type restrictions the destination imposes. |
| Departments | Mapping required | Departments control ticket routing and agent permissions in osTicket. They have email routing addresses and SLA plan associations. We map Departments to the destination's queue/team or department entity, but per-department SLA assignments require manual configuration post-migration. |
| SLA Plans | Mapping required | SLA Plans define response and resolution deadlines tied to ticket priority. osTicket allows multiple SLA plans assigned by department or help topic. We migrate SLA plan names and time windows as a custom configuration step, since most destination platforms model SLA differently. |
| Help Topics | Mapping required | Help Topics are ticket categories that drive routing and SLA assignment. They are a first-class object in osTicket but are typically modelled as Tags or Categories in other platforms. We map Help Topics to Tags in the destination, preserving the original topic label on each ticket. |
| Ticket Threads (Conversations) | Fully supported | The Thread is osTicket's internal conversation record — one per ticket, containing all internal notes and user responses in a merged chronological log. We split the thread into discrete message records in the destination, preserving the agent vs. user author attribution and internal/public flag. |
Gotchas
What to watch for in osTicket migrations
Issues we've hit on past osTicket migrations, tagged by severity. FlitStack AI handles every one — surfacing them up front because buyer engineering teams want to know.
API supports ticket creation only
Ticket threads are a single rich-text blob
Custom fields require optional setting for API
IP-restricted API keys block automated migration tooling
| Severity | Issue |
|---|---|
| High | API supports ticket creation only |
| Medium | Ticket threads are a single rich-text blob |
| Medium | Custom fields require optional setting for API |
| High | IP-restricted API keys block automated migration tooling |
Leaving osTicket?
Where osTicket customers move next
7 destinations osTicket can migrate to.
How a osTicket migration works
Four steps, osTicket-specific
Connect
API key (X-API-Key HTTP header, IP-restricted) into osTicket. Scopes limited to read-only on the data we move.
Map
We translate osTicket-specific structures (custom fields, objects, value lists) to the destination's model.
Sample
Test with a 50–200 record subset to validate osTicket quirks before production.
Migrate
Full migration with osTicket rate-limit handling. Rollback available throughout.
FAQ
osTicket migration FAQ
Answers to the questions buyers ask most during osTicket migration scoping. Not seeing yours? Book a call.
Can't find your answer?
Walk through your osTicket migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationOther helpdesks we support
Ready when you are
Migrate osTicket.
Without the rebuild.
Free scoping call with a migration engineer. Tell us about your osTicket setup and destination — written quote back within a business day.