Migrate from SendCloud to Mailchimp

SendCloud's ship-to addresses from Parcels and Shipments map to Mailchimp Contacts using email address as the deduplication key. Each Contact record receives ADDRESS1, ADDRESS2, CITY, STATE, POST, and COUNTRY merge fields populated from the SendCloud address object. If SendCloud stores multiple addresses per customer (billing vs shipping), we import both with separate merge field sets or flag the primary shipping address. Any address missing an email address is held in a reconciliation queue because Mailchimp requires an email address to create a subscriber record.

SendCloud Parcel records carry status (pending, shipped, delivered, returned), carrier name, and shipment date. We aggregate Parcel status per customer email to populate Mailchimp Tags (Active Shipper, Delivered, Returned, Never Delivered) and Segments (Recent Buyers: delivered in last 30 days; Repeat Buyers: more than one Parcel; Returners: at least one Return). Tag and segment logic is designed during scoping based on the customer's campaign strategy.

SendCloud Shipment records contain carrier name, shipping method, service level, and estimated delivery date. We map carrier name to a custom merge field CARRIER__c on the Contact record so that Mailchimp automations can reference the shipping method without querying SendCloud. This is particularly useful for post-purchase email sequences that depend on carrier-specific delivery timeframes.

SendCloud Return records carry return reason code, RMA status, and return-to-address. We tag returning contacts with RETURNED and return-reason tags (Damaged, Wrong Item, Changed Mind, Other) and add them to a Returns segment for targeted win-back or re-engagement campaigns. Return portal configurations do not migrate because Mailchimp has no return-portal object; we document the original return settings for manual reconfiguration at SendCloud or a dedicated returns platform.

SendCloud custom Parcel fields (account-scoped, visible on certain plans) map to Mailchimp custom merge fields. We pre-create each merge field in Mailchimp before import, noting that Mailchimp requires merge tags to be the first 10 characters (uppercase, no underscores) of the field label. Boolean and null custom fields from SendCloud must be created as TEXT merge fields in Mailchimp because Mailchimp stringifies these types on import. Date fields from SendCloud map to Mailchimp date merge fields only if the date format is ISO 8601; non-date values cause import failures.

SendCloud webhook endpoint configurations (Parcel status change, shipment event, return update) are exported as a written inventory document. Mailchimp does not have a webhook equivalent for shipping status; instead, Mailchimp triggers automations based on Contact behavior (opens, clicks, tag additions). We document which SendCloud webhooks should be replaced with Mailchimp automations and provide trigger mapping guidance. Actual webhook and integration reconfiguration is outside migration scope and requires the customer's technical team.

SendCloud native integrations with Shopify, WooCommerce, Magento, PrestaShop, and other shop platforms connect order data to the shipping workflow. We inventory active integrations during scoping and flag which require new API credentials in Mailchimp or a middleware connector (Zapier, Make, or the native Mailchimp e-commerce sync). The actual credential rotation and endpoint updates are outside migration scope.

SendCloud user accounts with shipping operation roles (Admin, Shipper, Viewer) do not map directly to Mailchimp user roles because the platforms have different permission models. We migrate a list of SendCloud user names and emails as a reference document so the customer's Mailchimp admin can provision equivalent access levels in Mailchimp (Admin, Manager, Author, Viewer) post-migration.