Known losses

Most event data migrates cleanly between The Events Calendar and NetterTech Events, but a handful of fields are expected not to survive a complete round-trip. This page documents those losses up front so you can plan around them.

Summary

Field	Direction	Impact	Workaround
Venue Post ID	TEC → NTE	Low	Venue data preserved, just denormalized
Ticket Security Codes	TEC → NTE → TEC	Medium	Requires ticket reissue
External Event URL	TEC → NTE	Low	Manual entry if needed
Hide From Upcoming	TEC → NTE	Low	Use NTE status field instead
Cost Display Fields	TEC → NTE	None	NTE uses actual ticket prices (improvement)
Layout Config	NTE → TEC	Low	Per-event customization lost
Check-in Token	NTE → TEC	Low	Volunteer check-in URLs lost
Checked-in Count	NTE → TEC	Medium	Partial check-in detail lost
Accessibility Notes	NTE → TEC	Low	Map to generic notes

TEC → NetterTech Events losses

Venue post ID

Field: _EventVenueID (TEC post ID)
Impact: Low
Reason: NetterTech Events stores venue data directly on the event record instead of maintaining separate venue posts.
What’s preserved: All venue information (name, address, city, state, postal code, country, phone, website) is denormalized onto each event.
Round-trip impact: If you migrate back to TEC, new venue posts are created. Duplicate detection prevents redundant venues.

Ticket security codes

Fields: _tribe_wooticket_security_code, _ticket_security_code
Impact: Medium – affects existing QR codes and ticket barcodes.
Reason: NetterTech Events generates its own unique ticket codes using a different format.
User impact: Existing QR codes and ticket barcodes from TEC become invalid after migration.
Workaround: Implement a “Reissue Tickets” workflow after migration to send attendees new QR codes. Plan this before you migrate if you have sold tickets.

External event URL

Field: _EventURL
Impact: Low
Reason: NetterTech Events has no equivalent field for external event URLs.
Workaround: Add the external URL to the event description, or use a custom field.

Hide from upcoming

Field: _EventHideFromUpcoming
Impact: Low
Reason: NetterTech Events uses event status (published, draft, hidden) instead of a separate hide flag.
Workaround: Events marked as hidden in TEC can be set to hidden or draft status in NetterTech Events after migration.

Cost display fields

Fields: _EventCost, _EventCostDescription, _EventCurrencySymbol, _EventCurrencyPosition
Impact: None – this is actually an improvement.
Reason: NetterTech Events calculates and displays prices from actual ticket type records rather than storing display-only cost fields.
Benefit: The displayed price always matches real ticket prices. No possibility of drift between the cost string and the actual cart.

NetterTech Events → TEC losses

These losses only matter if you’re migrating back to TEC (for example, to exit NetterTech Events or to run a parallel instance).

Layout config

Field: layout_config (JSON)
Impact: Low
Reason: TEC has no equivalent for per-event layout customization. NetterTech Events allows events to override default template layouts.
User impact: Events exported to TEC will use TEC’s default layouts. Any per-event layout customization is lost.

Check-in token

Field: checkin_token
Impact: Low
Reason: NetterTech Events’ volunteer check-in system uses unique tokens for each event/occurrence. TEC has no equivalent concept.
User impact: Volunteer check-in URLs become invalid after export to TEC.

Checked-in count (partial check-in)

Field: checked_in_count
Impact: Medium – partial check-in detail is lost.
Reason: NetterTech Events supports partial check-in (e.g., 2 of 4 tickets checked in for one attendee). TEC only tracks a binary checked-in status.
Example:
- Before: NetterTech Events shows “Attendee has 4 tickets, 2 checked in”
- After export to TEC: Attendee shows as checked_in = true, losing the “2 of 4” detail

Accessibility notes

Field: accessibility_notes
Impact: Low
Reason: NetterTech Events has a dedicated field for accessibility requirements. TEC only has generic notes.
Workaround: Accessibility notes can be mapped to TEC’s generic notes field or prepended to attendee info.

Bidirectional considerations

Series / recurring events

Partial support. TEC → NetterTech Events imports series relationships and generates occurrences from RRULE. NetterTech Events → TEC exports the RRULE, but series post relationships may not be recreated identically. Occurrences will match, but administrative structure may differ.

Featured images

Full support. Both directions. Images are re-attached to the destination post/event and maintain their WordPress media library relationships.

Organizer images

Full support. Same handling as featured images.

Migration recommendations

Before migration

Back up everything – database and uploads directory
Inform users about ticket reissue if applicable
Document custom fields – any TEC custom meta that may not have NetterTech equivalents
Test with dry run – use dry-run mode first to see what will change

After TEC → NetterTech Events migration

Verify venue data on spot-checked events
Review hidden events – check the status of events that were hidden in TEC
Plan ticket reissue if tickets were sold in TEC – existing QR codes are invalid

After NetterTech Events → TEC migration

Check attendee status – verify check-in data looks correct
Review event layouts – re-apply any custom layouts
Test check-in in TEC

ID preservation

IDs are not preserved across systems. The migration uses slug-based matching to maintain relationships:

Entity	Matched by
Events	`post_name` / slug
Categories	slug
Tags	slug
Organizers	slug
Ticket Types	name + event slug
Attendees	email + event slug + ticket name

This means: if you run a migration, delete the destination, and re-run, the migrator will recreate everything with new IDs but the same slug-based relationships.

Shared Capacity (Event Tickets “shared” stock)

Field: _global_stock_mode / _global_stock_cap on the ticket, _tribe_ticket_use_global_stock / _tribe_ticket_capacity on the event Impact: Low (mapped; one documented simplification) Mapping: A ticket that draws from the event’s shared pool (global) becomes a shared ticket type and the pool becomes the occurrence’s capacity (the “house”). A capped ticket becomes a fixed type with its own ceiling, still bounded by the house at checkout. Tickets with their own stock (own) and unlimited tickets are unchanged. The reverse export writes the same keys back, so a shared setup survives a round trip. Simplification: On a recurring event with several dates and one shared pool, the pool cannot be attached to a single date, so its tickets are imported as fixed types sized to the pool. Each date still carries the pool as its capacity, so no date can oversell; what is lost is the “one pool across all dates” accounting. Single-date events keep the shared type exactly. Warnings: The pre-flight check flags tickets that claim shared stock on an event with no pool (imported as unlimited) and unlimited tickets on a pooled event (not bounded by the house).

Attendee Registration Fields (Event Tickets Plus)

Field: _tribe_tickets_meta_enabled / _tribe_tickets_meta on the ticket (definitions) and on the attendee (answers) Impact: Low (mapped) Mapping: Registration questions defined on a ticket become NetterTech attendee fields on the event (one field per event and question key, so the same question on several tickets of one event is merged), and each attendee’s answers become field values on the imported attendee. Field types map one-to-one (telephone becomes phone; birth and date/time become date); a type NetterTech does not have is imported as a text field and flagged in the pre-flight check. Checkbox answers, which Event Tickets Plus stores one option at a time, are folded into a single comma-separated value. Not carried: conditional display rules and saved field sets (templates) — the fields themselves are imported, the reusable set is not.