Switching Ticketing Platforms: What to Migrate and What to Test

What switching a ticketing platform actually involves

Four workstreams move at once, and they fail in a predictable order when one is rushed. Data is what leaves one system and has to be usable in the other. Money covers who holds the float, when payouts stop and restart, and how refunds on old orders are processed. Access means door staff, scanners, roles and permissions on the new platform. Communication is what ticket holders are told, when they are told it, and what happens to the ticket already sitting in their inbox.

All four belong in the plan before anything is signed, because three of them have a fixed date attached - the moment you stop selling on the old platform - and that date is the hardest thing to move once it is public.

• Data: events, price bands, customers, order history and any scan records you still need. Decide what has to be exact, what only has to be reportable, and what can simply be archived.
• Money: the day the old platform stops paying out, the day the new one starts, and the refund path for orders that were never migrated as live transactions.
• Access: who can sell, who can comp, who can refund and who can admit - on the new system, before the first event, not on the night.
• Communication: what buyers are told, how they find their existing tickets, and where they are told to look if a confirmation email arrives from a domain they do not recognise.

What to migrate, and the order that avoids rework

Migrate the objects that sales depend on before anything cosmetic. Getting events, price bands and capacity right in the new platform is what makes customer records useful; loading customers first gives you a contact list with nothing to sell them.

• Events, dates and performance times, with any per-date capacity. A series needs every date created before the first seat is sold, or the first sale is a test you cannot refund.
• Price bands, fee treatment and channel rules - what the buyer pays, what the platform deducts, and what differs between online, box office and door.
• Inventory and capacity per area, including standing areas and seated blocks, so the inside count is derived from sold tickets rather than estimated at the door.
• Holds, comps and guest lists, because these consume capacity whether or not money changed hands. A hold that does not migrate is capacity you will oversell.
• Season passes and subscriptions that span the switch, since a pass sold on the old platform has to admit people on the new one. This is the migration item most often discovered too late.
• Customer records with consent status attached, not just email addresses. What someone agreed to receive is part of the record, and importing a list without it is how a migration becomes a compliance problem.
• Order history as reporting data, so you can answer fee, refund and revenue questions about past events without logging back in to a system you are leaving.
• Roles, permissions and scan devices, configured and tested before door staff see them.

What cannot move, and what to plan instead

Some things do not transfer between platforms, and the migration plan should name them rather than discover them in the second week.

• Saved card details. Card numbers are stored by a payment processor, not by the ticketing platform, and they cannot be copied from one platform to another. Buyers re-enter payment details on their next purchase, which is a checkout decision rather than a data decision.
• Past transactions as live orders. Historic orders exported from the old platform are records, not working transactions, so refunds and exchanges against them are handled in the old system or manually - decide which before you close it.
• Marketplace-side assets. If the outgoing platform owned the audience, the listings, the reviews and the buyer relationship stay with it. That is the price of selling through someone else and the argument for holding your own customer records.
• Search visibility and inbound links. Event URLs change, so old links need real redirects from a crawlable path, not a page that redirects in the browser after loading.
• Anything still in print. Posters, programmes and tickets already in circulation carry the old domain or an old QR code - plan the landing path for those before the first event, not after it.

The five tests to run before you announce the switch

Run these on the new platform against a real event with a small number of real orders, in this order. Each one tests state rather than features: which record knows what, and when.

• Sell, scan, reconcile. One ticket sold online, admitted at the door, then check the capacity count. If the sold count and the admitted count live in different places, you have found the whole problem in ten minutes.
• Scan with the network off. Disconnect the venue wifi, admit a batch, reconnect, then confirm nothing was lost and nothing was admitted twice.
• Refund and exchange a migrated order. Take an order created on the old platform and process a refund and a date exchange on the new one. If that path needs a spreadsheet, it will need one at the busiest possible moment.
• Comp and hold, then try to oversell. Add a comp and a hold of equal size to remaining inventory and attempt to sell both. Capacity that can be double-counted is not capacity.
• Produce the night-close report. Ask for the report you would actually close an event on - sold by channel, fees, admitted, refunds, door cash - and note how many exports it takes. That is your after-event routine, every event, for as long as you stay.

The risks that are not on the plan

The failures that upset audiences are rarely database copies that went wrong. They are second-order effects of two systems being live at once.

• Two systems selling the same event. If the old listing stays open while the new one sells, the inventory is duplicated and the oversell is invisible until the door. Close online sales on the outgoing platform before you open them on the new one.
• A series in flight. Cut over between runs, never in the middle, because passes, transfers and partial-run reporting all cross the boundary.
• Freshly trained door staff. The people scanning have usually had one briefing, so permissions and a printed one-page fallback matter more than the admin console.
• Email the buyer no longer recognises. Confirmations from a new sender address look like phishing. Tell buyers what the new emails will look like before the first one arrives.
• Marketing links that still resolve. Ads, bios and posters pointing at the old event pages need redirects, and those redirects should be checked after the cutover rather than assumed.
• The refund window. Do not delete the old platform the day you stop selling on it. Keep read access for the period in which buyers can still claim refunds, then archive.

Picking the cutover point

The safest cutover has an empty calendar: no event on the night it happens, no sale in flight that has to be honoured on both systems, and a gap long enough to run the five tests above with real orders.

If sales run continuously, shorten the risk instead of skipping the work. Move online sales to the new platform at a stated time, keep the old platform read-only for order history and refunds, and settle on one system as the record of truth for capacity. The single arrangement to avoid is two systems that both believe they are selling the last ten seats.

What to look for in the platform you are moving to

Compare against the migration you are about to do, not the demo you were shown. The platform that makes this easy is the one that keeps your data portable and your record single.

• One record for sold, held, comped and admitted, so the capacity number is derived rather than reconciled.
• Exportable everything - orders, customers, scan records - in a format you could use without the platform.
• Per-date inventory plus passes, so a series does not require a workaround.
• Admission built for disconnected operation, because venue wifi is not a plan.
• Roles that match how a venue actually runs: door staff who scan, a manager who comps, an owner who refunds.
• Fees and payouts stated in writing, including what happens to a refund processed after the event.

Why a storefront and a box office belong in one place

Most of the risks above come from the same root cause: the system that sells and the system that admits keep separate records of the same person and the same seat. Every extra system at the boundary is another export, another reconciliation and another place for the counts to disagree.

ShopDango takes the position that events belong inside the storefront rather than beside it. A date and its price bands are inventory, the buyer is a customer record on your own site, and the scan at the door reads the same data the checkout wrote. Migration, on that shape, is a data exercise rather than a reconciliation project - and the night-close report is a view, not an export.