--- title: "Migration Warnings & Troubleshooting" description: Eventixa Migration reports warnings and errors when source data cannot be migrated exactly, a required destination capability is unavailable, or a migration step fails. A warning does not always mean the whole event failed. Eventixa can successfully create the main… url: "https://eventixawp.com/docs/migration-warnings-troubleshooting/" updated: "2026-09-26" category: Migration --- # Migration Warnings & Troubleshooting Eventixa Migration reports warnings and errors when source data cannot be migrated exactly, a required destination capability is unavailable, or a migration step fails. A warning does not always mean the whole event failed. Eventixa can successfully create the main event while reporting a problem with a recurrence rule, timezone, attendee field, virtual-event provider, historical relationship, or another part of the migration. > **Admin Location:** Eventixa → Migration > **Recommended First Step:** Expand Details beside the affected source event > **Important:** Do not remove the source plugin until all important warnings and failures have been reviewed. ## Understanding Migration Results Each source event can show one of several migration states. The most important troubleshooting states are: - Migrated with Warnings - Failed - Requires Pro - Unsupported - Skipped Each status means something different and should be handled differently. ## Migrated with Warnings **Migrated with Warnings** means Eventixa created or updated the main destination event, but one or more migration details need review. The event may still be usable. Examples can include: - Invalid source timezone - Unsupported attendee field - Partially mapped dependency - Virtual-provider fallback - Reconciliation mismatch - Optional data that could not be migrated exactly Always expand **Details** before deciding the migration is complete. ## Failed **Failed** means Eventixa could not complete the required migration workflow for that event. A failure can result from: - Invalid source data - Missing destination dependency - Unexpected source relationship - Database failure - Migration-processing error - Historical record that cannot be reconciled - Temporary environment problem Failed events can usually be retried after the underlying problem is corrected. ## Requires Pro **Requires Pro** means the source event needs a destination capability supplied by Eventixa Pro. A common example is recurring-event migration. Eventixa uses this status rather than silently degrading the source event into a simpler Eventixa structure. ## Unsupported **Unsupported** means Eventixa has identified source data that it cannot currently represent safely. This is not the same as a temporary failure. Unsupported data should generally be reviewed and recreated manually when necessary. ## Skipped **Skipped** means Eventixa deliberately did not process the event or a migration condition prevented it from continuing. Open the migration details to determine why the event was skipped. ## Open Migration Details Go to: **Eventixa → Migration** Find the affected source event and click: **Details** The details area provides the event-specific result needed to understand warnings and failures. ## Do Not Troubleshoot from the Status Badge Alone The status badge tells you the overall migration result. The **Details** section tells you what actually happened. For example, two events can both show **Migrated with Warnings** while having completely different issues. ## Invalid Source Timezone Eventixa validates the source timezone before saving it. If the timezone identifier from the source is invalid or cannot be recognized, Eventixa can report an invalid-source-timezone warning. ## What to Check for a Timezone Warning Compare: - Source event timezone - WordPress site timezone - Migrated Eventixa timezone - Event start time - Event end time Pay particular attention to events that cross daylight-saving boundaries or were created using custom timezone settings. ## Fixing a Timezone Warning If the migrated event is otherwise correct: 1. Open the Eventixa event. 2. Set the correct timezone. 3. Verify the event start and end time. 4. Save the event. 5. Check the frontend event date and time. If you want to rerun the source migration after fixing the source timezone, use **Re-import Event**. ## Recurring Event Requires Pro If a recurring source event shows **Requires Pro**, Eventixa Pro is not providing the recurrence migration capability required by the source event. Activate Eventixa Pro and retry the event. ## Recurring Event Is Unsupported A recurring event can be marked **Unsupported** when its recurrence rule cannot be represented safely by Eventixa. Examples can include: - Certain positional monthly rules - Complex yearly recurrence - Multiple-month yearly structures - Complex recurrence exclusions - Per-occurrence timing differences - Unsupported standalone TEC Series structures Eventixa does not guess or simplify these rules silently. ## What to Do with an Unsupported Recurrence You have two practical options: 1. Recreate the recurrence manually in Eventixa using a supported schedule. 2. Convert the event into a supported recurrence structure in the source and then re-import it. After manual recreation, compare the generated Eventixa occurrence dates with the original source schedule. ## Occurrence Mismatch For recurring migrations, Eventixa can validate the generated occurrence dates against the source. If the destination occurrence set does not match the expected source dates, the migration reports an occurrence mismatch. ## Why Occurrence Mismatch Happens Possible causes include: - Different interval behavior - Weekday mapping differences - Excluded dates - Additional occurrence dates - Recurrence end boundary - Unsupported positional recurrence - Different occurrence timing ## Fixing an Occurrence Mismatch Compare: - Recurrence frequency - Interval - Selected weekdays - Start date - End date - Exclusions - Additional dates - Generated destination occurrences If the Eventixa recurrence model cannot represent the source exactly, recreate the destination schedule manually instead of repeatedly retrying the same unsupported rule. ## Standalone TEC Series Is Unsupported The Events Calendar can use a Series relationship independently from actual recurrence rules. A manually grouped TEC Series does not automatically represent a recurring event. If Eventixa has no equivalent destination structure, the migration can report the Series as unsupported. This prevents Eventixa from incorrectly turning a grouping relationship into recurrence. ## Attendee Field Warning A source attendee field can generate a warning if Eventixa cannot represent its field type safely. Eventixa may still migrate the event and other supported attendee fields. ## What to Check for an Attendee Field Warning Review: - Field label - Field type - Required state - Available options - Whether the destination requires Eventixa Pro - Whether the field has an Eventixa equivalent ## Unsupported Advanced Field Some advanced source fields require Eventixa Pro or may have no direct Eventixa equivalent. When the field cannot be mapped, Eventixa can skip that individual field and report a warning rather than failing the whole event unnecessarily. ## Fixing an Attendee Field Warning Open the migrated Eventixa event and recreate the missing field manually using the closest supported Eventixa attendee-field type. Then test the registration workflow. ## Venue Warning A venue warning can occur when source venue data is incomplete or cannot be mapped exactly. Review: - Venue name - Address - City - State - Country - Postal code - Phone - Website Confirm the migrated Eventixa venue contains the information required by your frontend. ## Organizer Warning If a source event contains multiple organizers or organizer information that cannot be represented exactly by the destination event structure, Eventixa may report a warning. Review the migrated organizers and confirm the correct organizer relationships. ## Ticket Warning Ticket migration warnings can involve: - Source ticket mapping - Capacity - Availability - Sale schedule - Ticket type - SKU - Historical ticket relationship Open the migrated event and compare the ticket configuration with the source. ## Ticket Reconciliation Warning Eventixa performs reconciliation between source and destination tickets. A reconciliation warning means the ticket record may exist but an important source/destination value or relationship does not match as expected. Do not ignore ticket reconciliation warnings on events that are already accepting registrations. ## What to Check for Ticket Reconciliation Compare: - Ticket name - Ticket type - Price - Capacity - Sale start - Sale end - Source ticket relationship - Event relationship ## Booking Migration Warning Historical booking migration is optional. When enabled, a booking warning can indicate that the historical source record could not be mapped or reconciled fully. ## Historical Booking Relationships A migrated booking must resolve correctly to: - Event - Ticket - Customer or registration - Source order or registration If one of these relationships is missing, the booking should not be assumed correct simply because a destination record exists. ## Booking Status Mismatch Eventixa can reconcile historical booking status against the source. If the source and destination statuses do not match as expected, the migration can report a reconciliation problem. ## Payment Status Mismatch Historical payment status can also be validated. Review the source order and Eventixa booking if the migration reports a payment-status discrepancy. ## Historical Total Mismatch When supported source financial values are available, Eventixa can compare migrated financial snapshots. A mismatch can involve: - Subtotal - Discount - Tax - Total - Currency Historical migration does not recharge the customer; these values are for record preservation and reconciliation. ## Currency Mismatch If Eventixa reports a currency mismatch, compare the source order currency with the migrated Eventixa booking snapshot. Do not manually assume the current site currency represents every historical transaction. ## Historical Ticket Quantity Mismatch The migration can compare source ticket quantities with the migrated booking. A mismatch should be reviewed before relying on historical attendance or reporting totals. ## Historical Attendee Missing Historical attendee migration requires: **Attendees & responses** to be enabled. If that option was not selected, missing historical attendees are expected. ## Attendee Migration Also Requires Bookings Every Eventixa attendee requires a booking relationship. For this reason, enabling historical attendee migration also includes booking migration. ## Attendee Cannot Resolve Booking An attendee can fail to migrate when Eventixa cannot establish the required booking relationship. Review whether the corresponding historical booking migrated successfully first. ## Attendee Cannot Resolve Ticket Historical attendees also need the correct migrated ticket relationship. If the source ticket was unsupported, missing, or failed reconciliation, the attendee may not be safely migratable. ## RSVP Response Warning Historical RSVP data can depend on: - Correct event mapping - Correct ticket mapping - Booking relationship - Source attendee response If one of these relationships cannot be resolved, Eventixa can report a warning or failure instead of silently assigning an incorrect RSVP response. ## Historical Check-In Missing Historical check-in migration is optional. Confirm that **Historical check-in state** was enabled in Migration Scope. It also requires the supported Eventixa Pro destination capability. ## Check-In Requires Attendee and Booking Data Historical check-in cannot exist independently. Eventixa needs: - Booking - Attendee - Event relationship for the check-in state to be meaningful. ## Historical Check-In Does Not Trigger Live Actions Imported check-in state does not perform a new attendee check-in. If you expected a live check-in email, webhook, or other action to run during migration, that does not happen by design. ## Virtual Event Warning Virtual-event migration can report warnings when source provider information cannot be adopted directly. This is especially important for managed Zoom or Google Meet data. ## Why a Managed Provider May Not Be Adopted An existing remote meeting belongs to a particular provider account and authorization relationship. Eventixa should not claim management of that remote meeting unless it can safely establish the relationship. ## Custom URL Fallback If Eventixa cannot safely adopt a managed Zoom or Google Meet meeting but a usable attendee-facing URL exists, migration can preserve access using **Custom URL**. This is a fallback, not necessarily an error. ## Meeting URL Missing If the source provider cannot supply a usable attendee meeting URL or meeting identifier, Eventixa may be unable to preserve virtual access automatically. Review the migration details and configure the virtual event manually if necessary. ## Source Event Not Found A migration can fail if the source event was deleted or changed after Eventixa initially fetched the event list. Click **Fetch Events** again and confirm that the source record still exists. ## Destination Event Missing If a previously migrated Eventixa event was deleted, its old mapping may still be known to the migration system. Eventixa can detect that the destination record no longer exists and allow the source event to be migrated again. ## Event Already Migrated An already migrated event does not necessarily need a brand-new destination record. Use **Re-import Event** when you intentionally want to process the source again. Eventixa uses source-to-destination mappings to avoid blind duplication. ## Retry Event vs Re-import Event Use **Retry Event** when a migration attempt failed or encountered a problem that may now be resolved. Use **Re-import Event** when an event was already migrated and you intentionally want Eventixa to process the source again. ## Retry Failed If several events in a migration run failed, use: **Retry Failed** from the Migration progress area. This retries the failed events without requiring successful events to be processed again. ## Migration Is Stuck or Appears Incomplete Eventixa uses persistent migration progress. If the page was closed or the browser session ended, return to: **Eventixa → Migration** and check whether the existing run can be resumed. ## Pause and Resume A migration run can be paused and resumed. If the migration is paused, use **Resume Migration** rather than starting another run unnecessarily. ## Closing the Browser Did Not Cancel the Migration This is expected. The migration run persists independently of the current Migration page view. Return to the page to inspect its current status. ## Failed Events Do Not Mean the Entire Run Failed A migration run can contain a mixture of: - Migrated events - Events with warnings - Failed events Review and retry only the affected items where appropriate. ## Source Plugin Is Not Detected If The Events Calendar shows **Not detected**, confirm that the supported source plugin is installed and active. The source migration controls remain unavailable when Eventixa cannot detect the required source. ## Fetch Events Is Disabled Possible reasons include: - Source plugin not detected - Migration adapter unavailable - Required source component not active Confirm The Events Calendar is active and reload the Migration screen. ## No Events Found If Fetch Events succeeds but no events appear, check: - Whether source events actually exist - Search field - Source-status filter - Event-type filter - Whether you are viewing a later loaded page Clear filters and fetch again if necessary. ## Search Hides the Event The event browser search filters source events by title. Clear the search field when troubleshooting an apparently missing event. ## Status Filter Hides the Event An event can be Draft, Pending, Private, or Scheduled rather than Published. Use **All Status** when troubleshooting missing source events. ## Event Type Filter Hides the Event If **Single Events** or **Recurring Events** is selected, the opposite type will not appear. Use **All Types** to confirm whether the source event is present. ## Migration Button Is Disabled **Migrate Selected Events** requires at least one eligible source event to be selected. Confirm the event checkbox is selected and that the source event is not blocked by its current migration state. ## Event Has Requires Pro Status Activate the required Eventixa Pro functionality before retrying. Do not expect retry alone to resolve a missing destination capability. ## Repeated Retry Produces the Same Unsupported Error Retry is intended for problems that can change. If Eventixa consistently reports that a source structure is **Unsupported**, repeated retries will not make the source rule compatible. Modify the source structure or recreate that part manually in Eventixa. ## Migration Warning After Re-import Re-importing does not automatically remove a warning if the underlying source data is unchanged. Fix the source or manually correct the destination depending on the warning. ## Migration Report Click **View Report** after a migration run. The report helps you review: - Migrated events - Warning counts - Failed events - Individual migration outcomes - Reconciliation results Use the report as part of final migration verification. ## What to Verify Before Removing the Source Plugin Do not use the number of successful migration badges as your only verification. Check the actual migrated data. For every important event, verify: - Event title - Dates and times - Timezone - Venue - Organizers - Categories - Tickets - Registration fields - Recurrence - Virtual-event access - Historical bookings if migrated - Historical attendees if migrated - Historical check-in if migrated ## Troubleshooting Workflow Use this order when a migration issue appears: 1. Open **Details**. 2. Identify whether the result is Warning, Failed, Requires Pro, or Unsupported. 3. Confirm the source event still exists. 4. Verify the required Eventixa capability is active. 5. Compare source and destination data. 6. Fix the source or destination configuration where applicable. 7. Use **Retry Event** for a failed attempt. 8. Use **Re-import Event** when intentionally processing an already migrated event again. 9. Review the Migration Report. 10. Manually verify the destination event. ## When to Retry Retry when the problem was temporary or has been corrected. Examples include: - Required Pro capability was activated - Temporary migration error was resolved - Source dependency was restored - Environment issue was corrected ## When to Re-import Re-import when the source or migration configuration has intentionally changed after a previous migration. Examples include: - Corrected source timezone - Updated source ticket configuration - Corrected attendee fields - Source virtual-event information changed - Previous Eventixa destination event was deleted ## When to Fix Manually Manual correction is appropriate when the source structure has no safe automatic Eventixa equivalent. Examples include: - Unsupported recurrence pattern - Unsupported standalone Series relationship - Unsupported advanced field type - Virtual configuration that cannot be adopted safely ## Avoid Repeated Blind Retries Before repeatedly clicking Retry, read the event details. A deterministic unsupported structure will continue producing the same result. Use retry for fixable failures, not for unsupported source models. ## Recommended Migration Verification Checklist Before completing a migration project: 1. Resolve all Failed events. 2. Review every Migrated with Warnings event. 3. Review every Requires Pro item. 4. Review Unsupported items. 5. Verify recurring occurrence dates. 6. Verify ticket configuration. 7. Test a frontend booking. 8. Test RSVP where used. 9. Verify attendee fields. 10. Verify virtual-event access. 11. Compare historical booking totals if migrated. 12. Compare attendee counts. 13. Verify check-in state. 14. Review the Migration Report. 15. Keep a backup before removing the source plugin. ## Common Questions ### Does Migrated with Warnings Mean the Migration Failed? No. The main event may have migrated successfully, but one or more details require review. ### Should I Ignore Warnings if the Event Opens Correctly? No. Open **Details** and identify the warning before considering the migration complete. ### Can I Retry a Failed Event? Yes. Use **Retry Event** or **Retry Failed** after resolving the underlying issue. ### Can I Retry an Unsupported Event? You can attempt processing again after changing the source structure, but retrying the same unsupported configuration will not make it compatible. ### Why Does My Recurring Event Require Pro? Recurring-event migration depends on Eventixa Pro. ### Why Was My Recurrence Marked Unsupported? The source recurrence structure could not be represented safely by the Eventixa recurrence model. ### Why Did My Zoom or Google Meet Event Become Custom URL? Eventixa could not safely adopt management of the existing remote provider relationship, so it preserved usable access through Custom URL when possible. ### Why Are Historical Attendees Missing? Make sure **Attendees & responses** was enabled. ### Why Are Historical Bookings Missing? Make sure **Bookings & orders** was enabled. ### Why Is Historical Check-In Missing? Make sure **Historical check-in state** was selected and Eventixa Pro provides the required capability. ### Why Didn't Migration Trigger Check-In Emails? Historical check-in import restores state and does not trigger live check-in actions. ### Can I Re-import an Event? Yes. Use **Re-import Event** when you intentionally want Eventixa to process a previously migrated source event again. ### Can I Migrate Again After Deleting the Eventixa Event? Yes. Eventixa can detect that the previous destination record no longer exists and allow the source event to be processed again. ### Will Re-import Create Duplicates? Eventixa uses source-to-destination mappings rather than blindly creating unrelated records. Always verify the destination after reimport. ### Should I Deactivate The Events Calendar After the Migration Finishes? Only after important migrated events, tickets, recurrence, virtual access, and historical records have been verified. ## Important Notes - **Migrated with Warnings** is not the same as Failed. - **Failed** usually indicates a migration process that did not complete. - **Requires Pro** indicates a missing destination capability. - **Unsupported** means the source structure cannot currently be represented safely. - Always use **Details** to understand the specific migration result. - Retry failed items after fixing the underlying cause. - Use Re-import when intentionally processing an already migrated source event again. - Eventixa validates recurring occurrence dates rather than assuming recurrence settings are correct. - Historical attendee migration requires booking relationships. - Historical check-in requires attendee and booking relationships. - Virtual provider fallback to Custom URL can be expected when managed provider ownership cannot be safely adopted. - Do not remove the source plugin until migration warnings and failures have been reviewed and destination workflows have been tested. ## Related Documentation - [Migration Overview](https://eventixawp.com/docs/migration-overview/) - [Migration from The Events Calendar](https://eventixawp.com/docs/migration-from-the-events-calendar/) - [Supported Migration Data](https://eventixawp.com/docs/supported-migration-data/) - [Recurring Event Migration](https://eventixawp.com/docs/recurring-event-migration/) - [Recurring Events Overview](https://eventixawp.com/docs/recurring-events-overview/) - [Attendee Registration Fields](https://eventixawp.com/docs/attendee-registration-fields/) - [In-Person, Virtual & Hybrid Events](https://eventixawp.com/docs/in-person-virtual-hybrid-events/) - [Zoom Integration](https://eventixawp.com/docs/zoom-integration/) - [Google Meet Integration](https://eventixawp.com/docs/google-meet-integration/)