Salesforce to HubSpot Migration

Every contact that syncs can burn through as many as four Salesforce API calls, and your Salesforce edition and licence set the ceiling on how many calls exist to spend in a day. HubSpot's 'Allocated to HubSpot' setting then caps the integration's own share of that ceiling within each rolling 24-hour window, so a large initial sync competing with everyday Salesforce use for the same pool of calls is how a migration stalls partway through without anyone touching a setting.

Workaround: Four levers exist, and it is worth knowing all four before the sync ever runs close to its limit: watch usage on the Sync Health tab, raise or lower the 'Allocated to HubSpot' setting, narrow the volume with inclusion lists or selective sync, or move to a higher Salesforce edition for more calls outright. In a Gulf group running several entities off one Salesforce contract, the edition upgrade is rarely yours alone to decide: it is a licensing cost that needs sign-off from whoever holds that contract, not just the project team running the migration.

Fifteen minutes is the shortest gap the standard sync allows between a change in one system and its arrival in the other: HubSpot polls for updates on that cycle rather than pushing them the instant they happen. Where WhatsApp and a phone call are the real record of a conversation and the CRM update follows some minutes behind it anyway, that gap rarely matters. It matters a great deal on a live tender or a fast-moving deal where two people are working the same account from different systems and neither can see what the other just did.

Workaround: Where near-real-time actually matters, HubSpot's Data Hub Data Sync closes the gap to seconds rather than minutes, or a custom API integration can be built to the same effect. Either is a genuine cost line, so decide whether the fifteen-minute default is actually a problem for your sales process before budgeting for either fix.

Nothing about a product or a line item crosses the connector in either direction: an opportunity syncs as a deal, but the products and priced line items sitting on it stay behind in Salesforce. What lands in HubSpot is a deal with a value and a stage and no record of what was actually being sold, at what price, in what quantity or in which currency, a serious gap for a business quoting the same product in AED, SAR and USD across a Gulf group.

Workaround: Rebuild the product catalogue directly in HubSpot rather than waiting for it to arrive: a CSV import or an API script carries the line item data across, and a third-party tool such as Commercient or a purpose-built API integration can do the same job at scale. Do this before quotes start going out of the new system, because a catalogue built once a market is already live in HubSpot means restating every open quote by hand.

Whatever is attached to an opportunity, an account or a contact record in Salesforce stays there: the native integration carries no files or attachments across in either direction. Look at what actually sits in those attachment fields on a regional account: trade licence copies, VAT registration certificates, tender submissions and signed Arabic-language contracts. None of that moves with the record it is attached to.

Workaround: Smart Transfer's one-time attachment transfer is the route to take first, with a third-party migration tool as the fallback for anything it misses. Reserve a manual download-and-reupload pass for a small, named set of critical files only: a hand-carried transfer is exactly where an Arabic filename gets mangled or a document quietly loses the record it was evidence for, the kind of break a compliance review finds long after go-live rather than during it.

A formula field recalculating in Salesforce is invisible to the sync: HubSpot only triggers on a record modification, and a formula's new value is not treated as one, however material the change actually is. A deal that just crossed a discount threshold or a risk score that just flipped can sit unsynced in HubSpot for as long as nothing else on the record changes.

Workaround: Build a small Salesforce workflow that writes the formula's result into an ordinary, non-formula field whenever it changes: that write counts as a modification and pulls the sync behind it. It is a modest piece of Salesforce configuration, but it needs to exist for every formula field the business actually relies on, not just the obvious one.

Mapping only works between compatible types: a HubSpot property and a Salesforce field that disagree on type throw a 'Type mismatch' error, and a picklist carrying more values than HubSpot allows throws an option limit error instead. Picklists are where a regional data model tends to break first: emirate and city lists, free-zone jurisdictions, nationality and language fields, each built up by hand over years until it exceeds what the mapping will accept.

