Migrate from Neoforce to Gorgias

Neoforce Tickets migrate to Gorgias Tickets with full thread history preserved as message records, attachments mapped to Gorgias attachment handling, and custom fields exported as typed Gorgias custom fields. We resolve the assignee by matching Neoforce Agent email to the Gorgias User email on creation. Neoforce ticket priority and status values map to Gorgias Ticket Status; category maps to Ticket Tags. Internal notes migrate as private Gorgias messages with the note flag preserved.

Neoforce Light Account records migrate to Gorgias Customer. This is the highest-risk mapping in the pair: Light Accounts in Neoforce may lack an email address in some export scenarios (they are free portal accounts with limited field coverage). We flag every Light Account without an email during scoping and apply an email-placeholder or contact-enrichment strategy — typically sourcing the email from the linked Ticket history if the customer submitted a ticket before creating the portal account — to prevent orphaned Customer records with no contact details.

Neoforce Company records (with address, custom fields, and links to Customers and Tickets) merge into Gorgias Customer records as organisation-level attributes. Multiple Neoforce Company records linked to the same domain or entity merge into a single Gorgias Customer with an organisation name. If a Neoforce Customer is linked to multiple Companies, we attach the primary Company as the organisation on the Gorgias Customer and store secondary company associations as custom fields.

Neoforce Agent accounts (with roles, permissions, and active/inactive status) migrate to Gorgias Users. Role names and permission levels are preserved as custom properties on the Gorgias User record so the customer can reconfigure Gorgias role-based access control post-migration. We match by email as the unique identifier. Inactive Neoforce agents migrate as inactive Gorgias users pending the customer's decision on whether to reactivate them.

Neoforce Asset records (hardware and software with custom fields, linked Contracts, and Company relationships) have no direct Gorgias equivalent because Gorgias lacks a native asset management module. We export all asset records and store them as structured JSON alongside the migrated Customer record, and the migration workbook includes a Gorgias custom fields configuration guide that the customer's admin uses to create asset-context fields (asset type, serial number, warranty expiry) on the Customer or Ticket object in Gorgias.

Neoforce Contract records (terms, renewal dates, linked Assets and Companies) merge into the Gorgias Customer record as a Contract section with renewal date, contract type, and terms stored as custom fields. We preserve the renewal date as a custom date field and flag upcoming renewals for the customer's CS team to manage in Gorgias. Multi-asset contracts are stored as structured JSON in a custom field since Gorgias does not support nested contract-to-asset relationships natively.

Neoforce SLA configurations (response-time targets, resolution-time targets, and escalation chain rules) are configuration objects, not ticket attributes, and cannot be transferred directly to Gorgias. We export all SLA tier definitions with their response and resolution time thresholds and deliver them as a structured SLA workbook listing every SLA policy, its linked ticket categories, and its escalation timings. The customer configures matching SLA policies in Gorgias using the exported numbers as the authoritative source.

Neoforce wiki articles (as of v26.02, exportable to PDF natively; API extraction available for structured content) migrate to Gorgias Help Center articles. We extract article content and metadata via the Neoforce API, convert HTML formatting to Gorgias-compatible markdown, and preserve article category structure as Gorgias Help Center categories. Links within wiki articles that reference other wiki pages are flagged for manual update post-migration since URL paths will change in Gorgias.

Neoforce custom fields on Tickets (name, type, required flag, picklist options) migrate to Gorgias custom ticket fields. We export the field schema alongside the field values so the destination receives both the structure and the data. Picklist options from Neoforce custom fields map to Gorgias multiple-choice custom field options. Required flags are noted in the migration workbook; Gorgias requires manual setting of required status post-migration.

Tags applied to Tickets, Assets, and Companies in Neoforce export as a flat tag vocabulary. We preserve the full tag array per record so that the destination can reconstruct filtering, segmentation, and reporting logic from the Neoforce tag set. Tags that were applied across multiple object types (Ticket and Asset) remain as separate tag sets in Gorgias since Gorgias tags are scoped to the Ticket object.

Neoforce workflow definitions (triggers, conditions, branching logic, and downstream actions) are stored in a proprietary format that is not accessible via the public API. We do not migrate workflows as code. We run a discovery sprint that produces a Workflow Inventory Document listing every active workflow with its trigger source, conditions, actions, and recommended Gorgias Rule equivalent. The customer uses this document to rebuild each automation in Gorgias Rule Builder. This inventory is delivered before cutover so rebuilding can begin in parallel with the data migration.

Neoforce dashboard widget layouts, chart configurations, and user-specific preferences are UI-level objects not accessible via the standard API. The underlying data feeding those dashboards (tickets, assets, metrics) migrates in full. We flag dashboard layouts as a post-migration configuration step and include a data export of all dashboard metrics so the customer can reconstruct charts manually in Gorgias analytics.