Salesforce to HubSpot Migration Case Study: Professional Services

Illustrative. Norbridge Engineering Group is a composite drawn from engagements of this shape. The figures are modelled targets — what this method is designed to produce — rather than measurements taken at a named client. They are internally consistent and should be read as a worked model, not as an audited result.

Abstract

The records were the easy part. A 380-person architecture and engineering firm moved 22,000 accounts, 61,000 contacts, 8,400 opportunities and 460,000 activity records from Salesforce to HubSpot at a field-level fidelity of 99.8 and 99.4 percent, and none of that is what made the engagement difficult. What made it difficult was eleven years of accumulated configuration: 1,140 custom fields, 340 automations and 612 saved reports, of which a minority were still doing anything.

This study documents the archaeology rather than the extract. Its central method is a usage test applied to every configured object — when did this last fire, when was this last run, how many records carry a value — and a three-way decision that follows from it: move, rebuild, or abandon. The firm rebuilt 74 automations of 340 and 41 reports of 612. It also records a capability that could not be reproduced at all, and the two automations the usage test wrongly condemned. Annual cost fell from roughly $148,000 to roughly $63,000, which is the opposite direction from the previous study in this series and is the more common one for this pair.

1. Why an Engineering Firm Leaves Salesforce

Norbridge is a multi-discipline practice — structural, civil and MEP — working mostly institutional and public-sector clients. Its commercial cycle is a pursuit rather than a sale: an RFQ becomes a shortlist, a shortlist becomes an interview, and an award arrives somewhere between six and twenty-four months after the first conversation. Principals sell, in the time left over from billable work.

Salesforce had been in place for eleven years, and it worked. The stated reasons for leaving were not that it lacked a capability, which is worth being precise about because a feature comparison would have found Salesforce ahead on nearly every axis that could be listed.

The binding constraint was the cost of change. A new pipeline stage, a new field on a pursuit, an adjustment to a validation rule — each went into a queue with one contract administrator who visited two days a month, and turned around in about nine business days. A firm whose pursuit process changes with the sector it is chasing had a CRM that could be altered four or five times a quarter, and so it went unaltered and drifted from what people actually did. Second was adoption: 34 percent of principals logged an activity in a given month, and a system recording a third of the client contact is not a record of anything.

Technochange is a useful frame here precisely because it refuses the framing the firm arrived with. Where a system is meant to change how people work, the intervention is neither a software project nor a change programme but both at once, and treating it as a procurement decision — which product wins the comparison — answers a question nobody had (Markus 2004). The question was not which CRM is better. It was which CRM this firm could keep in step with itself.

Annual cost, all in, ran to roughly $148,000: licences, a managed package for proposal assembly, and the contract administrator. The HubSpot arrangement came to roughly $63,000.

2. The Estate, Counted

Before anything was mapped, the configuration was inventoried and — the part usually skipped — measured for use.

The estate held 1,140 custom fields, 340 automations across workflow rules, process builder and Apex triggers, 612 saved reports and 47 record types. The usage figures are the finding. Reports run at least once in the preceding 90 days: 71 of 612. Automations that fired at least once in the same window: 96 of 340. Fields carrying a value on more than 5 percent of their object's records: 402 of 1,140.

None of that indicates incompetence, and reading it that way leads to the wrong remedy. Configuration of this kind accretes because people improvise against the system in front of them — a field added for one pursuit, a report built for one board meeting, an automation to cover one manager's preference — and each addition was locally rational at the moment it was made (Orlikowski 1996). Eleven years of locally rational additions is what an eleven-year-old estate looks like. The question is not who allowed it but which of it is still load-bearing.

3. Determining What Is Still Load-Bearing

Usage data answers that question for most objects and lies about a few, and knowing which is which is the method's whole content.

For reports and fields the test is close to conclusive. A report nobody has run in a quarter is not serving a decision, and a field empty on 95 percent of records is not carrying information. For automations it is weaker, because firing frequency and importance are different properties: an automation that fires twice a year at fiscal close can be the most consequential rule in the system.

Use is a legitimate measure of a system's worth and a poor measure of any single component's, and the difference matters here: the same body of work that establishes use as a dimension of information systems success treats it as an outcome of quality rather than as a proxy for value, which is precisely why a rule that fires rarely can still be the one holding a process together (Delone and McLean 2003). Usage answers what is being used. It does not answer what is needed.

The rule adopted was that the usage test could condemn a report or a field on its own, and could only nominate an automation. Every automation that had not fired in 90 days was read — what it triggers on, what it writes, who notices if it stops — and dispositioned by a person. That is slower and it is the difference between a considered rebuild and a deletion with a plausible justification.

The three-way decision that came out of it is the transferable artefact.

Record types were the one class with no clean disposition. Salesforce uses them to vary picklist values and layouts by business context, and Norbridge had 47; HubSpot expresses the same intent through separate pipelines and property groups, which is coarser. Eleven became pipelines, nine became a property, and the remaining 27 turned out to encode distinctions nobody could articulate when asked.

