Salesforce to HubSpot Migration Case Study: Professional Services

Summary

Norbridge Engineering Group, a 380-person architecture and engineering practice, moved from Salesforce to HubSpot after eleven years on the platform. The migration covered 22,000 accounts, 61,000 contacts, 8,400 opportunities and 460,000 activity records, and matched at 99.8 percent on contacts and 99.4 percent on opportunities against a floor agreed before the extract ran.

The data transfer was routine. The work was in the configuration: 1,140 custom fields, 340 automations and 612 saved reports built up over eleven years, with no record of which were still in use. Measurement settled it. In the preceding 90 days, 71 of 612 reports had been run and 96 of 340 automations had fired, and 402 of 1,140 fields carried a value on more than 5 percent of records.

The firm rebuilt 74 automations and 41 reports and abandoned the rest. Annual cost fell from about $148,000 to about $63,000. One Salesforce capability, record-level sharing by rule, has no HubSpot equivalent and was not reproduced. Two automations were abandoned in error and rebuilt in the second month.

1. Why the Firm Left Salesforce

Norbridge is a multi-discipline practice covering structural, civil and MEP engineering, working mostly for institutional and public-sector clients. It sells through pursuits rather than deals: an RFQ becomes a shortlist, a shortlist becomes an interview, and an award lands six to twenty-four months after the first conversation. Principals sell in the time left over from billable work.

Salesforce worked. A feature comparison would have favoured it on nearly every line, and the firm did not leave because something was missing.

It left because change was too slow. A new pipeline stage, a new field on a pursuit or an adjustment to a validation rule went into a queue held by one contract administrator who was on site two days a month, and took about nine business days. The firm's pursuit process shifts with the sectors it chases, so a CRM that could be altered four or five times a quarter went unaltered and drifted from how people actually worked. Adoption followed: 34 percent of principals logged an activity in a given month.

Framing the decision as a product comparison would have answered the wrong question. Where a system is meant to change how people work, the work is neither a software project nor a change programme but both, and the choice turns on fit with the organisation rather than on feature count (Markus 2004). The question was which CRM the firm could keep current.

Cost, all in, was about $148,000 a year: licences, a managed package for proposal assembly, and the contract administrator. The HubSpot arrangement came to about $63,000.

2. The Configuration Inventory

The configuration was inventoried before anything was mapped, and each object was 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. Usage over the preceding 90 days: 71 reports run, 96 automations fired, and 402 fields carrying a value on more than 5 percent of their object's records.

Those numbers are not evidence of poor administration, and treating them that way produces the wrong remedy. Configuration accumulates because people adapt the system in front of them — a field for one pursuit, a report for one board meeting, an automation to suit one manager — and each addition was reasonable when it was made (Orlikowski 1996). The useful question is which of it still does work.

3. Deciding What Was Still In Use

Usage data settles that question for most objects and misleads on a few.

For reports and fields it is close to conclusive. A report nobody has run in a quarter is not informing a decision, and a field empty on 95 percent of records is not carrying information. For automations it is weaker, because how often a rule fires and how much it matters are different things. An automation that fires twice a year at fiscal close can be the most consequential rule in the system.

Use is a reasonable measure of a system's value and a poor measure of any single component's. DeLone and McLean (2003), revisiting their model of information-systems success after a decade of studies, placed use as a consequence of a system's quality rather than as a measure of any component's worth. This is why a rule that fires rarely may still be holding a process together: low use is a fact about frequency, not about value.

The rule adopted was that usage could condemn a report or a field outright, and could only flag an automation for review. Every automation that had not fired in 90 days was read — what triggers it, what it writes, who notices if it stops — and dispositioned by a person. That is slower, and it separates a considered rebuild from a deletion with a plausible reason behind it.

Move applies to records and the fields carrying them. Rebuild applies to behaviour still wanted, expressed in HubSpot's own terms rather than ported: 74 automations became 61 workflows after merging, and 41 reports were rebuilt. Abandon applies to everything usage condemned that nobody defended.

Record types were the one class without a clean disposition. Salesforce uses them to vary picklist values and layouts by business context, and Norbridge had 47. HubSpot covers the same ground with separate pipelines and property groups, which is coarser. Eleven became pipelines, nine became a property, and the remaining 27 encoded distinctions nobody could explain when asked.

4. The Sharing Rule With No Equivalent

One capability did not transfer, and the firm changed its own policy rather than approximate it.

Salesforce composes record access from three parts: an org-wide default, a role hierarchy granting visibility upward, and sharing rules opening specific records to specific groups. Norbridge used all three. A pursuit was visible to its own discipline, to the principals above it, and to a second discipline only where that discipline was a named partner on that pursuit.

HubSpot's permission model grants 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 does not compose. There is no way to express "visible to this other team, but only on pursuits where they are a named partner."

