Migrate from SendCloud to Salesforce Sales Cloud

SendCloud Parcel records map to a Salesforce custom object Shipment__c with fields for Parcel ID, weight, dimensions, reference number, status, and carrier routing. The Parcel's status field maps to a custom Shipment_Status__c picklist. Shipment__c is linked to the parent Account via a Lookup relationship, allowing fulfillment context to appear on the Account record. The original SendCloud Parcel ID is preserved in a custom field sc_parcel_id__c for audit traceability.

SendCloud Shipment records (logical groupings of one or more Parcels to the same recipient) map to a parent Shipment__c record that aggregates child Parcel records via a lookup relationship. The Shipment's destination Address, shipping method, service level, and estimated delivery date become fields on the parent Shipment__c. If the destination Salesforce org uses Order Management, the Shipment__c can alternatively be linked to an Order record via WhatId.

SendCloud Return records map to a custom object Return_Request__c with fields for RMA number, return reason code, return label tracking number, and RMA status. The original SendCloud return reason codes are mapped to a picklist or multi-select picklist in Salesforce. Return_Request__c is linked to the original Shipment__c record (via lookup) and to the parent Account and Contact for service context.

Ship-from and ship-to addresses from SendCloud Shipments migrate as structured address records. In Salesforce, we map addresses to Account ShippingAddress fields for the merchant's ship-from location, and to a custom ShippingAddress__c object linked to Account or Contact for recipient addresses. Address validation rules differ between platforms; we flag address format discrepancies during reconciliation and apply normalization where possible.

SendCloud carrier configurations map to a Carrier__c custom object with fields for carrier name, carrier code, and service levels. We map carrier-to-carrier between SendCloud and Salesforce or the customer's preferred carrier integration. Merchant-specific negotiated carrier rates are SendCloud-stored values and do not transfer; we document the carrier mapping and flag that rate renegotiation or direct carrier account porting is required separately.

Custom fields added to SendCloud Parcels and Returns on Growth and above plans are inventoried during scoping. Each custom field is mapped to an equivalent custom property on the corresponding Salesforce custom object, with Salesforce field types selected to match the source data type (text, number, date, picklist). The custom field schema is pre-created in the destination org before data import begins.

SendCloud webhook endpoint configurations (Parcel status change, shipment event, return update) are exported as a structured inventory document listing endpoint URL, event types, and authentication configuration. We do not migrate webhooks as live connections because they are tied to the SendCloud account. The inventory document is delivered to the customer for manual recreation in the new shipping platform or Salesforce-based integration.

SendCloud user accounts with role assignments tied to shipping operations are inventoried and mapped to Salesforce User records by email match. Permission structures are platform-specific and require manual reconfiguration in Salesforce. The user inventory document identifies which SendCloud users should have Salesforce access provisioned and their recommended profile or permission set assignment.

Active native integrations with shop platforms (Shopify, WooCommerce, Magento, PrestaShop) are inventoried and documented with their current API credentials, webhook endpoints, and data sync scope. We flag which integrations require new API credentials to be generated and which require reconfiguration in the destination platform or the shop platform's integration settings. The integration inventory is delivered as a checklist for the customer's technical team to complete post-migration.

SendCloud label format preferences (carrier label size, branding options, barcode settings) are stored as account-level configuration. We inventory available label format settings during scoping and document them for manual reconfiguration in the destination shipping platform or as custom settings in Salesforce if the customer implements a custom label generation workflow.

SendCloud Parcel tracking status events (label created, picked up, in transit, out for delivery, delivered, exception) map to child Shipment_Event__c records under the parent Shipment__c. Each event carries the timestamp, status, location, and carrier scan description. We preserve the full tracking timeline as a related list on the Shipment__c, allowing service and ops teams to view delivery history directly in Salesforce without navigating to SendCloud.

Return labels generated in SendCloud (with tracking number, carrier, and label URL) map to custom fields on the Return_Request__c record: Return_Carrier__c, Return_Tracking_Number__c, and Return_Label_URL__c. The label binary itself is not migrated; instead we preserve the reference data so the customer can regenerate return labels in their new shipping platform and update the Return_Request__c record with the new label information.