What data should be migrated when changing ticketing platforms?
A ticketing migration should move the information needed to fulfil future tickets, serve customers, reconcile money and meet lawful recordkeeping duties. The right scope depends on forthcoming events, open financial liabilities, integrations and whether historic records require active access or can remain in a controlled archive.
What belongs in a migration inventory?
List events, venues, seating and capacities, ticket products, allocations, customer profiles, preferences and consent provenance, orders, refunds, outstanding balances, ticket entitlements, access codes and admission scans. Capture identifiers and relationships, not just spreadsheet rows. The old and new systems may model the same concepts differently.
Which historic records must stay accessible?
Decide which completed events and old orders need searchable operational access, reporting or evidence of financial transactions. Migrating every historical field can add cost and privacy exposure. Archiving may be suitable when permitted by retention policy and legal requirements.
How do you validate the mapping?
Reconcile counts and totals by event and state: sold, refunded, reserved, complimentary and available. Spot-check seated tickets, order taxes, discounts and partially paid orders. Test idempotent re-import and a dry-run with anonymised or appropriately protected representative records.
What should be retained after cutover?
Keep a signed mapping specification, exceptions log, export checksum, acceptance results and clearly scoped read-only access where required. Freeze or synchronise writes during migration so tickets cannot be sold twice.
Which ticketing data-migration checks should buyers approve before cutover?
List which event, customer, order, ticket, refund and historic records must move, remain accessible or be retained. Validate the mapping with representative records and reconcile counts, statuses and financial totals before accepting cutover.