Migrate from Alloy Navigator to HubSpot Service Hub

Alloy Navigator Service Requests map to HubSpot Service Hub Tickets. The mapping is 1:1 for standard fields (Ticket ID, Subject, Description, Priority, Category). The critical complexity is Alloy Navigator's classification-driven status values: Status = 'Open' in one classification may be 'New' in another, and these custom status value tables must be normalized before mapping to HubSpot pipeline stages. We detect every distinct status value set during discovery, create a unified status mapping table, and assign each Alloy Navigator status to a corresponding HubSpot Ticket pipeline stage before import. Ticket conversations and internal notes migrate as Ticket Conversations in HubSpot.

Alloy Navigator Tickets carry linked Incident, Problem, and Change sub-records that represent the ITIL resolution chain. These do not map to separate HubSpot objects because HubSpot Service Hub has no native Incident-Problem-Change model. We flatten these linkages into Ticket Conversation entries with a structured prefix (e.g., '[Change]') and preserve the linked record's description, status, and assignee. The original Alloy Navigator record ID is stored in a custom Ticket field for audit traceability.

Alloy Navigator Organizations map directly to HubSpot Companies. The Organization name becomes the Company name, domain data becomes the Website field, and the primary contact link is preserved as a Company-to-Contact association. We run deduplication by domain and Organization name before import to avoid duplicate Companies in HubSpot.

Alloy Navigator Locations form a hierarchical tree (e.g., Headquarters > Building A > Floor 2 > Rack Room) that has no direct HubSpot equivalent. HubSpot Companies have a single flat address. We flatten the location path into a structured string (e.g., 'Headquarters / Building A / Floor 2 / Rack Room') stored in a custom Company field, and preserve the deepest-level address as the primary Company address. If the customer requires full tree fidelity, we store parent-location references in a secondary custom field for downstream reporting.

Alloy Navigator Contacts map to HubSpot Contacts. The mapping is 1:1 for standard fields (Name, Email, Phone, Title, Department). Contact-Organization links become HubSpot Contact-to-Company associations. We run email-based deduplication before import. Any Contact records without valid email addresses are flagged for manual review and imported with a email-format placeholder.

Alloy Navigator Assets (hardware, software licenses, consumables) do not map directly to a HubSpot standard object. For basic hardware and product records, we migrate to HubSpot Products with a custom asset type field. For full lifecycle tracking (procurement date, warranty, assigned user, retirement date), we create a custom Asset object in HubSpot (requires Operations Hub Professional or Enterprise) or store the critical fields as custom fields on the Contact record for simpler implementations. The customer chooses the strategy during scoping.

Alloy Navigator Configuration Items model IT infrastructure components with relationship graphs. HubSpot Service Hub has no native CI model. We create a HubSpot Custom Object (requires Operations Hub) named 'Configuration_Item__c' with custom fields matching the Alloy Navigator CI schema: CI_Name, CI_Type, CI_Class, Serial_Number, IP_Address, Linked_Organization, and Relationship_Graph (stored as a structured JSON field or separate junction object). CI-to-CI relationships are preserved via custom lookup fields or a separate Relationship junction object. This is the most significant schema design task in the migration.

Alloy Navigator Knowledge Base Articles migrate to HubSpot Knowledge Base articles using HubSpot's native Knowledge Base Importer (not via API). We export the article body, metadata (category, author, publish date), and attachments, then the customer's admin uses HubSpot's importer tool to load them. Category hierarchies in Alloy Navigator may not map 1:1 to HubSpot's knowledge base folder structure; we flag the hierarchy and provide a category flattening recommendation during scoping.

Alloy Navigator Work Orders manage scheduled tasks and assignments separate from reactive tickets. HubSpot has no native Work Order object. We create a custom object 'Work_Order__c' with fields for Scheduled_Date, Assigned_User, Work_Order_Status, Description, and linked Ticket reference. Work Order schedules and completion records migrate as structured fields rather than a calendar integration.

Alloy Navigator Contracts link to Assets and Contacts with renewal dates, terms, and costs. We migrate contract metadata (Contract_Name, Vendor, Start_Date, End_Date, Renewal_Term, Cost) to a custom object 'Contract__c' with a lookup to the associated Company and Asset. Multi-document contracts with binary file attachments require file storage strategy; we store attachment URLs as text fields and recommend HubSpot's file manager for document hosting post-migration.

Alloy Navigator Software Licenses track seat counts, compliance metrics, and purchase records attached to Assets. We create a custom object 'Software_License__c' with fields for License_Key, Product_Name, Seats_Total, Seats_Used, Expiry_Date, Vendor, and linked Asset reference. Compliance metrics are calculated in Alloy Navigator using entitlement rules that are source-system-specific; we flag that these recalculate post-migration in HubSpot rather than migrate as static values.

Alloy Navigator Users (technicians) map to HubSpot Service Hub Users. We resolve by email match. Team assignments and role-based permissions in Alloy Navigator do not map directly to HubSpot's team and permission model; we store the Alloy Navigator team name in a custom User field and document the role mapping for the customer's admin to configure in HubSpot Settings. Inactive Alloy Navigator users are imported as inactive HubSpot users with their ticket history preserved.