What data should you be able to export before buying event software?

Before buying event software, ask for a usable export of your contacts, marketing permissions, events, orders, tickets and financial records. The files should preserve the links between those records, explain what each field means, and remain available under agreed terms when you leave.

Then ask the vendor to prove it. Set up a small test event, make a few different bookings and download the records yourself. You'll learn far more from opening those files than from a sales answer that says, "Of course, you own your data."

You might be choosing software because your events are growing, your current checkout is frustrating buyers or the reporting takes too much work. Leaving the new provider probably feels like a problem for another year. But the time to check whether you can take your business records elsewhere is before you start collecting them there.

That year can arrive sooner than you plan. In our Event Creators Survey of 350 organisers, about two in three said they were at least moderately likely to switch ticketing platform in the next 12 months.

This guide explains what to request, how to judge the files and which terms to settle before signing. If you've already chosen to move, our guide to switching ticketing platforms covers the actual changeover. Here, we're checking whether a prospective provider deserves the next few years of your event history.

Start with what your business needs to keep doing

The first thing you want to do is write down what you would need the day after your access ended. Could you answer a buyer's question about an old booking? Explain a refund to your accountant? Invite an existing customer to the next event without emailing someone who unsubscribed?

Those are better starting points than asking for "all data." That phrase sounds comprehensive, but it gives both sides too much room to assume they mean the same thing. A vendor might mean every name and email address. You might mean every paid booking, its ticket holders, the money received and the permissions attached to each contact.

Build your request around the work your team actually does. A promoter running general admission club nights needs a different level of detail from a theatre with assigned seats, subscriptions and transferred tickets. A conference business may also need exhibitor contacts and sponsor fulfilment records. You don't need somebody else's full specification to make a sensible purchase.

For each activity, name the records that support it and who will check the export. Your marketer should check contact preferences. The person handling customer support should check booking history. Your accountant should check the money. Ask them what would force them to reopen the old software if it were missing.

Our guide to essential event software features helps with the wider buying decision. Treat export access as part of that decision, because a feature you use every week can create records you'll need long after the contract ends.

Get contacts with the permissions attached

A contact export should distinguish the person who bought a ticket from the people attending. One buyer might book for friends, colleagues or a household. If the software flattens that booking into repeated email addresses, you need to know which address belongs to whom before using it elsewhere.

Request the contact identifier, available names and contact details, the source of the record, and any customer fields your business uses. An identifier is the software's reference for a particular record. It helps you recognise the same contact across several files without assuming that a name or email address will never change.

Marketing preferences deserve their own inspection. Ask for each person's current status, including unsubscribes, plus the available date, source and wording or version of the permission they gave. If your events use several brands, check whether a preference belongs to one brand or every brand in the account. A single "subscribed" column may hide that distinction.

Don't accept a demonstration containing only people who agreed to marketing. Add someone who declines and someone who later unsubscribes. Download again and check both. Also ask how the provider records an unknown preference. Missing information should remain identifiable when you import the file somewhere else.

In the US, the FTC's CAN-SPAM guidance requires businesses to honour opt-out requests within ten business days. Other jurisdictions have different requirements. Whatever rules apply to your audience, a software change should preserve the choices already recorded. An export does not create permission to market to someone.

Keep orders and individual tickets separate

Ask the vendor what one row represents before comparing any totals. Is it an order, a ticket, a person or a payment? A file can look tidy while answering a completely different question from the one you asked.

An order record should identify the event, buyer, purchase date, currency, amounts charged and current order status. Depending on your operation, you may also need billing details, invoice references, discount codes, sales channels and the answers collected during checkout. Ask which fields are standard and which require a separate download.

The ticket file should identify individual tickets and connect them to their orders and events. Check ticket type, attendee details where collected, issue status, transfers and cancellations. For assigned seating, include the section, row and seat reference. If someone changes a ticket holder's name, establish whether the export shows the current holder, the change history or both.

Here's a simple test. Place one booking containing two tickets, then refund only one of them if the product supports that action. Can you see the original booking and identify which ticket is still valid? A total saying "one refund" won't answer that customer support question.

Downloading a ticket reference doesn't make that ticket usable in a different scanner. Ask separately about active ticket migration if it matters to your plans. This buying test checks the record you can retain, while a working ticket transfer needs agreement about validation, cancellation and how existing tickets will be recognised.

Make sure you can explain the money

A sales total is useful during an event campaign. It is insufficient when your accountant needs to explain what reached the bank. Request the records that connect the original charge to fees, refunds, disputes, adjustments and payouts, with the relevant references and currencies.

