Migrate from Alloy Navigator to Zoho Desk

Alloy Navigator Tickets map to Zoho Desk Tickets with the classification-driven status value problem handled explicitly. We detect every distinct status value set per Alloy Navigator classification during discovery, build a unified Zoho Desk picklist that covers all variants, and write a status_map transform that normalizes each source value to the correct destination value before insert. Priority, category, and assignee fields map 1:1. The ticket conversation history (emails, notes, internal comments) migrates as Ticket Threads and Comments.

Alloy Navigator Organizations map to Zoho Desk Accounts. The Organization's primary contact link resolves to a Zoho Desk Contact with the AccountId lookup satisfied at import time. We export Organization hierarchy as a flat list with a parent_org_name field; Zoho Desk Accounts do not have native parent-child hierarchy, so the hierarchy is flattened and the root-level parent name is stored in a custom Account field for reporting.

Alloy Navigator Contacts map directly to Zoho Desk Contacts. The email address serves as the dedupe key. We resolve the Contact-to-Account link using the Organization name from the source. Any Contacts without a matching Account are held in a queue for the customer's admin to either create the Account or re-link before the import phase completes.

Alloy Navigator Assets (hardware devices, software licenses, consumables) map to Zoho Desk Assets. The asset_type, serial_number, purchase_date, and warranty_expiry fields map to Zoho Desk standard fields. Custom fields from Alloy Navigator classification-based UDFs migrate as Zoho Desk custom fields scoped to the Asset module. We preserve the asset-assignment relationship by linking to the Contact record for the assigned user.

Alloy Navigator Configuration Items (CIs) model IT infrastructure components and their relationship graph. CIs map to Zoho Desk Asset records with a custom CI-type field indicating the Alloy Navigator class. CI relationships (parent-child dependencies, support relationships) cannot migrate as native graph edges in Zoho Desk because the platform does not have a CI relationship model; we store relationship metadata as a JSON custom field on the primary Asset record for reference.

Alloy Navigator KB articles with formatted text, attachments, and category assignments map to Zoho Desk Knowledge Base articles. Article body migrates as HTML content preserving formatting. Category hierarchies may not map 1:1 because Zoho Desk organizes KB articles by department rather than by a hierarchical category tree; we map Alloy Navigator categories to Zoho Desk Sections within the selected department. Attachments migrate as files linked to the article; file size limit of 10 GB per upload applies per Zoho Desk's migration documentation.

Alloy Navigator's hierarchical Location tree maps to a Zoho Desk custom field on Account and Contact because Zoho Desk does not have a native multi-level location hierarchy. We evaluate tree depth during scoping: shallow trees (under 3 levels) are preserved as parent-child reference custom fields; deep trees are flattened to a pipe-delimited path string stored in a single custom field. The customer chooses the strategy during discovery.

Alloy Navigator Users and Technicians map to Zoho Desk Agents. We extract user records by email as the dedupe key and provision Zoho Desk Agents before any Ticket or Asset import. Active versus inactive status is honored: inactive Alloy Navigator users are provisioned as disabled Zoho Desk Agents. Team assignments from Alloy Navigator do not migrate directly because Zoho Desk Teams must be created manually in the portal; we provide a Teams creation guide and a mapping table to associate each Agent with the correct Team post-provisioning.

Alloy Navigator Contracts linked to Assets and Contacts map to Zoho Desk Contracts. Contract metadata (renewal date, terms, cost) migrates as standard fields. Multi-document contracts with binary file attachments require file handling for the KB attachments path. We note that Zoho Desk Contracts are scoped to the Contracts module and do not have native linking to Assets in the same way Alloy Navigator does; we store the linked Asset name as a custom field on the Contract for reference.

Alloy Navigator Work Orders managing scheduled tasks, assignments, and completion tracking map to Zoho Desk Tasks. The work_order status, scheduled_date, and assignee fields map to Task fields. Custom work-order-specific fields from Alloy Navigator classification schema migrate as Zoho Desk custom fields scoped to the Task module. Work Order attachments migrate as Task Attachments.

Alloy Navigator Software Licenses track compliance, seat counts, and purchase records attached to Assets. We map these to Zoho Desk Products with the license compliance data (seat count, expiration, vendor) stored in custom Product fields. License entitlement calculations from Alloy Navigator's ITAM module are source-system-specific and do not have a direct Zoho Desk equivalent; we preserve the raw data in a custom field for the customer's admin to interpret post-migration.

Alloy Navigator Workflows with Create Actions, approval chains, and escalations do not migrate as code to Zoho Desk. We deliver a written inventory of every active Alloy Navigator Workflow including its trigger conditions, action sequence, and conditional branching logic, with a recommended Zoho Desk Blueprint or Rule equivalent for each. The customer's admin rebuilds the automations post-migration. This approach is honest about the structural incompatibility between Alloy Navigator's workflow engine and Zoho Desk's Blueprint model.