Migrate from SendCloud to Twenty CRM

SendCloud stores ship-to and ship-from addresses as structured objects linked to Shipments and Returns. Ship-to addresses with a customer name map to Twenty People records; ship-from addresses (warehouse or business origin) map to Twenty Company records as the company's primary address. We deduplicate by address string during export and preserve the original SendCloud address_id as a custom field sc_address_id__c for reconciliation. Address validation rules differ between platforms; we flag any address records that fail Twenty's validation during import for manual correction.

SendCloud Shipments represent the logical grouping of one or more Parcels sent to the same recipient address. We create a custom Shipment object in Twenty with fields for shipment_date, shipping_method, service_level, carrier, tracking_number, destination_address (lookup to People), and ship_from_address (lookup to Company). The SendCloud shipment_id becomes sc_shipment_id__c on the custom object for cross-reference. Historical shipment status (in_transit, delivered, returned) migrates as a select field.

SendCloud Parcels are the transactional unit with weight, dimensions, reference number, and status. We create a custom Parcel object in Twenty with fields for parcel_reference, weight, dimensions, status, and a lookup to the parent Shipment object. Each Parcel's shipment link is resolved at migration time using the SendCloud parcel_id-to-shipment_id relationship. Parcel custom fields (defined on certain SendCloud plans) migrate as custom fields on the Parcel object, created in Twenty before import.

SendCloud Return requests track inbound parcels with return reason codes, return label data, and RMA status. We create a custom Return object in Twenty with fields for rma_number, return_reason, return_status, return_label_url, and lookups to the original Shipment (via sc_shipment_id__c) and the People record of the returning customer. Return reason codes are mapped to a select field with options sourced from SendCloud's available codes during scoping.

SendCloud User accounts with shipping operations roles map to Twenty People records. We extract user name, email, and role assignments from SendCloud and create corresponding People records in Twenty. Role assignments are stored as a text field since Twenty's permission model is workspace-scoped and not directly equivalent to SendCloud's account-level role structure. Active SendCloud users without a matching email in Twenty are held in a reconciliation queue for the customer's admin to provision.

SendCloud custom fields defined on Parcels and Returns are account-specific and exposed partially via API. We inventory all custom fields during scoping, map their data types to equivalent Twenty field types (text, number, date, select, multi-select), create the fields in Twenty's Settings → Data Model before import, then populate them during the data load. Any custom fields with unsupported data types are flagged for manual migration post-load.

SendCloud webhook endpoint configurations are exported during scoping as a written inventory document. We do not migrate live webhook connections because they are tied to SendCloud credentials and will not function at Twenty. The inventory includes the endpoint URL, event type (parcel_status, shipment_created, return_initiated), and payload schema for each webhook so the customer's development team can recreate these in Twenty's webhook configuration. This is a manual rebuild task outside migration scope.

SendCloud's native integrations with Shopify, WooCommerce, Magento, PrestaShop, and other shop platforms are inventoried during scoping. We export integration configuration settings (API keys, webhook URLs, sync settings) as a written document for the customer's admin to reconfigure in the destination platform. Twenty has no native Shopify or WooCommerce integration; the customer will need to build a custom integration via Twenty's REST or GraphQL API, use an iPaaS tool like Zapier or n8n, or engage a developer. This is documented as a post-migration configuration task.

Carriers defined in SendCloud's routing rules map to a select field on the custom Shipment object in Twenty. We create a carrier__c select field with options sourced from the active carrier list in the SendCloud account. Carrier-specific routing rules (which are SendCloud-stored workflow configurations) are documented in the integration inventory for manual rebuild. Merchant-specific negotiated carrier rates are not exported from SendCloud and do not migrate; this is flagged as a high-severity gotcha before migration begins.

SendCloud shipping label binary files are not migrated as they are carrier-generated PDF or ZPL files stored in SendCloud's file system. We create a label_url__c text field on the Parcel object and populate it with the SendCloud label URL if accessible via API during the export window. Post-migration, the customer regenerates labels from the carrier portal directly using the tracking number and shipment data migrated to Twenty. Label format preferences (size, branding) are documented for manual reconfiguration at the carrier level.