Practical guide

Change ticketing platforms without running two conflicting admission records

Last materially reviewed 2026-09-28

Quick answerChoose the authoritative record and a deliberate transition point before moving an active event.
What to know

Decide whether a move is necessary now

Changing platforms during an active sales period can create several records of the same entitlement. Consider whether the observed problem can be repaired before the event and a broader move deferred. This is not a recommendation to tolerate a critical failure; it is a reminder to compare the risks of the change itself. The organizer should own the decision and the evidence behind it.

What to know

Map what must remain valid

List the existing tickets, customer communications, payment records and admission rules that need continuity. Do not assume an export can recreate every status or code in another product. Verify what the destination accepts and what remains in the original system. Keep the payment and refund responsibilities separate from the doorlist plan. This guide does not execute a migration or promise that a vendor supports a particular transfer.

What to know

Avoid two sources of truth

Name the authoritative route for each period and explain how the door team distinguishes old and new tickets. A merged spreadsheet without provenance can hide duplicates or omissions. Preserve the source of each record and any unresolved mapping privately. Rehearse an existing ticket, a new ticket and a changed ticket through the intended admission process before calling the transition ready. Do not invent replacement entitlements to make counts match.

What to know

A fictional deferred move

A committee finds a promising alternative but cannot verify how existing codes will be handled before Saturday. It retains the current admission process, documents a repair for the immediate issue and schedules its own later platform decision. The comparison remains useful without forcing a rushed transition. After the event, the organization can assess the next event’s requirements with fewer live dependencies and a clearer record of what actually needs improvement.

Continue when useful

Next: Requirements brief

Turn each important promise into a named task, an expected result and an owner.

Open Requirements brief →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Ticket Tailor: printing a doorlist — Merchant documentation · help.tickettailor.com · Merchant-controlled · checked 2026-09-28
  2. Ticket Tailor: check-in reporting and its limitations — Merchant documentation · help.tickettailor.com · Merchant-controlled · checked 2026-09-28
  3. Ticket Tailor: preparing check-in devices — Merchant documentation · help.tickettailor.com · Merchant-controlled · checked 2026-09-28