Migrate from Alloy Navigator to Zendesk

Alloy Navigator Tickets map directly to Zendesk Tickets. The primary challenge is status value normalization: Alloy Navigator allows status labels to vary by classification (e.g., Status = 'Open' in one classification may be 'New' or 'Active' in another). We detect all distinct status value sets during discovery and build an explicit mapping table per classification before ticket import. Ticket priority and impact map to Zendesk priority fields. Linked Incidents and Changes migrate as threaded comments on the parent Ticket.

Alloy Navigator Organizations map to Zendesk Organizations. The organization's primary address and contact details map to Zendesk Organization fields. Organization-level custom fields migrate as Organization custom fields. Parent-child Organization hierarchies in Alloy Navigator are preserved as a denormalized parent_organization_name string on the child Organization record since Zendesk does not support Organization hierarchies natively.

Alloy Navigator Contacts map to Zendesk End Users. Email address is the dedupe key. We preserve the contact's organization link (Alloy Navigator Organization to Zendesk Organization). Suspended contacts in Alloy Navigator unsuspend during migration into Zendesk; we flag any suspended contacts during discovery so the customer can decide whether to migrate them as inactive or skip them entirely.

Alloy Navigator User records (technicians) map to Zendesk Agents. We resolve by email match against the Zendesk destination account. Active versus inactive status must be explicitly mapped: active Alloy Navigator technicians become active Zendesk agents; inactive technicians become Zendesk agents with the suspended flag. Role mapping (Alloy Navigator security roles to Zendesk agent roles) requires customer input because Zendesk's role model is different from Alloy's classification-based permission structure.

Alloy Navigator Assets (hardware devices, software licenses, consumables) require custom object mapping in Zendesk since Zendesk has no native asset management object. We create a Zendesk custom object named 'Asset' with custom fields matching the Alloy Navigator asset schema: asset_tag, serial_number, purchase_date, purchase_cost, warranty_expiry, assigned_user (lookup to End User), and status. Asset lifecycle states (Procurement, Deployment, In Repair, Retired) map to a custom Asset Status picklist. The asset_assignment_history migrates as a JSON array in a custom field or as related custom object records.

Alloy Navigator Configuration Items model IT infrastructure components and their relationships. We map CIs to a Zendesk custom object named 'Configuration_Item' with custom fields for CI type, serial number, IP address, MAC address, manufacturer, model, and status. CI relationship graphs (parent-child, dependency, connected-to) migrate as relationship records in a Zendesk custom object named 'CI_Relationship' with source_ci and target_ci lookup fields and a relationship_type picklist (Contains, Depends_On, Connects_To, Runs_On). Custom CI types introduced via Alloy classification are detected during discovery and mapped to Zendesk custom object subtypes via a type field.

Alloy Navigator Knowledge Management articles migrate to Zendesk Guide articles. Article body (formatted text, attachments) maps to Zendesk article body. Article category hierarchies in Alloy Navigator map to Zendesk Guide section structures; however, Zendesk Guide on non-Enterprise plans limits section nesting to two levels, and Enterprise allows up to five levels. We flag any Alloy Navigator category trees that exceed Zendesk's nesting limit and propose a flattening strategy (root path as section name, or denormalized section naming). Attachments migrate as article file attachments. The default language constraint applies: only the default language article migrates automatically; non-default language articles require post-migration translation workflow or manual re-creation.

Alloy Navigator Work Orders manage scheduled tasks, assignments, and completion tracking. We map Work Orders to Zendesk Tasks with the subject, description, schedule date, assignee (lookup to Agent), and status preserved. If the customer requires the full Work Order schema including custom fields (work order type, labor hours, parts used), we create a Zendesk custom object named 'Work_Order' with the additional fields. Work Order status values map to Zendesk Task status values (open, pending, complete). Linked Work Order items migrate as related Task records or as line items on the custom Work_Order object.

Alloy Navigator Contracts link to Assets and Contacts with renewal dates, terms, and costs. We map Contracts to a Zendesk custom object named 'Contract' with fields for contract_name, contract_type (Maintenance, Support, SLA, Lease), vendor_name, start_date, end_date, renewal_date, annual_cost, and related_asset (lookup to Asset custom object). Multi-document contracts with binary file attachments require file migration as Zendesk article file attachments or as ContentDocument records linked to the Contract custom object. Contract renewal alerts require manual configuration in Zendesk's trigger framework post-migration.

Alloy Navigator Software Licenses track compliance, seat counts, and purchase records attached to Assets. We map Software Licenses to a Zendesk custom object named 'Software_License' with fields for license_name, product_name, license_type (Perpetual, Subscription, OEM, Trial), seat_count, used_seats, free_seats, purchase_date, expiry_date, vendor, cost, and related_asset (lookup to Asset custom object). License compliance metrics (compliant, over-deployed, under-utilized) migrate as a compliance_status picklist. License entitlement calculations are source-system-specific and may not map directly to Zendesk's reporting model; we document the compliance formula for the customer's admin to implement in Zendesk Explore or a BI tool.

Alloy Navigator Locations form hierarchical trees representing physical sites for Organizations. Zendesk Organizations do not support hierarchical location structures. We flatten the location hierarchy by mapping the root location to the Organization name or a custom organization field, and preserve the full parent path as a denormalized string field (e.g., 'Building A / Floor 3 / Room 301'). For customers requiring full location hierarchy in Zendesk, we propose a custom object named 'Location' with parent_location lookup field, which allows unlimited depth but requires manual rebuild of any location-based routing logic. We flag location tree depth during scoping and confirm the flattening strategy before migration begins.

Alloy Navigator Workflows drive business process automation including approval chains, escalations, and Create Actions. We do not migrate Workflows as code because the Alloy Navigator Workflow model (classification-triggered, with Create Actions, field updates, and external integrations) does not map to Zendesk's trigger and macro framework. We export the full Workflow definitions, trigger conditions, action lists, and escalation rules as a written inventory document. The customer's Zendesk admin or a Zendesk partner rebuilds each Workflow as Zendesk triggers, macros, and automation rules. Workflow configuration that cannot be represented in Zendesk (e.g., Alloy-specific integrations) is flagged in the inventory with alternative approach notes.