Migrate from Ivinex to Gorgias

Ivinex Contact records map to Gorgias Customer objects. The email address is the primary dedupe key. We call GetFields on the Contacts Tab before pulling records to capture all custom field labels and types, then map each to a Gorgias Customer custom field via external_id. Standard fields (name, email, phone, address) migrate directly. Owner assignment resolves by email match to the Gorgias User table.

Ivinex Organizations are linked to Contacts via LinkRecords. We flatten organization fields onto the related Customer record in Gorgias rather than creating a separate object, since Gorgias does not have a standalone Organization/Account object separate from Customer. The company name and domain map to Customer attributes; the relationship chain is preserved in a migration notes file for manual reconstruction if the customer needs separate company-level reporting.

Ivinex Ticket records map directly to Gorgias Ticket. The ticket status, priority, assignee, and description fields map to their Gorgias equivalents. Custom fields on the Ivinex Tickets Tab are enumerated via GetFields and mapped to Gorgias Ticket custom fields using external_id. We resolve the assignee to a Gorgias User by email match. The Ivinex ticket created_date and modified_date become Gorgias created_datetime and updated_datetime.

Ivinex Activities attached to a Ticket (call logs, emails, notes, tasks) map to Gorgias Ticket message records. We retrieve all GetAllRelatedItems for each Ticket before inserting, then write them as a chronological sequence of comments on the destination Ticket. Call duration and disposition from Ivinex become custom message metadata fields. The activity timestamp preserves the original date for timeline ordering.

Standalone Ivinex Task records are evaluated during scoping. If tasks correspond to follow-up work on an existing ticket, they migrate as comments on that Ticket. If tasks are independent work items without a parent ticket, they are documented as a rebuild scope in Gorgias Rules or a separate task management tool, since Gorgias does not have a standalone Task object separate from Ticket workflow.

Ivinex User records (name, email, role, active/inactive status) map to Gorgias User. We match by email address. Inactive Ivinex users who own records are mapped to an inactive Gorgias User stub so that ownership history is preserved. Active users must have a corresponding Gorgias User provisioned before Ticket import begins, since assignee resolution is required.

Ivinex Groups control API permissions and record access. We export group membership as a JSON artifact documenting which Ivinex users belong to which groups. Gorgias Teams are the equivalent organizational unit for agent grouping. The customer's admin rebuilds team membership in Gorgias Settings post-migration based on this artifact.

Ivinex stores attachment metadata with download URLs in GetRecords responses, but binary content requires a separate download pass. We extract all attachment URLs during the data pull, execute parallel downloads in a second pass, and re-upload files to Gorgias via the /api/upload endpoint. Files over 20 MB exceed Gorgias Help Center limits but are accepted on Ticket records. Large file volumes should be migrated in a dedicated post-ETL file transfer step to avoid extending the main migration window.

Every Ivinex Tab has a unique set of custom fields not documented in a global schema. We call GetFields on every Tab during the pre-migration schema audit, capture field type, label, and dropdown options, then pre-create matching Gorgias Custom Fields with external_id set to the Ivinex field identifier. Field type handling: Ivinex text, number, date, and checkbox types map to Gorgias text, decimal, date, and boolean respectively. Ivinex dropdown fields map to Gorgias options custom fields. Ivinex user-link fields are documented for manual reconstruction as Gorgias User lookup fields if needed.

Ivinex Workflows are automation rules defined in the process automation module. We export workflow configuration as structured JSON documenting trigger conditions, action steps, and branching logic. Gorgias Rules are condition-action pairs that operate on tickets and messages but do not share the same data model or UI as Ivinex workflows. Workflows are not migrated as executable code; we deliver a written inventory with a recommended Gorgias Rules equivalent so the customer's admin can rebuild them post-migration.

Ivinex Saved Views define field visibility and filter criteria per Tab. These are user preference data, not customer data. We export view names, filter criteria, and sort order as a JSON artifact. Gorgias Views are defined by channel, status, assignee, and tag combinations and do not share the same field-level filtering model. Views are documented as a rebuild guide rather than migrated as data.

Ivinex Change History captures field-level audit trails per record. Full history export is scoped to the records being migrated. Gorgias Ticket events capture status changes and assignee changes but not field-level history for all custom field modifications. We migrate the most recent status and assignee changes as Ticket events; a complete audit log requires a custom integration and is outside standard migration scope.