Migrate from Neoforce to Intercom

Neoforce Tickets map to Intercom Conversations. The ticket subject becomes the conversation title, ticket status maps to open/snoozed/closed, priority maps to conversation priority, and the assignee maps to the assigned admin or team. Each Neoforce ticket comment becomes a threaded reply note in Intercom, preserving the full message body and internal note distinction. We use Intercom's REST API to create conversations in order after contacts are established, simulating an inbound message from the customer to satisfy the Messenger-visibility requirement documented in Intercom's migration guide.

Neoforce distinguishes full Agent accounts from free Light Accounts (end customers). Light Accounts may lack email addresses in some export scenarios, which is a known gap. We flag every Light Account with a missing email during scoping, apply a configurable placeholder strategy (a generated email address in a customer-controlled domain or a flag indicating incomplete record), and migrate records that meet the minimum contact requirement (user_id or email) as Intercom Contacts. Those below the minimum migrate as Leads with the incomplete flag so the admin can enrich post-migration.

Neoforce Company records map directly to Intercom Company. The company name, domain, address, and custom fields migrate. We use company domain as the dedupe key during import. If the destination Intercom workspace has existing Company records, we run a domain-match reconciliation to prevent duplicate companies.

Neoforce Agent accounts (paid staff accounts) map to Intercom Admins. Role names and permission levels are preserved as custom properties on the Intercom Admin record so the admin team can reconfigure role-based access post-migration. We resolve agents by email match against the Intercom workspace's admin list.

Neoforce custom fields on Tickets (string, boolean, date, number, picklist, multi-select) migrate to Intercom Custom Data Attributes. We pre-create the attribute schema in Intercom before importing any conversations so that attribute values map correctly on first insert, following the sequence documented in Intercom's migration guide. Picklist values become options in Intercom's custom attribute definition.

Tags applied to Neoforce Tickets, Companies, and Assets are exported as flat tag arrays per record. We preserve the tag vocabulary across all objects and map them to Intercom Tags. Tags used for ticket categorization map directly; the customer decides whether to use tags as filtering segments in Intercom's inbox views.

Neoforce wiki articles (exportable as PDF or via API depending on version) contain knowledge-base content that maps to Intercom Help Center articles. We extract article title, body content, author, and publication status. Articles are imported into Intercom Collections and Sections, following Intercom's knowledge base hierarchy. The article body transfers as HTML; the customer recreates any embedded media references as Intercom-supported assets.

Neoforce Asset records (hardware and software assets with custom fields, linked contracts, and Company relationships) have no native Intercom equivalent. We migrate assets into an Intercom Custom Object named Asset, preserving all custom fields, linked contract references (stored as text or relationship fields), and the relationship to the corresponding Company record. The customer configures asset views and linking logic post-migration.

Neoforce Contract records (terms, renewal dates, custom fields, linked to Assets and Companies) migrate to an Intercom Custom Object named Contract. Renewal date semantics are preserved as date fields; contract-type categorisations map to picklist custom attributes. Links to the Asset Custom Object are stored as text relationship fields. SLA tier information from the contract migrates to a custom field so the customer can configure matching SLA rules in Intercom.

Neoforce SLA definitions (response time, resolution time, escalation thresholds) are stored as configuration objects, not ticket attributes. These do not transfer as data to Intercom because Intercom's SLA rules operate on first-response time and are configured per inbox rather than imported as records. We document the current SLA tiers and timings in the migration workbook so the customer's admin configures equivalent SLA rules in Intercom's SLA policy editor (available at Expert plan). This is a manual reconstruction step, not a data migration.

Neoforce workflow definitions (triggers, conditions, branching logic, and downstream actions) are stored in a format not accessible via the public API and cannot be exported or migrated. We run a discovery sprint that produces a Workflow Inventory Document listing every active Neoforce workflow with its trigger type, conditions, actions, and a recommended Intercom Workflow builder equivalent. The customer's admin rebuilds each workflow in Intercom's Workflows editor (included at Advanced and Expert plans). This is a handoff, not a data transfer.

Neoforce dashboard widget layouts, chart configurations, and user-specific preferences are UI-level objects not accessible via API. The underlying ticket and asset data feeding those dashboards is fully migrated. We flag dashboard recreation as a post-migration configuration step and include a data-export package of all dashboard-source metrics so the customer can rebuild reports and inbox views in Intercom's built-in reporting and Custom Reports builder.