Migrate from Track-It! to Salesforce Service Cloud

Track-It! tickets map directly to Salesforce Case. The HDTickets table columns (Title, Description, Status, Priority, Category, RequesterName, RequesterEmail, AssignedTo, CreatedDate, ResolvedDate) map to Case Subject, Description, Status, Priority, Type, Contact name/email, OwnerId, CreatedDate, and ClosedDate. The HDTicketHistory table provides the audit trail, which migrates as a structured attachment to the Case record. Custom fields appended to HDTickets are pre-inventoried during discovery and created as Salesforce custom fields on Case before migration.

Track-It! assets stored in the Assets table map to Salesforce Asset. The asset name, serial number, status, purchase date, and location fields map directly. AssetRelations records (linking child assets to parent assets) map to Salesforce Asset Relationships. We resolve the Account and Contact lookups on Asset by matching the Track-It! customer account reference to the Salesforce Account mapped from Track-It!'s HDUsers or a related customer table.

Salesforce Service Cloud has no native Change Request object. We propose one of two approaches during scoping: (a) map Change Requests to Case with a Change Request Record Type, mapping approval status and risk fields to custom Case fields; or (b) create a custom Change_Request__c object in Salesforce with the approval routing, risk assessment, and implementation fields from the Track-It! ChangeRequests table. The customer selects the approach before schema design. Linked CIs on the Change Request are preserved as custom lookup fields.

Track-It! technician accounts in HDUsers map to Salesforce User records. We resolve by email match against the Salesforce org's User table. End-user accounts (requesters) from HDUsers map to Salesforce Contact if the organization uses Contact-based case management. Any Track-It! user without a matching Salesforce User goes to a reconciliation queue for admin provisioning before production migration.

Track-It! SLA configurations (response and resolution timers per priority level) map to Salesforce Entitlement Processes and Milestones. We extract the SLA-to-priority mappings from Track-It!'s configuration tables and configure Salesforce Entitlement records linked to Account, with milestones for First Response and Case Resolution. Business hours mapping from Track-It! transfers to Salesforce Business Hours so that SLA timers honor the correct support window.

Track-It! attachments stored as BLOBs in the database or as file references to the Track-It! file store extract to a structured file package. Each attachment associates with its parent ticket or asset record by the original reference key. In Salesforce, attachments load as ContentVersion records (file body and metadata) linked to the parent record (Case or Asset) via ContentDocumentLink. Large BLOB volumes extend migration timeline — we estimate storage and extraction time during discovery.

Track-It! KB articles stored in a dedicated module table with category and tag relations migrate to Salesforce Knowledge Article (KaAnswer data category). Article bodies, summaries, and metadata preserve. Category assignments from Track-It! map to Salesforce data categories and topic assignments. KB article-to-ticket linking is documented as a separate mapping for the admin to re-create via lookup fields or a junction object post-migration.

Track-It! stores full audit trails in per-module history tables (HDTicketHistory, AssetHistory, ChangeRequestHistory). We extract the complete change log as a structured JSON or CSV dataset and attach it to the migrated record in Salesforce. Options include CaseComment records (chronological list of changes), a custom Case_Audit__c object, or a structured file attachment. The customer selects the format during scoping. This is important because Track-It!'s per-group view permissions affect which history records a user could see — we capture the full history regardless of group permissions.

Track-It! ConfigItems represent configuration items, license counts, and component hierarchies that extend beyond standard assets. The mapping depends on how the customer uses ConfigItems: serializable hardware assets map to Salesforce Asset; software licenses and subscriptions map to a custom Asset_License__c object; CI relationships map to custom lookup fields or junction objects. We inventory every ConfigItems column during discovery and propose the appropriate Salesforce object per row in the mapping spreadsheet.

BCM (Business Configuration Management) linkage records that connect assets to tracked items and maintain CI relationship graphs do not survive migration to Salesforce. These records are specific to Track-It!'s BCM module and have no Salesforce equivalent. We run a pre-migration query to enumerate every BCM-linked record, surface the full list to the customer, and document each relationship type (asset-to-ticket, CI-to-CI, license-to-asset) with a recommendation for re-creating it in Salesforce via custom fields or lookup relationships. This gap is accepted at migration sign-off.

Track-It! Purchase Order records (PO headers and line items in a dedicated module table) are extracted if they contain relevant asset or expense data. Where the destination Salesforce org does not have a native PO object, we map PO headers to a custom Asset_Purchase__c object with line items as a child Asset_PO_Line__c object. The customer selects the approach during scoping based on their finance workflow requirements.