Migrate from Startly to HubSpot Service Hub

Startly Tickets migrate directly to HubSpot Tickets. The Startly ticket status (open, pending, resolved) maps to HubSpot Ticket status values, and Startly priority maps to HubSpot Priority. We preserve ticket subject, description, requester reference, assignee reference, created date, updated date, and closed date as typed HubSpot properties. Conversation threads migrate as HubSpot Ticket-engraved EmailMessage records. Startly custom fields migrate as HubSpot custom properties if the destination Service Hub account is Professional or above; Starter tier limits custom properties and we flag this constraint during scoping.

Startly Users map to HubSpot Users by email match. We extract all active Startly users and map them to HubSpot Users at migration time. Inactive or disabled Startly accounts are held in a reconciliation queue for the customer's admin to decide whether to import as inactive HubSpot users or exclude them. HubSpot seat count is determined post-mapping, and Starter tier limits paid seats; we flag this before production migration.

Startly Organizations map to HubSpot Companies. The Startly organization name becomes the HubSpot Company name, and the domain field (if present) becomes the Company website. Organization-to-user assignments in Startly are preserved as Company-to-Contact associations during the Contact import phase.

Startly ticket requesters map to HubSpot Contacts. If the requester email matches an existing HubSpot Contact record, we link by ContactId; otherwise we create a new Contact from the requester record. Startly requester name, email, phone, and any custom requester properties migrate as HubSpot Contact properties.

Startly Assets (hardware, software, contracts) have no native HubSpot Service Hub equivalent. We migrate asset name, type, status, assigned user, and location as structured rows in a supplemental asset export. For IT teams that require asset-to-company linkage in HubSpot, we create a custom asset__c multi-select property on the Company object and link asset names to the relevant Company record. Relationship graphs (asset to CI, asset to user) are documented as a reference CSV for manual re-association post-migration.

Startly CMDB entries represent servers, software, and network devices with relationships to each other and to Assets. HubSpot Service Hub does not have a native CMDB or configuration item object. We create a custom HubSpot object (CI__c) during schema pre-creation, migrating CI name, type, serial number, location, and status as custom properties. CI-to-CI relationships and CI-to-asset relationships are preserved as structured reference rows in a supplemental export CSV and documented for manual re-association in HubSpot. This mapping requires HubSpot Professional or Enterprise because custom objects are not available on Starter.

Startly SLA policies define response time and resolution time targets tied to ticket priority with associated business hour calendars. HubSpot Service Hub does not have a native SLA object; service level targets are tracked via HubSpot Goals on Professional and above. We extract SLA configuration values (hours, thresholds, priority mappings, business-hour schedules) as a structured reference document during migration scoping. The customer recreates these as HubSpot Goals manually after migration, referencing the extracted values. SLA data is not imported as a live HubSpot object in this migration.

Startly Projects bundle tasks, budgets, and time entries under a single record. HubSpot has no project object. We migrate project metadata (name, description, dates) as a structured reference export. Tasks within the project migrate as standalone HubSpot Tasks without a parent project linkage, and budget and profitability data migrates as a supplemental CSV flagged for manual review. If the customer requires project tracking in HubSpot, we recommend a third-party project integration post-migration.

Startly time entries track labor against tickets and projects with description, duration, and billable flag. We migrate time entry records as HubSpot Tasks, setting the Task subject to the linked Startly ticket subject and ActivityDate to the time entry date. Time entry IDs are not portable and do not recreate as linked records; they are assigned new HubSpot Task IDs. Billable flag and duration migrate as custom properties on the Task. Time entries linked to projects without a corresponding HubSpot project object are migrated as standalone tasks with a project name reference field.

Startly Knowledge Base articles are associated with ticket categories and service catalog items. HubSpot Service Hub has a native Knowledge Base import tool that accepts articles in a structured format. We extract Startly KB content, metadata, and article-to-category associations, then format the export for ingestion via HubSpot's pre-built Knowledge Base importer. Category-to-article relationships are not preserved as portable foreign keys; we document the original linkage for manual re-association in HubSpot Knowledge Base.

Startly service catalog items define requestable services with associated forms, approval workflows, and KB article links. HubSpot Service Hub does not have a service catalog equivalent. We extract catalog item structure (name, description, form fields, associated KB articles) as a reference document. Approval workflows and routing rules do not migrate as code; we document the routing logic for the customer's admin to rebuild in HubSpot using Workflows or a third-party service catalog tool.

Startly Change Requests manage change lifecycle with risk assessment, approval fields, and linked CIs from the CMDB. HubSpot Service Hub does not have a native change request object. We migrate change request records (subject, description, risk level, status, change type) as structured rows in a reference export, and we extract the linked CI references for reconciliation against the custom CI__c object if that custom object was created during migration scoping. Approval workflows and risk matrices do not migrate.

Startly post-resolution satisfaction surveys and CSAT scores associated with resolved tickets migrate to HubSpot Service Hub's native survey tracking if HubSpot CSAT surveys have been configured. Startly survey responses map to HubSpot survey submission records linked to the corresponding migrated ticket. If HubSpot CSAT surveys are not yet configured at migration time, we preserve the survey response data as a supplemental CSV for manual import after the customer activates HubSpot surveys.

Startly workflow rules define automated actions triggered by ticket or project events. HubSpot Service Hub has its own automation model using Workflows (Professional and above) and Operations Hub for advanced automation. Startly workflow rules do not migrate as code. We extract every active Startly workflow rule with its trigger, conditions, and actions and deliver this as a written inventory document with recommended HubSpot Workflow equivalents. The customer's admin rebuilds these in HubSpot post-migration. This is standard scope for all FlitStack AI migrations.

Startly ticket tags (labels assigned to tickets for categorization) migrate to HubSpot Ticket multi-select properties or HubSpot Topics depending on the customer's intended use. Tags used for internal ticket classification migrate as multi-select properties on the Ticket object. Tags used for content or knowledge organization migrate as HubSpot Topics with TopicAssignment records. The customer selects the tag strategy during scoping.