Check who supplies each record. Your event platform might provide the orders while a payment provider supplies settlement reports. That arrangement can work perfectly well if you know which account contains the information, who controls access and what remains available after you stop using the event software. "It's in the payment system" needs a practical explanation.

Stripe's payout reconciliation documentation illustrates the distinction. Its itemized report lists the transactions included in an automatic payout, including payments, refunds, disputes and fees. Its guidance also explains that different payout arrangements require different reconciliation approaches. Ask your vendor to show the equivalent records for the payment setup it is proposing to you.

Use the test booking to trace money through the files. Start with what the buyer paid, identify each deduction or refund and find the remaining amount in the appropriate balance or payout record. If the test account cannot produce a real payout, ask for an anonymised example from the same payment arrangement and confirm how you will access your own reports.

Don't demand that every platform uses identical column names. Demand that your finance team can understand the figures without guessing. A field called "revenue" needs a definition. It could mean ticket value before fees, the amount charged to the buyer or the amount due to you.

Export event details and the settings you'd have to rebuild

Contacts and transactions aren't the whole business record. Think about the time your team spends setting up each event. Descriptions, schedules, ticket names, prices, sale windows and booking questions may all need to be recreated if you move later.

Request a sample event export and compare it with the event you've configured. Does it contain the full description or only the title and date? Are recurring dates individual events? Do ticket quantities refer to the original allocation, remaining availability or a shared capacity? Ask for the meaning that applies to the product you're considering.

If your business uses seating, test a layout you would actually sell. Find out whether you can download a usable layout file, an image, a seat list or only a PDF. Each has a different purpose. A seat list may preserve what was sold without letting another provider reproduce the booking interface.

Discount rules and booking conditions need the same attention. An export of code names without the dates, eligible ticket types or usage limits may leave your team rebuilding the rules from memory. You can decide some settings are easy enough to recreate, but make that decision after seeing what's available.

For sponsorships or exhibitor bookings, ask which agreements, purchased packages, supplied assets and delivery records belong in the export. Keep the request proportionate to what you will use. You aren't asking the software to reproduce your entire business elsewhere automatically. You're finding out which work you'll have to repeat and which records you can keep.

Check that separate files still connect

The interesting part of an export often appears when you open the second file. You have the contacts, orders and tickets, but can you match them without searching names by hand? If not, the information has left the platform while much of its usefulness remains behind.

Look for stable references shared across the relevant files. A ticket should point to its order. An order should point to its event and buyer. A refund should identify the transaction or booking it changes. You don't need to understand the vendor's database to ask which columns make those connections.

W3C's tabular data model describes how tables can use identifiers and references to express relationships between rows. For your purchasing decision, the practical question is whether your team can follow a booking across the files and reach one consistent answer.

Try two customers with the same name. Then try a customer who books several dates. If the vendor expects you to match records using names alone, those examples should reveal the problem. Email addresses are helpful, but shared addresses and later changes can also make them unreliable as the only connection.

Ask whether those references remain the same in future exports. If the software generates a fresh number every time, comparing this month's download with last month's may become difficult. Also check whether the receiving system can keep the old references in a field, even if it assigns its own numbers after import.

Ask for files your next tools can actually use

For rows of bookings or contacts, ask for CSV or another documented format that your intended tools can read. CSV is a plain text table commonly opened in spreadsheet software. JSON can carry more complex records, but someone still needs to understand its structure and prepare it for the destination.

A PDF can be valuable as an invoice or statement. A screenshot can help explain a report. Neither proves that you can sort the underlying bookings, preserve every field or import the contacts into another service. Ask for the working records as well as the documents your finance team needs to retain.

Request a field guide with the sample files. It should explain column names, dates, time zones, money amounts, status values and the difference between blank and zero. If an amount appears as 4000, you need to know whether that means forty dollars, four thousand dollars or a different currency altogether.

Open a sample containing a long name, an accented character and a booking answer with a comma. Check that each remains in the right column. Ask your analyst or prospective receiving provider to inspect more complicated exports rather than relying on how they look in a spreadsheet preview.

You don't need a universal format that imports everywhere untouched. You need a documented file that can be converted with reasonable effort. If conversion requires paid specialist work, establish the likely cost before comparing the vendor's price with an alternative whose exports your team already understands.

Ask the receiving provider what it can actually import before treating a successful download as a complete move. It may accept contact names and email preferences while leaving old orders in an archive. That can still meet your needs if customer support and finance can retrieve those records separately. What matters is agreeing where each kind of information will remain usable. Ask who will prepare the files, what that preparation involves and how you'll verify the result. Include that work in the purchase decision rather than assuming another system will accept everything exactly as downloaded.

