Salesforce Marketing Cloud Migration for a Passenger Ferry Operator
A government-owned ferry operator ran email journeys, post-trip surveys and a loyalty voucher programme on Salesforce Marketing Cloud. The platform's rigid, siloed structure meant every campaign change depended on a specialist. We rebuilt the marketing automation natively in HubSpot Marketing Hub Enterprise ahead of a Salesforce licence expiry. It replaced 21 daily email journeys and the trip-count-triggered loyalty voucher with logic tied directly to the booking record on each Contact.
Executive Summary
Context
A government-owned ferry operator ran its passenger marketing on Salesforce Marketing Cloud, alongside a Salesforce CRM nearing the end of its purchased licence term. Every email journey, post-trip survey and loyalty send ran on a platform the marketing team found rigid and siloed. Changing one campaign meant routing the request through a small group of specialists.
What We Built
We rebuilt the operator's email marketing programme natively inside HubSpot Marketing Hub Enterprise. It replaced all 21 daily journeys that had run on Salesforce Marketing Cloud, and we rebuilt the loyalty voucher automation on a Bookings custom object tied to each Contact record.
Tech Stack
- Salesforce Sales Cloud
- Salesforce Service Cloud
- Salesforce Marketing Cloud
- HubSpot Marketing Hub Enterprise
- HubSpot Sales Hub Enterprise
- HubSpot Service Hub Enterprise
- HubSpot Data Hub Enterprise
- HubSpot Smart CRM Enterprise
- Bookings custom object
Not a fit if your CRM and marketing platform migration has no hard licence-expiry deadline forcing a fixed cutover date, because the sequencing here assumes a fixed window and not an indefinite parallel run. Also not a fit if you don't already hold Enterprise-tier hubs across marketing, sales and service, since the rebuilt journeys and loyalty automation depend on features gated to that tier.
The Challenge
Salesforce Marketing Cloud held every one of the operator's email journeys, its post-trip survey sends, and the loyalty voucher logic that tracked how many trips a passenger had taken. The platform's rigid, siloed structure meant a change to one journey needed someone who understood its configuration. So day-to-day optimisation of 21 daily sends depended on a small group of Marketing Cloud specialists, not on the marketing team itself.
A Salesforce licence due to expire within months turned that dependency into a deadline. The CRM data underneath the journeys, and the survey and loyalty logic built on it, all had to move before the licence lapsed. That meant we couldn't treat the loyalty voucher and the 21 journeys as one open-ended migration. Each had to go live against the deadline while the existing Marketing Cloud sends kept running.
Our Approach
We couldn't treat the Salesforce-to-HubSpot cutover as a lift-and-shift of the existing Marketing Cloud configuration, because the deadline left no time to debug a copied configuration from a platform that was already being retired. Instead we rebuilt each of the 21 daily journeys natively in HubSpot Marketing Hub Enterprise, triggered off the same post-trip survey sends and scheduled sends the programme used. We keyed each one to the booking and trip record tied to the Contact, not to a Marketing Cloud data extension.
The loyalty voucher logic moved onto a Bookings custom object. A workflow trigger fires when a contact's cumulative trip count crosses a threshold, and a separate gate checks voucher eligibility before the voucher is issued. That replaced a scoring model inside Marketing Cloud's journey builder. We carried the post-trip survey sends across as their own journeys, so the eligibility gate stays specific to the voucher and isn't shared logic that a future survey change could break.
We built the trigger against the Bookings object rather than importing a snapshot of historical trip counts. The trade-off is that the voucher logic is only as current as the underlying bookings sync, but we never have to reconcile two trip-count sources again.
The post-trip survey was the first production phase of the move. Under the old design a booking produced a daily CSV export, an FTP pull carried it into Salesforce Service Cloud, Marketing Cloud sent the survey, and the completed response travelled back into Service Cloud: three systems and a chain of scheduled file handoffs, where a missed export or a stalled transfer could hold a whole day's surveys. We retired that chain and rebuilt survey handling natively in HubSpot Service Hub, confirmed functioning by November 2025, and left the reporting format for the results as a separate, later decision rather than let it stall the retirement of the manual flow.
Impact
Campaign changes stop waiting on a Marketing Cloud specialist
Each of the 21 daily email journeys now runs on HubSpot Marketing Hub Enterprise, built against the triggers the marketing team already worked with rather than a data extension only a handful of people could edit. The team can change a send or adjust targeting directly, because the rebuild removed the layer of specialist configuration the old siloed structure required.
The loyalty voucher fires off live trip data instead of a snapshot
The loyalty voucher programme now reads its cumulative trip count directly off the Bookings custom object tied to each Contact, so a passenger crosses the threshold and clears the eligibility gate against actual booking history rather than a periodically refreshed import. That keeps the voucher logic current with bookings as they happen, which the prior version couldn't do.
Consolidated records sharpen who a campaign actually reaches
Migrating more than 92,000 contact records into HubSpot for real-time sync with the CRM gave the rebuilt journeys one consolidated data set to target from, rather than the marketing platform and the CRM holding separate, occasionally conflicting pictures of the same passenger. Targeting accuracy improved because the journeys read from the record the sales and service teams update, not a copy synced on its own schedule.
One deadline cleared two platforms instead of one
Because the CRM migration and the Marketing Cloud rebuild shared the same licence-expiry deadline, we sequenced the journeys and loyalty automation to go live before the cutover rather than running a second migration later. The marketing team never operated against a CRM that had already moved while its journeys still waited on Marketing Cloud.
Each of the 21 daily email journeys runs on the same post-trip survey sends and scheduled sends the programme used, rebuilt natively in HubSpot Marketing Hub Enterprise rather than imported as a configuration snapshot. Every journey keys off the booking and trip record tied to the Contact, so a send reflects the passenger's actual trip history rather than a value copied over in a prior sync.
The loyalty voucher automation reads a cumulative trip-count property on each Contact and fires an event-based workflow when a passenger crosses the loyalty threshold. A separate eligibility gate checks the voucher rules before issuing it, keeping the trigger and the check as two distinct steps rather than one rule.
A Bookings custom object associated to the Contact record stores trip counts and booking history, replacing the trip data Marketing Cloud held in its own data extensions. The loyalty and journey logic both read from this object, so a booking recorded once updates every automation keyed to trip count.
The rebuilt journeys, the survey sends, and the loyalty voucher key off the same Contact record rather than three separate identifiers carried over from Marketing Cloud. Consolidating onto one key let more than 92,000 migrated contact records feed every journey without a separate matching step per automation.
Marketing Cloud's rigid structure meant every journey change needed a specialist, and a Salesforce licence expiry set a hard deadline. Now the 21 daily journeys run natively in HubSpot, keyed to the booking record on each Contact instead of a Marketing Cloud data extension. The loyalty voucher logic sits on a Bookings custom object. A workflow fires when a contact's cumulative trip count crosses the threshold, and a separate gate checks eligibility before the voucher is issued.
FAQ
A straight migration would have carried over the same siloed structure that made changing a journey dependent on a specialist. The licence deadline also left no time to debug a copied configuration from a platform that was already being retired. Rebuilding each journey natively in HubSpot let us key every send to the Contact record directly, so a journey can be adjusted without routing it through anyone else.
The loyalty voucher automation moved off Marketing Cloud's journey builder onto a Bookings custom object, with the cumulative trip count and the voucher eligibility gate built as two separate steps. That means a passenger's voucher status follows their actual booking history rather than a count Marketing Cloud calculated on its own schedule.
