Changing Ticket Number Format

Changing your ticket number format

You've been running FreeITSM for a few months. Every ticket so far looks like CKQ-418-73926, and you've decided you'd rather they looked like INC-2026-00042.

The question everybody asks at this point is the right one:

Is it actually OK to have old tickets on one scheme and new tickets on another?

Yes. It is not only OK, it is almost always the better choice. This page explains why, and when the alternative is worth it.

---

The short version

Just change the format	Old tickets keep their references. New tickets get the new shape. Nothing breaks, nothing to plan, no risk. Start here.
Change the format and renumber	Everything looks consistent immediately. Costs you the numbers people have already written down. Worth it in one specific situation — see below.

---

Why mixed schemes are fine

The instinct that a mixed estate is untidy is a real one, and worth taking seriously — so here is exactly what does and doesn't depend on the shape of a reference.

Nothing in FreeITSM parses the shape

A reference is looked up, never recognised. When a reply arrives, the subject carries [SDREF:CKQ-418-73926], and FreeITSM takes whatever sits inside that tag and asks the database which ticket it belongs to. It has no opinion about how many letters or digits it should have.

That means an install can carry references from every format it has ever used, all working identically, indefinitely. Search finds them, ⌘K finds them, email replies thread onto them, the REST API returns them.

Old tickets are mostly finished tickets

This is the practical point. A ticket raised four months ago is almost certainly closed. Nobody is going to quote its number down the phone again. The references that get read out, written on forms and pasted into emails are this week's — and those are the ones that will have the new shape from the moment you save.

Give it a fortnight and the awkward-looking old references have dropped off the bottom of everyone's view.

The mixture is self-documenting

There is genuine value in being able to tell, at a glance, that CKQ-418-73926 is from before the change. When somebody digs up an old thread, its reference tells you roughly when it's from — which a renumbered estate throws away.

---

What changing the format actually does

Nothing to existing tickets. Truly nothing: no rows are touched, no history is written, no counter moves. The setting affects the next number issued and nothing else.

The one thing to get right before you save is the starting number, since that's awkward to change later without renumbering:

• Starting from 1 is the natural choice, and means your first sequential ticket is INC-2026-00001.
• Starting from a round number above your ticket count — say 5000 when you have 900 tickets — is worth considering if you'd like sequential numbers never to look like a count of how much work you've done.

Either way the digit width is a floor and not a limit, so there's nothing to run out of.

---

When renumbering is worth it

There is one situation where it clearly earns its risk:

You have just migrated to FreeITSM. The tickets you imported carry references from your old system, or FreeITSM's random ones, they are a few weeks old at most, and nobody outside the IT team has ever quoted one. You want the whole estate to look like it was always numbered your way.

That's the case the tool was built for. It's a migration step, done once, early, before anyone gets attached to a number.

Signals that it's the wrong choice:

• Customers have your ticket numbers. In their inboxes, in their own spreadsheets, in emails to their managers. Those references still work after a renumber — but they no longer match what they see in FreeITSM, and "your ticket is TICKET-000042" against a customer saying "I have CKQ-418-73926" is a conversation you have to have every time.
• Your ticket numbers are quoted outside FreeITSM. Change records, knowledge articles, a supplier's system, a contract, an invoice, a status page. FreeITSM keeps its own references working; it can't update anybody else's copy.
• You're doing it because the mixture looks untidy. That's not a good enough reason to rewrite every reference in the system, and in a fortnight you won't notice.

---

What renumbering guarantees, and what it doesn't

It guarantees

Every old reference goes on working, for ever. Each number a ticket has ever had is kept, and keeps resolving to that ticket. A customer replying to a two-year-old email quoting the old number still lands on the right ticket. This is the same mechanism that already makes merging tickets safe.

A retired number is never given to somebody else. It stays permanently spoken for. Handing it on would mean an old email thread silently arriving on a different ticket, which is worse than not matching at all — so the tool refuses outright rather than allow it.

Order and dates are preserved. Tickets are renumbered oldest first, so the numbers mean something afterwards. A ticket raised in 2024 renumbered under INC-{YYYY}-{#####} comes out as INC-2024-…, not stamped with this year.

All or nothing. One operation. A half-renumbered estate would have two schemes in it and a counter matching neither, so it either does the lot or does nothing.

It doesn't guarantee

That anything outside FreeITSM is updated. A number in a customer's spreadsheet, a supplier's ticketing system or a printed report is not ours to change.

That you can undo it. There is no reverse button. The old numbers are remembered so they keep working, not so they can be put back.

That reports and saved searches read the same. Anything keyed on the text of a reference — a saved filter matching CKQ-%, a spreadsheet formula splitting on hyphens — needs revisiting.

---

If you do renumber: the order to do it in

1. Decide the format and try it in the preview at the top of the numbering screen, before saving anything. The live preview costs nothing and moves no counter.
2. Pick the starting number. Coming from another system, this is where you carry on from where it left off.
3. Save. The renumbering tool reads the saved settings, not what's currently on screen.
4. Take a database backup. It cannot be undone, and this is the only thing that would let you change your mind.
5. Preview the renumber. It runs the entire job and writes nothing, then shows what would change, what already matches, the first and last few conversions, and what the next new ticket would be numbered.
6. Read the first and last few conversions properly. This is the moment to notice a format that isn't doing what you thought.
7. Renumber. The button only turns on once a preview has run.
8. Tell your customers, if any of them hold ticket numbers. Their old references still work, so this is a courtesy rather than a scramble — but the first person to quote an old number will be confused if nobody warned them.

---

A note on changing scope later

Switching Count separately for after you're up and running deserves the same thought.

Going from one shared sequence to per-type or per-company counting starts each new sequence at your configured starting number, which will collide with numbers already issued unless the format distinguishes them — which is why {TYPE} and {COMPANY} are required for those scopes. Existing tickets are untouched, and new tickets simply climb over any collisions rather than failing, but the first few numbers on each new sequence may skip.

If you want each type or company genuinely counting from 1, that's a renumber, and the same considerations on this page apply.

---

See also

• Ticket numbering — every setting, in detail
• Ticket numbering — Developer Guide — what happens underneath
• Merging tickets — the same "old reference keeps resolving" mechanism