Workaround: Align the field types before a single mapping is created, trim unused picklist options rather than carrying them across, and build fresh HubSpot properties of the right type wherever the existing ones will not do. Settle the language of each picklist in the same pass: a list kept half in Arabic and half in English will not map cleanly and will not report cleanly once it does.

The integration will not accept a Salesforce lookup field on a custom object as a mapping target, so any relationship modelled through a lookup has no path across the sync at all. That is a hard limit exactly where custom objects tend to carry the real structure of a regional business: units linked to towers in real estate, pre-qualifications linked to tenders in construction, licensed entities linked to their group parent in financial services.

Workaround: Swap the lookup relationship for a plain text ID field that carries the linked record's identifier across, then rebuild the associations by hand once the sync has run, or build a custom API-based sync purpose-made for lookup relationships. Whichever route is chosen, put someone who actually knows the entity structure on the re-association pass: a wrong link inside a multi-entity group is not something a validation script will catch.

Custom object sync carries the object across but not automatically the web of associations around it, and an association can only pass at all between two objects that are both already syncing with HubSpot. Turn on custom object sync before the standard objects underneath it are syncing, and the links a regional account structure depends on simply do not form.

Workaround: Sequence it deliberately: confirm every related standard object is already syncing before custom object sync goes live, then map the remaining associations by hand and use workflows to re-create the ones that still do not form on their own. Treat the sequence as a checklist item in the plan rather than an assumption, because it is easy to enable custom object sync first and only discover the ordering problem afterwards.

There is no tier below Enterprise that syncs custom objects at all, and the object itself has to exist in HubSpot, with at least one required field defined, before the sync can even be configured. Where a regional business runs its actual structure through custom objects, units and towers, tenders and licensed entities, that Enterprise requirement is not a nice-to-have discovered mid-project: it belongs in the first budget conversation, because a tier change found partway through a committee-run procurement restarts an approval cycle that runs in months rather than days.

Workaround: There is genuinely no way around this one: an Enterprise subscription is required, full stop. What you can control is the timing, so design the custom object architecture in HubSpot in full before sync is switched on, rather than discovering the gaps in the schema after records have already started to move.

Only the last thirty days of marketing email engagement travels with a contact when it syncs to Salesforce; anything older than that window is simply not carried across and cannot be recovered afterwards by running the sync again. A decision cycle slowed by Ramadan, Eid or the deep summer, which is normal in this market, can be enough on its own to age a whole quarter of engagement data out of that window before the project even reaches the sync step.

Workaround: Pull the historical engagement data out on its own, ahead of the sync, and bring it back in afterwards as custom properties or notes attached to the contact record. Do the export early in the project rather than at the point of cutover, since the thirty-day clock is already running against whatever has not yet been captured.

A contact's form submission history only makes the crossing to Salesforce if it falls inside the twelve months before that contact was synced; anything older is left behind. A long procurement cycle, common enough for an enterprise or public sector deal in this market, can put the original inquiry form on the wrong side of that line before the deal has even closed.

Workaround: Export the older submissions on their own before the window closes on them, and bring them back in through a CSV import or the API rather than accepting the loss. Treat this as one more item on the pre-migration audit list, not an afterthought once the sync is already running.

Take a record off a Campaign in Salesforce and nothing happens on the HubSpot side by default: that removal alone does not trigger a sync. The contact or custom object record has to be independently prompted to sync, by some other field change, before HubSpot's copy reflects that the record is no longer on the list.

Workaround: Trigger the sync on the affected records by hand, or make a small, deliberate update to any other field on the record to set the sync off. Either way it needs to be a step someone owns, because nothing in the platform will flag that a campaign removal is sitting unsynced.

A multi-currency Salesforce org hands over only the bare number: no exchange rate is applied during the sync, and the currency code itself does not transfer with it. For a group pricing the same deal in AED, SAR and USD across its operating entities, that means HubSpot receives figures with no way to tell which currency they were ever in, which turns consolidated revenue reporting across the group into a manual reconciliation exercise rather than a report.

