Migrate from Moskit to HubSpot

Moskit persons map 1:1 to HubSpot contacts. The person's name, email, phone, job title, and address fields translate to HubSpot's standard contact properties. Organizations linked as the primary company become the Contact's primary CompanyId lookup; secondary organizations are preserved as HubSpot company associations.

Moskit organizations map to HubSpot companies. Domain, name, industry, employee count, and annual revenue map to their HubSpot equivalents. Parent-child organizational hierarchies in Moskit map to HubSpot's parent company field. Multi-organization contact links collapse to one primary company per contact in HubSpot.

Moskit deals map to HubSpot deals. Each deal carries a name, amount, status (mapped to pipeline stage), close date, owner, and linked contacts/organizations. Moskit's flat status field requires mapping to HubSpot's pipeline-specific stage values — one Moskit status value set per HubSpot deal pipeline.

Moskit's deal status is a flat pick-list. HubSpot deals have stage values scoped per pipeline. We map each distinct Moskit status value to a HubSpot stage within the target pipeline. If Moskit stores probability or weighted value on the deal, those migrate as HubSpot custom properties.

Moskit's person status field has no native HubSpot equivalent. We create a lifecycle_stage custom property on the HubSpot contact object and populate it with the Moskit status values. Lifecycle stage history in Moskit (if stored) migrates as a secondary custom property for audit continuity.

Moskit activities (calls, emails, meetings, tasks, notes) map to HubSpot engagements. Each activity retains its original timestamp, owner, and parent-record link (person or deal). Engagement type (call, email, meeting, note) is stored as a custom property on the HubSpot engagement record.

Moskit projects are their own object type with a relationship to deals or persons. If HubSpot has a matching custom object already created, we map project fields directly. If no custom object exists, we flag it during planning and create the custom object definition before the migration runs.

Any Moskit custom fields on persons migrate as HubSpot contact custom properties. Field type conversion (date, number, multi-select pick-list) must match HubSpot's type model. We surface each custom field's Moskit type during the planning phase so HubSpot-side creation happens before data lands.

Moskit custom fields on organizations migrate as HubSpot company custom properties. Multi-select pick-lists in Moskit map to HubSpot's multi-checkbox or multi-select-picklist property types. We validate HubSpot property limits per plan tier during the planning phase. If any organization custom fields exceed the property count limits of your HubSpot plan, we flag them for field consolidation or plan upgrade before migration proceeds.

Moskit owner IDs are resolved to HubSpot users by email match. Unmatched owners are flagged before migration — your team either invites them to HubSpot or assigns their records to a fallback owner. No record lands in HubSpot without a valid owner assignment.

Moskit file attachments linked to persons, organizations, or deals are re-uploaded to HubSpot Files and attached to the corresponding record. We handle file type detection, re-hosting, and HubSpot file size limits (default 25MB per file) during the migration run. Files larger than the HubSpot limit are split or linked externally, with a reference stored in the CRM record.

Moskit followers on deals, organizations, or persons have no direct HubSpot equivalent. We map followers to a custom property (Follower_Ids__c) or association record in HubSpot so the follow relationship is preserved as reference data for your team to action manually.