Migrate from Vivantio to Gorgias

Vivantio Tickets (Incident, Problem, Change, Service Request, and unlimited custom types) map to a single Gorgias Ticket object. Each Vivantio ticket type is preserved as a tag or ticket attribute in Gorgias so the original categorization is queryable. Ticket status, priority, and assignment migrate directly. We map Vivantio's category hierarchy to Gorgias tags for filtering equivalence. Note that Gorgias does not have separate record types for Incident, Problem, or Change as Vivantio does; the semantic difference is reconstructed via tag and channel metadata.

Vivantio Organisations map to Gorgias Customers with the organisation flag set. The Organisation name becomes the customer name, and the primary contact links to a Customer (person) record. We preserve Organisation contact links and address data. Organisation is created before any Contact or Ticket import so that lookups resolve at insert time.

Vivantio Contacts and Callers map to Gorgias Customer records (person type). We canonicalise the Vivantio terminology (Contact, Caller, Client all become Customer in Gorgias) and preserve all contact fields including email, phone, language, and timezone. External ID from Vivantio is stored as a custom field for cross-system reference.

Vivantio Agents map to Gorgias Users. We resolve agents by email match. Concurrent license holders in Vivantio are flagged during scoping because Gorgias licensing is per-user (no concurrent option); the customer decides whether concurrent users map to individual named accounts or a shared-role account. Teams, Roles, and field-level permissions are mapped to Gorgias permission groups during migration.

Vivantio Teams and Resolver Groups map to Gorgias Teams. Team membership and workload balancing rules are preserved as team-level configuration in Gorgias. We validate that the AD connector instance name from Vivantio (if present) is reproduced exactly in Gorgias to prevent duplicate user creation on first sync.

Vivantio Knowledge Articles (private and public) migrate to Gorgias Knowledge Base Articles. We preserve article body, categories, status, and publication date. Public/private visibility from Vivantio maps to the published/draft state in Gorgias. Article attachments migrate as linked media. Note that Vivantio article versioning does not have a direct Gorgias equivalent; we migrate the most recent version and note the version history as a separate reference document.

Vivantio SLA configurations (priority-based response and resolution windows with business-hour calendars) map to Gorgias SLA policies. This mapping is available on Gorgias Enterprise tier. If the destination is Starter, Basic, or Pro, we document the SLA Policy structure as a configuration checklist for the customer to implement post-migration and flag the gap in the migration report.

Vivantio modern custom fields (non-legacy) map to Gorgias custom fields on the corresponding object (Ticket, Customer, User). Field type mapping includes text, number, boolean, date, and dropdown. Multi-select picklists in Vivantio map to multi-value fields in Gorgias. We pre-create the destination custom field schema before data import.

Legacy custom fields from Vivantio Service Desk cannot be used in Gorgias Business Rules or automation context. During discovery we identify every legacy field, document its current usage, and present remediation options: convert to a modern custom field type, archive the field (migrate data as read-only text), or exclude from migration. We do not import legacy fields as-is because they would break Gorgias automation. This remediation step is a critical path item in the migration schedule.

Files attached to tickets, articles, and contacts are extracted from Vivantio, chunked if the file exceeds Gorgias API upload limits, and re-uploaded with the same parent reference. We preserve inline images in article bodies and ticket conversation threads. Large file batches (over 5 GB total) are processed in batches to avoid API timeout and are validated post-upload with a checksum comparison.

Vivantio Workflows and Business Rules do not migrate as automation code to Gorgias because the trigger-action models differ structurally. We deliver a written inventory of every active Vivantio Workflow with its trigger conditions, routing rules, escalation actions, and SLA timer configuration, mapped to a Gorgias Rule and Macro equivalent. The customer's admin rebuilds the automation in Gorgias Rules using the documented map. This inventory is a standard deliverable and is included in migration scope.

Vivantio Self Service Portal structure (multiple portals per team with Service Catalog and request forms) is documented as a written specification for the Gorgias Help Center and customer-facing portal. Visual branding, CSS customisation, and portal layout do not migrate. We note the Vivantio portal URL structure for redirect planning. Knowledge Articles migrate separately to provide the content foundation for the Help Center.