Workaround: Either agree a single reporting currency before the sync runs, or apply the exchange rate conversions by hand afterwards. Whichever the group decides, put the decision in writing before go-live: it is the kind of choice finance across several entities needs to agree on together, not one the project team should make on their behalf.

Einstein Activity Capture logs an email in a form the integration does not recognise: it never becomes a standard task or email activity inside Salesforce, so it never becomes anything on the HubSpot side either. Whoever runs a compliance or audit review on the account afterwards will not find that correspondence in HubSpot at all, and will have no way to know from HubSpot alone that it exists.

Workaround: Either log the emails that matter manually as Salesforce tasks so they take the standard path into the sync, or switch to HubSpot's own email tracking and capture the activity directly on that side instead. Decide which correspondence actually needs to be visible in HubSpot before choosing between the two, since logging everything by hand rarely holds up past the first few weeks.

The word 'campaign' means two different things on either side of this integration: a HubSpot campaign groups marketing assets together, while a Salesforce campaign is a list of members each carrying a status. Because they describe different kinds of object entirely, there is no mapping between them, direct or otherwise, and a strategy built around exhibitions, conference floors and referral tracking inside a group structure has to be rebuilt on HubSpot's model rather than carried across on the name alone.

Workaround: Split the old Salesforce campaign into its two real jobs: HubSpot campaigns for grouping the marketing assets, and lists or active segments for tracking who is actually a member and what their status is. Rebuild it around where regional demand genuinely arrives, exhibition and conference floors, WhatsApp inbound, referral from within the group, rather than reproducing a category list nobody has used since the last event season.

Every Apex trigger running in your instance encodes business logic that has no direct port to HubSpot: each one has to be read individually and sorted into what a workflow or custom code action can reproduce and what needs an external service standing alongside HubSpot instead. A before-save validation trigger is the hardest of the three to replicate, since HubSpot has no equivalent point in the record-save sequence to block or rewrite data before it lands. Line count of the Apex behind each trigger is the honest way to size the work before it starts, not after.

Sort every Apex class in your org into one of four buckets before pricing the rebuild: utility classes, which often turn out unnecessary once HubSpot's native tooling replaces what they did; integration classes, which need rewriting against the HubSpot API; business logic, which becomes a workflow or custom code action; and UI controllers, which get rebuilt from nothing. Total line count and class count across those buckets is what actually drives the estimate, and each significant class runs 4 to 8 hours once identified.

Scheduled and batch Apex jobs typically process data volumes HubSpot workflows were never built to carry, so the question to answer before migration is not whether the logic can be ported but whether the volume behind it can move through HubSpot at all. Where it cannot, an external ETL tool or a scheduled serverless function has to stand in for what batch Apex used to do.

Every Visualforce page in your org is a rewrite, not a port, and the target depends on what the page was actually for: a PDF template moves to HubSpot's own quote templates or an external PDF generator, a custom form becomes a HubSpot form or custom code, and a genuinely complex UI is often enough work to need a separate web application built alongside HubSpot rather than inside it.

Lightning Web Components carry no path into HubSpot at all: each one is a full rewrite, sorted by what it actually does. A simple data display becomes HubSpot record customisation, an interactive tool becomes a CRM extension card, and a full application becomes a separate web app built outside HubSpot entirely. Of everything in a Salesforce migration, this is consistently one of the largest gaps to size, so treat the LWC inventory as its own line item in the estimate rather than folding it into the general rebuild.

Nothing in CRM Analytics, formerly Tableau CRM or Einstein Analytics, carries across: the dashboards and datasets need a complete rebuild in an external BI tool, and the SAQL queries, data recipes and AI predictions behind them do not migrate at all. How sophisticated your existing analytics actually are is what should decide which BI tool replaces it, so size that assessment before choosing one off a shortlist.

