Migrate from Neoforce to Zoho Desk

Neoforce Tickets map directly to Zoho Desk Tickets. Standard fields (status, priority, category, assignee) map to Zoho Desk's Status, Priority, Category, and Assignee fields. Custom ticket fields migrate as typed Zoho Desk custom fields (text, picklist, number, date, or multi-select) created during the pre-migration schema design phase. Ticket thread history migrates as Thread records preserving the original timestamp, direction (incoming/outgoing), and author type. Any inline images in ticket descriptions or comments are flagged as non-migratable per Zoho Desk's import constraints and noted in the migration workbook for manual re-insertion post-migration.

Neoforce Company records map to Zoho Desk Account. The Company name becomes Account Name, address fields map to the standard Account address compound, and custom fields on Company migrate to Zoho Desk custom fields on Account. Company-to-Customer (Light Account) relationships are preserved as Account-to-Contact lookups in Zoho Desk. We use Company record ID as the external ID for deduplication during import.

Neoforce Light Accounts are end-customer portal accounts that may lack an email address or full contact details in some export scenarios. We flag every Light Account record during scoping, confirm which ones require full contact migration, and apply either a configured email placeholder strategy or a contact-enrichment pass before importing into Zoho Desk as Contacts. Light Accounts without any usable identifier are documented in a reconciliation queue for the customer to resolve before final import. Zoho Desk requires a Contact to have either a name or an email; records missing both cannot be imported and are flagged explicitly.

Neoforce Agent accounts map to Zoho Desk Agents. We extract the agent's name, email, and role designation from Neoforce and create Zoho Desk agent profiles with matching department assignments. Neoforce role names and permission levels are preserved as custom properties on the Zoho Desk agent record so the customer's admin can remap them to Zoho Desk's role and profile system. Agent accounts with no email address in Neoforce are flagged for manual email assignment before migration.

Neoforce Assets with product-like characteristics (tracked hardware, software licenses, configurable items) map to Zoho Desk Products if the customer wants to manage them as serviceable products linked to tickets. Assets that represent non-product infrastructure (building equipment, facility items) map to a custom Asset record type in Zoho Desk using a custom object or custom fields on Account. Asset-to-Company relationships are preserved as Account links or custom lookup fields depending on the Zoho Desk edition in use.

Neoforce Contract records link to Assets and Companies and store terms, renewal dates, and custom fields. Contract terms and renewal dates migrate to Zoho Desk as custom fields on Account (for account-level service agreements) or on Product (for product warranty and SLA contracts). Renewal date semantics and contract-type categorisations vary between Neoforce and Zoho Desk, so we document the source contract structure in the migration workbook and the customer configures the target field schema during the schema design phase.

Neoforce SLA definitions (response time targets, resolution time targets, escalation thresholds, and chain-of-escalation rules) are stored as configuration objects that cannot be transferred as data. We export the SLA tier definitions with their numeric targets, calendar associations, and escalation rule descriptions and deliver them as a structured SLA Configuration Document in the migration workbook. The customer's Zoho Desk admin uses this document to configure matching SLA policies in Zoho Desk's SLA engine, which supports calendar-based response and resolution SLAs, escalation rules, and notification templates. The migration itself carries only the documentation, not the configured SLA engine data.

Neoforce wiki article content and metadata migrate to Zoho Desk Knowledge Base articles. Article title, body text, category, and publication status transfer as standard fields. Knowledge Base attachments (PDFs, images embedded within articles) do not migrate per Zoho Desk's import constraints, which explicitly exclude Knowledge Base attachments. We flag every article with attachments and deliver a list of the original attachment filenames and storage locations in Neoforce so the customer can re-attach them manually or store them in Zoho Desk's document management post-migration. Article creation dates are not preserved as Zoho Desk imports use the import timestamp for article dates.

Tags applied to Tickets, Assets, and Companies in Neoforce migrate as Zoho Desk Tags. Tags are stored as a flat tag array per record in Neoforce and are mapped to Zoho Desk's tag field on the corresponding Ticket, Account, or Product. Zoho Desk's tag vocabulary is preserved across all objects so the customer can reconstruct filtering and segmentation post-migration.

Neoforce custom fields on Tickets (text, number, date, picklist, multi-select, checkbox) map to equivalent Zoho Desk custom field types. The custom field schema (name, type, required flag, picklist options) is exported during scoping and pre-created in Zoho Desk before any ticket data is loaded. Custom field values migrate as typed values against the pre-created field definitions. Any Neoforce custom field types that do not have a direct Zoho Desk equivalent (e.g., highly specific Neoforce field types) are documented as requiring either a custom field workaround or a post-migration data entry process.

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 cannot migrate automation rules as data. We run a discovery sprint that produces a Workflow Inventory Document listing every active workflow with its trigger type, conditions, actions, and a recommended Zoho Desk Blueprint or workflow rule equivalent. The customer's admin or a Zoho implementation partner uses this document to reconstruct each automation in Zoho Desk's Blueprint editor post-migration.

Neoforce dashboards store widget layouts, chart configurations, and user-specific preferences as UI-level objects that are not accessible via the standard API. The underlying ticket and asset data feeding those dashboards is fully migrated to Zoho Desk. Dashboard layouts themselves are not migratable and must be manually recreated in Zoho Desk's reporting module. We flag this as a post-migration configuration step and confirm in writing that the data migration itself is complete so there is no ambiguity about what was and was not transferred.