The firm's answer was partly technical. Two confidential pursuit types, acquisitions and a small number of security-cleared projects, moved to a separate pipeline with restricted team access. Everything else became visible across the firm, and the policy was rewritten to say so: pursuit visibility is open by default.

That is the usual shape of adopting a package. Sia and Soh (2007) found that a gap between a package's assumptions and an organisation's structure can be closed only three ways — change the organisation, change the package, or build at the boundary — and that gaps rooted in a firm's regulatory setting are the least amenable to the first. A firm required to compartmentalise by regulation should treat this section as a reason not to migrate.

5. Computed Fields

Salesforce evaluates formula fields and roll-up summaries on the record, so a derived value exists without anything running.

Sixty-three computed fields fell into three groups. Those with a HubSpot calculated-property equivalent moved directly. Those depending on an aggregate across related records, such as total fees across every pursuit at an account, were rebuilt as workflow-maintained properties. That is a weaker guarantee: the value is correct as of the last workflow run rather than at the moment it is read, and the reports built on it were checked against that difference. Timeliness is a distinct data quality dimension rather than a softer form of accuracy, and the gap does not show on the record while it does show in a report (Wang and Strong 1996). The remaining 19 existed to work around Salesforce limitations and were dropped.

The extract itself was straightforward, with one point that affects planning. Salesforce's Bulk API 2.0 runs ingest and query jobs asynchronously, and instead of publishing fixed daily thresholds its documentation directs callers to the REST /limits endpoint. A migration plan cannot quote a ceiling from the documentation; it has to query the org for its own.

6. Why Parallel Running Was Rejected

Running both systems for a quarter was proposed and declined.

Two systems accepting writes produce two versions of the same pursuit, and within weeks neither is trusted. The reconciliation nobody has time for becomes the reason every number is questioned, and the cost lands on everyone downstream of the record rather than on whoever created the divergence, which is why it is underestimated when parallel running is proposed as caution (Redman 1998). The specific problem here was that the people double-entering would have been the principals, whose 34 percent logging rate was among the reasons for the project.

The plan instead was a rehearsal into an unused portal, a hard cutover across one weekend, and heavy support for the first fortnight. Sequencing a change in stages is often better than a single switch, but staging the change is not the same as running two systems of record at once, and the two get conflated (Markus 2004).

7. Outcomes

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

Time to make a configuration change. From about nine business days to same-day.

Administrator requests. From about 34 a month to 6, the difference being changes the operations lead now makes without a specialist.

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

Automations in service. From 340 to 61.

Saved reports. From 612 to 41.

Custom fields. From 1,140 to 318.

Field-level match rate. 99.8 percent on contacts and 99.4 percent on opportunities against a floor of 99.5 agreed in advance. The opportunity shortfall was a currency-rounding difference on historical records.

Time to produce a pursuit dashboard. From about two weeks of exports and reconciliation to immediate.

8. Limits

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

The sharing gap in section 4 was an inconvenience here and would be disqualifying elsewhere. Where compartmentalisation is a regulatory obligation, this migration should not be attempted on the strength of anything here.

The method depends 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 work degrades to reading every object by hand.

This study observes four months after go-live. Difficulties in that period are frequently attributed to the new system when they are the ordinary cost of relearning a process, and four months is too short to separate the two (Gattiker and Goodhue 2005). Nothing here should be read as a durable result.Treat the linked documentation as authoritative rather than this study.

9. The Two Automations That Came Back

Two automations were abandoned during the migration and rebuilt in the second month. They are the most useful finding here because they show where the method fails.

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 it was flagged and the reviewer agreed to drop it. It was missed within six weeks, by which point two joint-venture pursuits had advanced without the contracts review it existed to trigger.

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

Both share a shape. A rule whose cycle is longer than the observation window is indistinguishable from a dead one, and no amount of care in the review fixes that, because the reviewer 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. Ask what a rule's natural period is, and treat anything annual or quarterly as live unless someone argues otherwise.

Implementation problems surface after go-live, and firms that handle them well treat them as information rather than as evidence the project failed (Robey, Ross, and Boudreau 2002). Two rules came back. The method is otherwise sound and now carries one more question.

10. Conclusion

Eleven years of configuration is a record of every occasion someone needed the system to do something it did not yet do. Most of those needs have since expired without anyone saying so.

The migration's real work was reading that record and deciding what still applied, which is why the useful outputs are a usage test, a three-way disposition and a plain statement of the one capability that did not transfer. The records moved at 99.8 percent, and that figure is the least informative number in this study. The number that matters is 74 of 340.

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 result. Section 8 states the conditions under which that reduction would not apply, and section 4 states a capability the target platform cannot express. Client details are pseudonymised.

Acknowledgments

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