Move covers records and the fields that carry them. Rebuild covers behaviour that is still wanted and must be expressed in the target's own idiom rather than ported: 74 automations became 61 HubSpot workflows, some merged, and 41 reports were rebuilt. Abandon covers what the usage test condemned and nobody defended.

4. What Could Not Be Reproduced

One capability had no equivalent, and stating it plainly is more useful than the workaround.

Salesforce's sharing model is compositional: an org-wide default, a role hierarchy that grants upward visibility, and sharing rules that open specific records to specific groups. Norbridge used it for something real — a pursuit is visible to its own discipline, to the principals above it, and to another discipline only when that discipline is a named partner on the pursuit.

HubSpot's permission model offers view, edit, delete, merge and communicate, each scoped to records the user owns, records their team owns, everything, or nothing, with an optional allowance for unassigned records. It is coherent and it is not compositional. There is no expression for "visible to this other team, but only on the pursuits where they are a named partner."

The firm's answer had two parts, and only one of them is software. Two genuinely confidential pursuit types — acquisitions and a small number of security-cleared projects — moved into a separate pipeline with restricted team access. Everything else became visible firm-wide, and the policy changed to match: pursuit visibility is now open by default, which is a decision the firm made rather than a constraint it hid.

This is the ordinary shape of package adoption. The gap between a package's assumptions and an organisation's structure is resolved by adapting the organisation, adapting the package, or building at the boundary, and there is no fourth option where the gap does not have to be paid for (Sia and Soh 2007). A firm with a regulatory obligation to compartmentalise should read this section as a reason not to make this move.

5. Where the Arithmetic Moves

Salesforce computes on the record: formula fields and roll-up summaries evaluate in place, so a value can be derived without anything running.

Three classes of computed field existed. Those with a HubSpot calculated-property equivalent moved directly. Those depending on a related record's aggregate — total fees across all pursuits at an account — were rebuilt as workflow-maintained properties, which is not the same thing: the value is now eventually consistent rather than always true, and the reporting had to be checked against that. Timeliness is a data quality dimension in its own right rather than a lesser form of accuracy, and a figure that is correct as of the last workflow run is a different object from one that is correct now — the distinction is invisible on the record and decisive in a report (Wang and Strong 1996). Those that existed to work around a Salesforce limitation were abandoned, which was 19 of 63.

The extract itself was unremarkable and worth one note for planning. Salesforce's Bulk API 2.0 handles both ingest and query jobs asynchronously, and rather than publishing fixed daily thresholds its documentation directs callers to the REST /limits endpoint. The practical consequence is that a migration plan cannot cite a ceiling from a documentation page; it has to ask the org what its ceiling is, and an estimate built on a remembered number will be wrong in one direction or the other.

6. Parallel Running, and Why It Was Rejected

The safe-sounding option was to run both systems for a quarter. It was rejected, and the reasoning is the counterpart to the previous study's rollback window.

Two systems accepting writes produce two records of the same pursuit, and within weeks neither is trustworthy: the reconciliation nobody has time for becomes the thing everybody cites when a number is questioned. The cost of that condition falls on everyone downstream of the record rather than on whoever created the divergence, which is why it is chronically under-priced at the moment somebody proposes it as a safety measure (Redman 1998). Worse for this firm specifically, the population that would have to double-enter is principals — the same population whose 34 percent logging rate was a reason for the project. Asking them to enter twice would have produced a clean measurement of how little they would do it.

What ran instead was a rehearsal into an unused portal, a hard cutover over one weekend, and a support model heavy in the first fortnight. Where a system is meant to change working practice, an incremental approach is often better than a big-bang one — but incremental means sequencing the change, not running two systems of record concurrently, and the two are easy to conflate when someone proposes parallel running as caution (Markus 2004).

7. Modelled Outcomes

Figures below are modelled targets for this method rather than measurements at a named client, as stated at the head of this study.

Annual cost. From roughly $148,000 to roughly $63,000, covering licences, the proposal managed package, and the contract administrator the arrangement no longer requires.

Time to make a configuration change. From about nine business days to same-day, which was the constraint that started the engagement.

Administrator requests. From about 34 a month to 6, the reduction being changes the operations lead can now make without a specialist.

Principals logging an activity in a month. From 34 percent to 78 percent.

Automations in service. From 340 to 61, having rebuilt 74 and merged some of them.

Saved reports. From 612 to 41, rebuilt rather than ported.

Custom fields. From 1,140 to 318.

Field-level fidelity. 99.8 percent on contacts and 99.4 percent on opportunities against a pre-agreed floor of 99.5, with the opportunity shortfall isolated to a currency-rounding difference on historical records.

Time to assemble a pursuit dashboard. From about two weeks of export and reconciliation to live.

8. Limits

The figures are modelled rather than measured, as stated.

The cost reduction is specific to an estate that had grown a specialist dependency around it. A firm running a lean Salesforce configuration that its own operations staff can change will not find $85,000 a year to save, and the comparison in section 1 would be much closer.

