Migrating from Spiceworks or osTicket: what to keep from a decade of self-hosted history

Spiceworks and osTicket deserve more respect than migration guides usually give them. Between them they have run the internal service desk at an enormous number of small and mid-sized companies, for a decade or more, at a software cost of zero. Plenty of teams learned what a ticket queue even is from one of them. If you are leaving, you are not leaving because the tool failed at its job.

You are leaving because of what has accumulated around it. This guide covers the move: what actually pushes teams off these tools, how to get your data out of a database you happen to own, how to deal with a decade of custom fields, and a cutover that finishes with the old server switched off rather than quietly humming in a corner.

Why teams leave

For osTicket the honest reason is almost always the operational burden. It is open source PHP and MySQL that you host, which means you own the version upgrades, the TLS certificates, the PHP end-of-life migrations, the database backups, and the patching of an internet-facing application that holds employee names, addresses, screenshots, and occasionally credentials that somebody pasted into a ticket. That burden is manageable while the person who set it up is still around. It becomes a risk the moment they leave and the install drifts a few versions behind, at which point you are running an unsupported version you are afraid to upgrade — which means you are also afraid to patch, which is the actual problem.

For Spiceworks the pressure tends to come from product direction rather than pain. The free help desk is ad-supported, and the emphasis has moved toward the hosted version. If you are running a self-hosted install, confirm its current support status with the vendor before you plan around it, and note where your data physically lives in the hosted version if you have residency obligations.

The second reason, common to both, is that neither was designed for what teams now want from a service desk. Modern triage means reading a ticket against your resolved history and your systems and acting on it, not matching keywords to a department. That is not a feature you bolt on to a 2011 data model with a plugin; it needs the ticket, the thread, and the surrounding context in one place. Be clear-eyed that this — plus the patching — is the actual driver, because it should shape what you evaluate. A replacement that is merely a nicer-looking queue solves neither problem.

What to export from a self-hosted database

Here is the one large advantage of leaving a self-hosted tool: you own the database. You are not negotiating with an API rate limit or a vendor export queue. Take a dump, restore it somewhere private, and work from the copy — never query the live server, and never let a migration script write to it.

Pull each of these to a neutral format, one file per table, so you are not locked into whichever importer you end up using.

• •Ticket records with every field: subject, status, priority, department or queue, help topic, created and closed timestamps, requester, and assignee.
• •The thread entries — osTicket stores messages, responses, and internal notes as thread items, and that is where the resolutions actually live.
• •User and staff tables including email addresses, which are your join key for identity mapping later.
• •Custom form and field definitions exported alongside their values, so that a stored value of "3" still means something afterwards.
• •Canned responses and any knowledge base or FAQ content, as plain text — years of canned replies are a knowledge corpus, whatever the mechanism.
• •An attachment inventory (ticket id, filename, size) even if you decide not to move the binaries; note whether your install stores files on disk or in the database.

Two failure modes are worth pre-empting because they are near-universal in old self-hosted installs. The first is character encoding: MySQL databases that have been through several upgrades routinely hold UTF-8 bytes in latin1 columns, and nobody notices until every apostrophe and accented name turns into garbage inside the new tool. Check a few non-English names and quoted strings in your export before you trust it. The second is HTML: ticket bodies are often stored as HTML fragments of varying quality, and an importer that treats them as plain text will show your users escaped tags for the next five years. Decide up front whether you are importing HTML or converting to text, and test both on a ticket with a table in it.

Treat the dump itself as a sensitive artifact. It is a decade of employee personal data in one file. Encrypt it, keep it off shared drives, restrict who can restore it, and set a date to delete the working copies once the migration is verified.

Mapping legacy custom fields

A helpdesk that has run for ten years has fields nobody can explain. There is an Asset Tag field that half the tickets fill in, a dropdown with forty options of which six are ever selected, a checkbox added for a 2019 audit, and a text field named "Notes2". The instinct is to recreate all of it in the new tool so that nothing is lost. Resist it: a schema built to hold dead data is dead weight you will carry for another decade.

Map by reading values, not names. Export the last twelve months of each field, count the distinct values and the fill rate, and sort the results into three piles. Fields that still drive routing or fulfilment get migrated properly. Fields that are historical record only get flattened into the ticket body or a single notes field on the imported record — the information survives, the schema does not. Fields whose meaning cannot be reconstructed by anyone still at the company stay in the archive, which is the honest place for data you cannot interpret.

Two structural mappings need a decision rather than a rule. Departments and queues in these tools usually encode two things at once — the team that owns the work and the kind of work it is — because there was only one dimension available. Split them on the way out into an owning team and a category, or you will import that ambiguity permanently. And help topics, which requesters chose from a dropdown, are worth keeping as a category signal even if you retire the dropdown itself: they are a decade of humans labelling their own requests, which is unusually good training data for triage.

Your history is the asset, not the configuration

Teams consistently undervalue the archive because it looks like clutter — tens of thousands of rows about printers. It is the single thing in the migration that a vendor cannot sell you and a competitor cannot copy. It contains your systems under the names your staff actually use, your recurring failures, your seasonal patterns, and the specific fixes that worked in your environment. That corpus is what makes AI triage specific to your company rather than generically competent, and it is why a long free history is worth more than the configuration you built around it.

The practical consequence is a split. Import a live window — open tickets plus a recent period, commonly six to twelve months, or thirteen or more if your queue is genuinely seasonal — and keep the full corpus somewhere queryable rather than deleting it with the old server. If the new tool can ground on more than the live window, give it more. If it cannot, the archive is still the reference you will want the first time someone asks whether this has happened before.

One caution before you import anything. A decade of tickets contains a decade of things people should not have pasted into tickets: passwords, API keys, bank details, medical notes, screenshots of payslips. Scan the export for obvious secret patterns, rotate anything you find, and get a decision from whoever owns data protection about what is imported versus archived. Migrating that content into a new system without review is how a migration becomes an incident.

The cutover

The shape is the same as any queue migration, with one extra step self-hosted teams keep forgetting. New tickets go to the new tool from day one; open tickets drain where they are rather than being re-keyed mid-conversation; the two systems run in parallel for about two weeks while the team works real volume in the new one; and then the old system is actually turned off.

Decommissioning deserves its own owner and its own date. An abandoned helpdesk VM, still reachable, still holding employee personal data, still running the PHP version you were afraid to upgrade, is precisely the risk the migration was meant to remove — and it is more dangerous after the migration than before, because nobody is logging into it any more and nobody would notice if someone else did. Take it off the public internet on the day intake is redirected, keep it read-only and internal while people still need to look things up, and delete it on a scheduled date once you have proven the archive is complete and searchable elsewhere.

Announce the change where people file, not in a company-wide email nobody reads. If your intake was a support address, the forward changes and most requesters never notice. That is the correct outcome: a migration the requesters do not have to participate in is a migration that works.

On the new-tool side, FlowTux is a reasonable landing spot for these teams for the reasons that pushed them out — it is hosted, so the patching stops being yours, and pricing is flat from $49 a month rather than per agent, which matters when you are coming from free and the alternative quotes are per-seat. Assume a scripted import from your own dump rather than a turnkey migration. What the imported history buys you is immediate: triage grounded in resolved history and the linked codebase, semantic deduplication of repeat requests, and per-category suggest, approve, or autonomous modes so you can promote one category at a time. Autonomous resolution is allow-listed and every step is written to the ticket timeline as an audit trail. Intake arrives from Slack, Teams, email, and WhatsApp, and data can be held in the EU, US, or India — worth checking against whatever your self-hosted install implicitly guaranteed by sitting in your own building.