HubSpot has no equivalent to a virtual object that shows externally-held data without copying it: External Objects and HubSpot start from a fundamentally different model of where data lives. Three routes exist and they carry different consequences: sync the external data into HubSpot outright, which duplicates it; display it through a CRM card without storing it; or keep separate access to the external system running alongside HubSpot. This is an architecture decision, not a migration task, and it is worth making deliberately rather than defaulting to whichever route looks fastest.

A MuleSoft estate represents real investment, and the migration does not have to throw it away: you can keep MuleSoft in place and repoint its flows at the HubSpot API, or move to lighter-weight middleware if the investment no longer justifies itself. Either way, every flow and API in Anypoint needs individual evaluation, and that evaluation is substantial enough to run as its own workstream alongside the core migration rather than a line inside it.

Treat every Experience Cloud site as a custom web application rather than a configuration to migrate, because that is what it actually is. A customer portal has a home in HubSpot's own Customer Portal and a knowledge base in HubSpot's KB, but a partner portal has no equivalent at all and needs a third-party product, and the same is true of community forums, which need something like Discourse or Khoros running alongside HubSpot. Any custom page beyond those standard patterns is a rebuild from nothing.

Partner Relationship Management sits in a solution category HubSpot does not compete in at all, so if deal registration, partner onboarding or channel marketing runs through Salesforce PRM today, none of it folds into the HubSpot migration: a dedicated third-party PRM has to run alongside HubSpot instead. Treat that as a major line in scope and budget, not a detail to discover once the main migration is already underway.

Of everything in a Salesforce migration, CPQ is consistently among the hardest to move: pricing rules, configuration rules, product bundles and approval chains all need rearchitecting from the ground up rather than a straightforward port. Where CPQ carries real weight in how you sell today, that rearchitecting alone can double the overall migration timeline, so price and schedule CPQ as its own assessment rather than folding it into the general estimate.

HubSpot was never built to replace a financial system, and Salesforce Billing is exactly that: invoicing, payment processing, revenue recognition and usage-based billing all need a dedicated billing platform integrated alongside HubSpot rather than folded into it. Scope this migration as two transitions running together, the CRM move and the billing system move, not one.

they have to be migrated on a separate track, by CSV or by API, and priced correctly across AED, SAR and USD before quotes go out against them

Salesforce and HubSpot mean different things by campaign, so campaign strategy needs a genuine re-architecture rather than a rename, especially where exhibition and conference tracking depends on member status the new object does not carry

only the bare number crosses, which turns consolidated reporting across a multi-entity group into a manual reconciliation unless the currency is standardised or the rates applied by hand afterwards

API call limits can throttle a large initial sync outright, so plan for it to run across several days rather than overnight for any org of real size, and confirm the Salesforce edition's daily allowance before committing to a go-live date

Any email logged through Einstein Activity Capture is simply invisible to the integration, which means a compliance review relying on HubSpot alone will not find that correspondence there at all

A formula field changing value does not trigger the sync on its own, so a workaround field update has to be built for every formula field the business actually relies on, not just the obvious one

Lookup fields on custom objects cannot be mapped through the connector at all, so relational data, the kind that ties units to towers or licensed entities to a group parent, needs a text-ID workaround or a custom API approach instead

Account hierarchies do not carry across on their own, and for a holding company sitting above several operating entities, rebuilding those parent-child links by hand is what keeps a dozen accounts recognisable as one customer

Any marketing email engagement older than 30 days when the contact syncs is gone for good, and a decision cycle slowed by Ramadan, Eid or the summer can be enough on its own to push real engagement history past that window before the project even reaches this step

Trying to move everything in a single weekend is one of the most common ways this fails; a phased approach across a longer calendar, one that accounts for who is actually available to validate each phase, holds up far better

Picklist values have to be standardised and matched exactly between the two systems before sync begins, and settling whether each list is kept in Arabic, English or both belongs in that same pass rather than being decided per record later

their owned records can simply fail to sync if the ownership question is left unresolved, so decide the reassignment before migration rather than discovering the failure afterwards