Migrate your Neoforce data

Tickets are Neoforce's core helpdesk object. They have standard fields (status, priority, category, assignee) and support custom fields per ticket. We export Tickets with their full custom-field payload, conversation threads, and internal notes as structured JSON. Status and priority enums are mapped to destination equivalents via a configurable lookup table.

Neoforce distinguishes full Agent accounts from free Light Accounts used by end customers accessing the portal. Light Accounts lack an email-contact equivalent in some exports. We flag all Light Account records during scoping and map them to Contacts or Users in the destination depending on whether portal access is needed post-migration.

Company records are a top-level object linking multiple Customer and Ticket records. We export Companies with their address, custom fields, and relationship links intact. Where the destination CRM uses Accounts or Organisations as the equivalent object, we apply a standard field mapping.

SLA definitions (response time, resolution time, escalation rules) are stored as configuration objects rather than ticket attributes. These require reconstruction on the destination platform because escalation chain logic does not export as portable data. We document the current SLA schedule so the customer's new platform can be configured to match.

Neoforce's asset management module stores hardware and software assets with a flexible data structure. We export all asset records including custom fields, linked contracts, and relationship to Companies and Tickets. The flexible schema means we preserve all custom properties as-is and apply destination-specific field typing on import.

Contract records link to Assets and Companies and store terms, renewal dates, and custom fields. Renewal date semantics and contract-type categorisations vary between Neoforce and destination systems, so we map contract types via a value-lookup table and flag any contracts without linked assets for manual review.

Neoforce workflow definitions (triggers, conditions, actions) are stored in a proprietary format that is not exportable via API. We cannot migrate automation rules directly. We document the full workflow inventory during discovery so the customer can rebuild them in the destination platform with FlitStack AI's workflow-mapping workshop as a guided reference.

As of v26.02, wiki articles within the customer portal can be exported to PDF natively. For migration scoping, we extract wiki article content and metadata via the API where available, handling the PDF export as a fallback binary. Article-to-category relationships are preserved as tag assignments on the destination KB.

Neoforce supports custom fields on Tickets. We export the custom field schema (name, type, required flag, picklist options) alongside the field values so the destination system receives both the field definition and all populated values in one pass.

Neoforce dashboards store chart and widget configurations per user. The dashboard definition itself is not a portable API object; however, the underlying ticket and asset data feeding those dashboards is fully migrated. We advise customers that dashboard layouts must be rebuilt manually on the destination platform.

Agent accounts with roles and permissions are migrated as User records. Role names and permission levels are preserved as custom properties on the destination User object so the customer can reconfigure RBAC to match their desired access model post-migration.

Tags applied to Tickets, Assets, and Companies are exported as a flat tag array per record. We preserve the tag vocabulary across all objects so the destination can reconstruct filtering and segmentation logic without losing any applied labels.