Migrate from SendCloud to HubSpot

SendCloud has no native contact object — addresses are the contact proxy

SendCloud stores recipient and sender data as Address objects tied to shipments, not as standalone contact records. There is no SendCloud contact with a persistent email record unless the address was used across multiple shipments. FlitStack deduplicates addresses by email during migration: when the same email appears across multiple SendCloud shipments, we create one HubSpot contact and associate all matching shipments to it. If an address appears only once and has no email, we create a contact with available fields and flag it for review. This behavior is specific to the SendCloud-to-HubSpot pair because most other CRMs have a contact object that SendCloud address data maps onto directly.

HubSpot has no native shipment or logistics object — custom schema is required

HubSpot's standard CRM objects (Contact, Company, Deal, Ticket) have no fields for carrier name, shipping rate, tracking status, or return reason. Migrating SendCloud data without creating HubSpot custom objects means losing the logistics layer entirely. FlitStack creates a Shipment custom object and a Return Request custom object in HubSpot before writing data, but this requires HubSpot Enterprise or Professional tier. We surface the exact custom-object schema required in the migration plan so your HubSpot admin can pre-approve the property creation in staging before the migration runs.

SendCloud workflows have no HubSpot CRM equivalent and cannot migrate

SendCloud automations — carrier routing rules based on weight or destination, return-flow triggers, label-print conditions, and carrier-specific rate shopping logic — operate on logistics events that HubSpot workflows cannot observe. HubSpot workflows trigger on CRM property changes, form submissions, deal stage updates, and similar CRM events, not on carrier scan events or shipment status changes. FlitStack documents every SendCloud automation as a rebuild reference specification and can map the trigger conditions to HubSpot workflow equivalents where the business logic overlaps (e.g., if a SendCloud return request should create a HubSpot ticket, we note that mapping). The automation rebuild itself is out of scope for the data migration.

SendCloud API rate limits constrain bulk export speed

SendCloud's API enforces rate limits that vary by account tier. Large-volume migrations (500,000+ shipments) require pacing to stay within these limits, which extends migration clock time. FlitStack implements exponential backoff and respects SendCloud rate limit headers during extraction. We surface the estimated export duration based on your SendCloud plan tier during the discovery phase, and we can request a rate-limit increase on your behalf from SendCloud if your plan allows.

SendCloud tracking event history requires schema flattening for HubSpot storage

SendCloud stores tracking events as a chronological array per shipment (pickup scan, transit scan, delivery scan, return initiation, etc.) with individual timestamps and location data. HubSpot has no native equivalent and no repeating or nested property structure for timeline events. We serialize the full event array into a single long-text property (Event_Log__c) on the Shipment custom object. This preserves all original timestamps and status codes but means the data is not queryable as individual HubSpot timeline entries — it is readable as a structured log. Teams that need per-event CRM automation triggers should rebuild those triggers using HubSpot workflow tools after migration.