Find out what reports and history leave out

Ask whether the export contains the current position, a history of changes or both. Those serve different needs. A current attendee list can tell staff who should enter tonight. It may tell you nothing about a ticket transfer, an earlier refund or a change to the price.

For check-in records, establish what the timestamp means and which time zone it uses. If tickets can be scanned repeatedly or used across sessions, ask which attempts are included. Don't compare a count of successful admissions with a count of all scan attempts and call the difference missing data.

Marketing reports have similar limits. You may be able to export campaign names, sends and recorded engagement while losing the saved audience rules that produced each campaign. If you want to repeat a segment later, ask whether its conditions can be documented or downloaded. A list of today's members won't necessarily reproduce that audience next month.

For your own analysis, distinguish recorded events from the provider's calculated judgments. A recorded order source is different from a proprietary attribution model that assigns credit to a campaign. Ask which underlying records and definitions you can retain when the model itself is unavailable.

You can accept an exclusion when it doesn't affect your operation. The problem is discovering it after you've built reporting around information that only exists on the vendor's screen. Keep the missing items in the buying notes so your team can decide whether to change its process or choose another provider.

Be specific about media and restricted information

A file containing image links doesn't necessarily contain the images. Ask whether you can download your uploaded originals in bulk, whether names are preserved and whether any exported links expire. Check event artwork, sponsor logos and attachments your team might otherwise have to request again.

Also distinguish an original upload from the version displayed on the page. If the platform crops or resizes images, you may want the original for reuse. For material supplied by a photographer or sponsor, keep the relevant usage agreement too. Possessing a downloaded file doesn't settle what you're allowed to do with it.

Some exclusions are appropriate. Don't ask a vendor to provide raw payment card security codes as proof of completeness. The PCI Security Standards Council explains that sensitive authentication data must not be stored after authorisation, even when encrypted. Booking and payment references are the records to discuss with your payment provider, rather than a general spreadsheet of card credentials.

Sensitive attendee information needs deliberate handling too. If you collect accessibility requests, dietary details or identity documents, decide whether each item genuinely needs exporting and who should receive it. A bulk download containing everything can create unnecessary access for people who only need sales totals.

Ask the vendor to identify exclusions and their reasons in writing. That lets you separate information it cannot appropriately disclose from records it simply hasn't built a download for. Those are different buying considerations, and a broad answer about security should explain which particular information is affected.

Test the export using the plan you would buy

Arrange the test before your purchasing decision depends on a deadline. Ask for access to the plan and account permissions your business would actually receive. A demonstration performed by an internal administrator can show what's technically possible while hiding an upgrade or support request you'll need later.

Create a small event with representative details, then enter a normal order, a group booking and a discount. Include a cancellation or refund where supported, and the contrasting marketing choices discussed earlier. Add the custom question or seating detail that matters to your operation. Use invented personal details and agreed test payment methods.

Download the files as an ordinary authorised account user. Note which reports require separate steps, a support ticket or a higher plan. If the vendor must prepare part of the export, ask it to do so during the evaluation. You want to see the actual delivery process, including how securely you receive the files.

Next, give the download to the people who will use it. Ask support to find the group booking, marketing to exclude the unsubscribed contact and finance to explain the refund. Where possible, try a small import into a suitable test destination. An export can be complete yet need preparation before another system will accept it.

Keep the original files and the vendor's explanations with your purchase notes. If a result is wrong, request a corrected export and repeat the affected check. Don't close the issue because a salesperson says the missing field will be available once you're onboarded.

What a useful sample booking should show

Suppose you're evaluating software for a paid workshop series. Alex buys a ticket for himself and another for Jo. Alex agrees to hear about future workshops. Jo provides a name for the attendee list but doesn't make a marketing choice. Later, Alex cancels Jo's ticket and receives a partial refund. This is an invented test case, not a customer result.

Open the order file first. You should be able to find the booking and establish who paid, which workshop they booked and what the original purchase contained. Open the ticket file next. Find the two tickets using their order reference, then identify the cancelled one. Alex's remaining ticket should be distinguishable from Jo's cancelled ticket without interpreting an unexplained total.

Now inspect the contact records. Can you distinguish Alex's marketing choice from Jo's missing choice? If Jo's contact details have been copied from the buyer because none were supplied, can your team recognise that? Otherwise a future import could turn one person's consent into permission for someone else, or make it look as though you collected information you never received.

