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.