The sharing-model gap in section 4 is disqualifying for some firms and was merely inconvenient for this one. Where compartmentalisation is a regulatory obligation rather than a preference, this migration should not be attempted on the strength of anything in this study.

The usage test rests on telemetry the source system keeps. Report run history, workflow execution and field population are all available in Salesforce; a source system with weaker instrumentation gives a weaker test, and the method degrades to reading every object by hand.

Post-implementation experience is where an outcome is really determined, and this study observes four months of it. The evidence on enterprise systems suggests difficulties in that period are frequently misread as defects in the new software rather than as the normal shape of relearning work (Gattiker and Goodhue 2005). A four-month window is too short to distinguish those, and nothing here should be read as a durable result.

The vendor mechanics — the permission model, the bulk API's runtime limits endpoint — were verified against documentation current in August 2026, and the linked documentation rather than this study should be treated as authoritative.

9. The Configuration That Came Back

Two automations were rebuilt in month two, having been abandoned in the migration, and they are the most useful thing in this study because they falsify part of its method.

The first notified the contracts team when a pursuit reached a particular stage with a joint-venture partner attached. It had fired eleven times in three years and not once in the 90-day window, so the usage test nominated it and the person reading the queue agreed. It was missed within six weeks, by which point two joint-venture pursuits had advanced without the contracts review the rule existed to trigger.

The second set a default on a field used only in the annual fee-schedule update. Nobody missed it until the update came round.

Both failures share a shape: a rule whose period is longer than the observation window is indistinguishable from a rule that is dead. Ninety days cannot see an annual cycle, and no amount of care reading the queue fixes that, because the person reading is looking at the same evidence. The correction is not a longer window — a year of history would have caught these and delayed the project by a year — but a different question: rather than asking when a rule last fired, ask what its natural period is, and treat anything annual or quarterly as live until someone argues otherwise.

Implementation is a process of learning through the problems that surface after go-live, and the organisations that come out well are the ones that treat those as information rather than as evidence the project failed (Robey, Ross, and Boudreau 2002). Two rules came back. The method that lost them is otherwise sound and is now one question longer.

10. Conclusion

Eleven years of configuration is not a mess to be cleaned up. It is a record of every occasion on which someone needed the system to do something it did not yet do, and most of those needs have since expired without anyone being told.

The migration's real work was reading that record and deciding what still applies — which is why the useful artefacts are a usage test, a three-way disposition, and an honest statement of one capability that could not come along. The records moved at 99.8 percent fidelity and that number, prominently reported, would be the least informative thing this study could tell anyone. The number that matters is 74 of 340: what was still load-bearing, once somebody looked.

References

Delone, William H., and Ephraim R. McLean. 2003. "The DeLone and McLean Model of Information Systems Success: A Ten-Year Update." Journal of Management Information Systems 19 (4): 9–30. https://doi.org/10.1080/07421222.2003.11045748

Gattiker, Thomas F., and Dale L. Goodhue. 2005. "What Happens After ERP Implementation: Understanding the Impact of Interdependence and Differentiation on Plant-Level Outcomes." MIS Quarterly 29 (3): 559–585. https://doi.org/10.2307/25148695

Markus, M. Lynne. 2004. "Technochange Management: Using IT to Drive Organizational Change." Journal of Information Technology 19 (1): 4–20. https://doi.org/10.1057/palgrave.jit.2000002

Orlikowski, Wanda J. 1996. "Improvising Organizational Transformation Over Time: A Situated Change Perspective." Information Systems Research 7 (1): 63–92. https://doi.org/10.1287/isre.7.1.63

Redman, Thomas C. 1998. "The Impact of Poor Data Quality on the Typical Enterprise." Communications of the ACM 41 (2): 79–82. https://doi.org/10.1145/269012.269025

Robey, Daniel, Jeanne W. Ross, and Marie-Claude Boudreau. 2002. "Learning to Implement Enterprise Systems: An Exploratory Study of the Dialectics of Change." Journal of Management Information Systems 19 (1): 17–46. https://doi.org/10.1080/07421222.2002.11045713

Sia, Siew Kien, and Christina Soh. 2007. "An Assessment of Package–Organisation Misalignment: Institutional and Ontological Structures." European Journal of Information Systems 16 (5): 568–583. https://doi.org/10.1057/palgrave.ejis.3000700

Wang, Richard Y., and Diane M. Strong. 1996. "Beyond Accuracy: What Data Quality Means to Data Consumers." Journal of Management Information Systems 12 (4): 5–33. https://doi.org/10.1080/07421222.1996.11518099

Conflict of Interest Statement

RevOps HQ is a certified HubSpot Solutions Partner and derives revenue from HubSpot implementation and migration work. This study reports a migration onto the platform this firm is paid to implement, and reports a cost reduction as a consequence. Section 8 states the conditions under which that reduction would not apply, and section 4 states a capability the target platform cannot express at all. Readers should weigh the commercial interest against both.

Acknowledgments

The operations lead who read 244 automations one at a time, and argued for keeping eleven of them against the data, was right more often than the usage test was.