Ask finance to follow the partial refund. The export should let them establish the original charge, the refunded amount and the financial records that explain the remaining balance. If charges appear in one report and refunds in another, ask which reference connects them. They should also understand whether fees were returned, retained or adjusted in a separate entry.

Finally, change a detail that you expect to matter next year, such as Alex's email address. Repeat the download and inspect what changed. Does the contact keep its identifier? Does the old booking still point to it? Does the financial record retain the billing information needed to explain the original transaction? Ask the vendor to describe its approach rather than assuming every record should update identically.

The point of this exercise is to discover how the proposed software represents your work. You can make a buying decision when you understand that representation and the files preserve it. If the vendor can't explain the results of a small booking your team has just created, resolve that uncertainty before adding a season of real customers.

Check volume, timing and who controls access

A small test checks the content of the files. It doesn't establish that you can retrieve several years of history before your contract ends. Ask about row limits, date limits, archived events, deleted records and whether you can export the whole account or must repeat the process for each event.

For a multi-venue business, check whether the account structure affects access. An administrator for one venue may be unable to retrieve another venue's records. That can be desirable during normal work, but someone in your business needs an authorised route to the complete set when finance or a future move requires it.

Ask how long larger exports take and how failed jobs are handled. A download delivered by email might expire before the person responsible returns from holiday. An export request might also complete after new sales or refunds have arrived. You need to know the time covered by the file so you can collect later changes without gaps.

Some vendors provide an API, which lets another authorised system request data directly. That can help with ongoing reporting, but ask which records it exposes, whether historical information is available and what usage limits or additional charges apply. The existence of an API doesn't guarantee it includes every item your business needs.

Finally, check account ownership. The business should retain an appropriate administrator when an employee or agency leaves. Ask how you replace that person and recover access. A documented export process is little use if its only authorised user no longer works with you.

Also ask what happens when your own team deletes a contact or event. A provider may correctly remove personal details while retaining limited financial records for a separate purpose. You need to understand that behaviour so an archive doesn't become an excuse to keep unnecessary information indefinitely. Agree who reviews retained files and who can remove them when your business no longer needs them.

Keep test files away from the mailing list and live ticket inventory. Tell everyone helping which records were invented and which payment actions were real. Delete unnecessary evaluation copies once the purchase decision is documented. The export test should help you choose software without leaving confusing bookings for the team that later opens the account.

Settle the exit terms before signing

Ask the vendor to put the export scope, format, access route and applicable charges into the agreement or an incorporated schedule. Include the records you tested and the known exclusions. The wording should identify what you'll receive rather than promising a vague right to your data.

Agree when you can request the files, how long delivery takes and what happens after cancellation. Will you have read-only access? For how long? Is a final export included, and can you request another one if a late refund or dispute changes the financial records? An exit date should account for unfinished business as well as the last event you sell.

If the vendor offers a managed export, establish the price or how it will be calculated. Clarify whether payment of an outstanding invoice affects download access, and have your adviser review any disputed terms before signing. You don't want your only usable copy dependent on a negotiation held after the relationship has deteriorated.

Don't substitute a general reference to privacy law for these commercial terms. The UK's ICO describes the right to data portability as an individual's right concerning certain personal data, subject to conditions. It is not a blanket promise that an event business can obtain every operational record, report or setting it wants from a supplier.

Ask your legal adviser to check the obligations that apply to your business and contract. Your practical purchasing requirement remains straightforward. You should understand which business records you can retrieve, what the process costs and what access continues while remaining obligations are resolved.

Make the buying decision with the files open

Bring the findings back to the people approving the software. Which records downloaded correctly? Which need manual preparation? Which are unavailable, and what would that prevent your team doing? These answers belong alongside subscription charges and ticket fees because missing history can create real work later.

A provider with several separate, clearly documented exports may suit you better than one with an impressive download button that omits permissions or refunds. Equally, don't reject good software because it won't reproduce a feature your business never uses. Judge the limitations against your events and the records you have a reason to retain.

If you're assessing Loopyah's event software, make the same request. Ask to see the export files for your intended setup and test the records your team depends on. A product page or a feature list cannot establish that a particular download contains the detail you need.

Before you approve the purchase, keep a sample export, its field definitions and the agreed exit terms in a location your business controls. Record any unresolved omission and who accepted it. That gives the next person responsible for the account something more useful than a remembered promise from a sales call.

Then choose with a clear understanding of the commitment. You're deciding where future bookings, customer choices and financial history will accumulate. Seeing how those records leave the system is a reasonable part of deciding where to put them.