Migrate from Neoforce to Zendesk

Neoforce Tickets map directly to Zendesk Tickets with standard field mapping (status, priority, category, assignee) and all custom fields preserved. We extract the ticket's created_at and updated_at timestamps and set them in Zendesk using the Tickets API, preserving the historical timeline. Comments, internal notes, and attachments migrate as Ticket Comments. The Neoforce ticket ID is preserved in a custom field neoforce_ticket_id__c for cross-reference.

Neoforce Light Accounts (free end-customer portal accounts) map to Zendesk End Users. Light Accounts may lack an email address in some export scenarios, so we apply an email-placeholder strategy during scoping: records without an email receive a placeholder in the format placeholder_neoforce_{id}@placeholder.local so that the End User record is valid in Zendesk and can be enriched later. The customer's admin reviews these placeholders post-migration and replaces them with real email addresses or merges with existing End User records.

Neoforce Company records map directly to Zendesk Organization. The Company name becomes the Organization name, address fields map to Zendesk address fields, and custom fields on Company migrate as Organization custom fields. We use Organization name as the dedupe key during import to prevent duplicate Organizations from being created.

Neoforce Agent accounts (full user accounts with roles and permissions) map to Zendesk Agents. Role names and permission levels are preserved as custom properties on the Zendesk User record so the customer's admin can reconfigure matching Zendesk roles (Agent, Admin) post-migration. We match by email address.

Neoforce SLA configurations (response-time targets, resolution-time targets, and escalation thresholds) are stored as configuration objects that cannot be exported as transferable data. We extract and document every SLA tier with its name, response time in hours, resolution time in hours, and applicable business hours calendar. The customer uses this documentation to configure Zendesk SLA Policies in Admin > Business Rules > SLA Policies post-migration. Escalation chain logic tied to specific agent groups requires manual reconstruction in Zendesk.

Neoforce Asset records map to a Zendesk Custom Object named Asset. We pre-create the Custom Object schema in Zendesk (Professional and above) including all custom fields, then import asset records via the Custom Objects API. Assets linked to Organizations retain the relationship through a lookup field. Asset status, type, serial number, and custom fields migrate as typed fields.

Neoforce Contract records map to a Zendesk Custom Object named Contract. Contract terms, renewal dates, and custom fields migrate as custom fields on the Contract object. Renewal date semantics vary between platforms, so we flag date-format handling during scoping. Contracts linked to Assets and Organizations retain their relationship through lookup fields that we resolve at migration time.

Neoforce custom fields on Tickets (text, number, dropdown, multi-select, checkbox, date) map to Zendesk custom ticket fields of equivalent type. We export the field schema (name, type, required flag, picklist options) alongside the field values so the destination receives both the field definition and the data. Multi-select and checkbox fields in Neoforce generate tags in Zendesk automations, which we flag during scoping.

Neoforce wiki article content and metadata (as of v26.02) can be exported via the API. We extract article title, body content, author, publication status, and associated category or section. Articles migrate as Zendesk Help Center articles in the appropriate Section and Category. Inline images and attachments in articles migrate as article attachments. The customer's admin activates Zendesk Guide before migration if not already enabled.

Tags applied to Tickets, Assets, and Companies in Neoforce export as a flat tag array per record. We preserve the tag vocabulary across all objects and import tags to Zendesk, where they can be used in triggers, automations, views, and reporting. Tag-to-field mapping (if the customer used tags as a structured classification) is documented separately for the admin to convert to Zendesk custom fields or topics.

Neoforce workflow definitions (triggers, conditions, branching logic, and downstream actions) are stored in a proprietary format not accessible via the public API. There is no bulk-export endpoint for automation definitions. We do not migrate workflow definitions as code. We run a discovery sprint that produces a Workflow Inventory Document listing every active Neoforce workflow with its trigger event, conditions, and actions, giving the customer a complete blueprint to reconstruct each one in Zendesk's trigger and automation builder.