Zoho to HubSpot Migration Case Study: Wholesale Distribution

Illustrative. Thornquist Supply 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

A CRM migration is usually described as a data-movement problem and is mostly a decision problem: what the source actually contains, which of it has any destination in the target's object model, how much of the remainder is worth carrying, and what fidelity the business will accept before anyone begins. This study documents the move of a $95 million industrial supplies distributor from Zoho CRM to HubSpot, in which 96,000 of 214,000 source records were migrated and the other 118,000 were deliberately left where they were.

The study is unusual in this series for spending most of its length on subtraction and on the honest arithmetic of the decision. Annual licence cost rose from roughly $16,800 to roughly $58,000, which is a real argument against moving and is stated here rather than buried. What the firm bought for that was reporting it could not previously produce, a duplicate rate falling from 17 percent to 2, and a quote turnaround falling from 3.5 days to 1.1. The cutover held a read-only window of 11 hours against a planned 36, and a rollback path that stayed open for fourteen days and was never used.

1. The Case for Moving, and the Case Against

Thornquist distributes fasteners, safety equipment and cutting tooling to contractors and manufacturers across the upper Midwest — about 30,000 SKUs, 2,800 active accounts, 22 outside reps and 12 inside sales staff. It had run Zoho CRM for six years.

The case against moving should be stated first, because it is stronger than the genre usually admits. Zoho worked. It held the account base, the reps used it, and it cost about $16,800 a year. Migrations are expensive, disruptive and risky in ways that are difficult to price in advance, and the correct recommendation for most firms in that position may well be to stay and fix what is wrong in place. A CRM that is disliked is not the same as a CRM that is unfit, and the two are routinely confused in the room where this decision is made.

Three things made this case different, and only the third is really about the software. Reporting had become the binding constraint: producing a rep-level pipeline view took about two days of exporting and reconciling in a spreadsheet, and so it was produced monthly and trusted by nobody. The marketing function had been bought separately and did not share a contact record with sales, so the same customer existed twice with two engagement histories. And the firm had decided to put quoting into the CRM, which its ERP could not surface and which its Zoho configuration had been extended toward twice without success. The first of those is the one that generalises: managing customer relationships as a set of processes requires that the processes be measurable, and a report that takes two days to assemble is not a measurement anyone will take often enough to manage against (Reinartz, Krafft, and Hoyer 2004).

The relevant question is not which product is better but which fits the organisation's structure and processes, and misalignment between a package's assumptions and the adopting firm's shape is the more reliable predictor of an unhappy implementation than any feature comparison (Hong and Kim 2002). Thornquist's shape had moved; the fit had not.

Licence cost rose to approximately $58,000 a year, before implementation. Nothing in this study argues that the increase was small.

2. What the Source Actually Contained

The first phase was an inventory, and it was conducted before any mapping was drawn, because the mapping a firm expects to need is a description of what it believes the source holds rather than what it holds.

Zoho contained 214,000 records across the modules in scope: 61,000 Leads, 38,000 Contacts, 11,400 Accounts, 9,200 Deals, 84,000 Activities, and roughly 10,400 notes and attachments. The distribution was the first finding. Of the 61,000 leads, 47,000 had never been converted, and 31,000 of those had no activity in five years or more — an accumulation that is entirely normal and that nobody had ever been asked to look at.

Quality was assessed by dimension rather than as a single judgement, because the dimensions moved independently and an aggregate would have hidden the one that mattered. Completeness was reasonable on contacts and poor on deals: 61 percent of open deals carried a close date. Accuracy was untestable in bulk and was sampled. Consistency was the worst of them — 17 percent of accounts were duplicates, mostly the branch-versus-parent problem endemic to distribution, where the same customer buys through three sites under three spellings. Treating quality as a set of separately assessable dimensions is what makes a migration plan tractable, and collapsing them into "the data is messy" is what makes it unplannable (Wang and Strong 1996; Batini et al. 2009).

The deeper point about the duplicates is that they were not errors of entry. Each record was created by a person acting correctly on the information in front of them, and the defect is in the representation rather than the keystrokes — a distinction that decides whether the fix is training or a data model (Wand and Wang 1996).

3. The Objects With No Destination

The mapping exercise produced a category the firm had not anticipated: source objects with no target to map to at all.

The largest is Leads. Zoho models a lead as a distinct record that is later converted into a contact, an account and a deal; HubSpot has no equivalent object, expressing the same idea as a lifecycle stage on a contact. A converted Zoho lead therefore has an obvious destination, because its contact and account already exist. An unconverted lead has none, and the 47,000 of them had to become contacts at an early lifecycle stage, or not move.

Sales Orders and Invoices were the second. Both exist as Zoho modules and neither has a native HubSpot counterpart that would hold them as records of financial fact. The decision taken was to leave both in the ERP, which was already their system of record, and to carry into HubSpot only a summary property on the company. That is a smaller migration and a better architecture, and it was contested at the time on the grounds that reps liked seeing order history in the CRM.

Packaged systems embed assumptions about how a generic business works, and the adopting organisation resolves the gap by adapting itself, adapting the package, or building at the boundary (Sia and Soh 2007). A migration forces that choice to be made explicitly and all at once, which is uncomfortable and is also the single most valuable thing about doing one.

Mechanically, both platforms were cooperative. Zoho's bulk APIs are asynchronous — a job is submitted, and its result collected later — which suits an extract of this size and means the extract is a scheduled operation rather than a long-running script somebody must watch. On the destination side, HubSpot's import supports multiple objects in one file and creates the associations between them from that file, which removed an entire class of association-stitching work the plan had originally budgeted for. Its documentation does not state a row limit, so the practical ceiling was established by testing rather than assumed.

4. What Was Deliberately Left Behind

118,000 of 214,000 records did not move. The list is the most transferable part of this study, because every migration faces the same decisions and most make them by default rather than on purpose.

The 31,000 unconverted leads with no activity in five years were left. They were exported to cold storage, and the argument for moving them — that someone might one day work them — did not survive the observation that nobody had worked them in five years while they sat in a system everyone had open all day.

Activities older than three years were left, 52,000 of them. The retained three years covers every account's last full buying cycle and then some. What this loses is the ability to answer questions about 2019, and the firm accepted that in writing, which matters more than the decision itself.

Attachments were left in place and linked rather than carried, on volume grounds, with the exception of executed contracts.

Closed-lost deals older than two years were left, which was the only decision that later drew complaints, from a sales manager who used them for win-rate analysis.

The rule that produced these decisions is worth stating plainly, because a migration without one moves everything by default and inherits the source's accumulated disorder along with its data: a record moves if someone can name the question it answers. Not the theoretical possibility of a question — a question, asked by an identifiable person, in the last year. The cost of poor data quality is rarely paid at the moment of entry and is instead paid continuously afterwards by everyone reading it, which is why importing a record with no reader is not a neutral act (Redman 1998).

5. Fidelity, and How It Was Measured

Fidelity was defined before the extract ran, in a document both sides signed, because a tolerance agreed after the result is known is not a tolerance.

Three checks were specified. A count reconciliation per object, requiring an exact match between records extracted, records loaded and records rejected, with every rejection individually accounted for rather than netted. A field-level audit on a random sample of 500 records per object, comparing every mapped field between source and target and requiring a 99.5 percent match rate. And a set of business assertions — total open pipeline value, count of accounts with an owner, count of deals with a close date — computed on both sides and required to agree.

The field-level audit achieved 99.7 percent on contacts and 99.2 percent on deals. The deal shortfall was a single, characteristic class of failure: Zoho permitted values in some picklist fields that the corresponding HubSpot dropdown property did not define, and the import dropped those values rather than rejecting the rows carrying them. Nothing errored. The records arrived, complete except for a field that was silently empty — which is exactly the failure a count reconciliation cannot see, and the reason the field-level sample exists at all.

Assessment methodologies in the data quality literature are explicit that different checks detect different defect classes, and that a programme relying on one of them inherits a blind spot rather than a smaller one (Batini et al. 2009). The three checks here were chosen to fail differently.

Two further points about that failure are worth recording. It was found by the sample rather than by anyone noticing, and it would not have been found at all by a check that only compared totals. And the remedy was not to widen the target property to accept every source value: 23 of the offending values were themselves data-entry noise, and defining them into the new system would have migrated the disorder along with the data.

6. The Cutover and Its Rollback Window

The cutover ran over a weekend, in a sequence designed so that the irreversible step happened as late as possible.

A full extract and load ran two weeks before go-live into a HubSpot portal nobody used, which is where the picklist failures were found. The rehearsal appears to be the step most often cut for time, and it is the one that tends to pay for itself. On the cutover weekend, Zoho was set read-only, a delta extract carried everything changed since the rehearsal, the three fidelity checks ran, and the portal was opened to users on Monday morning. The read-only window was planned at 36 hours and took 11, the difference being almost entirely that the delta was small because the rehearsal had been recent.

Rollback deserves more attention than migration write-ups usually give it. The plan kept Zoho live, in read-only, for fourteen days after go-live, with a documented path to reverse: reopen Zoho for writing, replay the fourteen days of HubSpot changes by hand, and abandon the new portal. Its cost was estimated at roughly $40,000 and three weeks. It was never exercised. The value of having it may not have been the option itself so much as the effect on the decision to go live, which was taken on the evidence of the checks rather than on the impossibility of turning back.

7. The First Four Weeks

What happens after a system goes live is a weaker predictor of anything than it should be, because most accounts of implementations stop at go-live. The evidence available suggests the post-implementation period is where the outcome is actually determined, and that difficulties in it are frequently misread as defects in the software rather than as the normal shape of learning a new system (Gattiker and Goodhue 2005).

Support tickets ran at 47 in the first week and 6 by the fourth. Their composition is more useful than the count: the great majority of week-one tickets were about where a thing had moved to rather than about a thing being wrong, which is the profile a migration wants. Three were genuine defects, all in the quoting configuration rather than in migrated data.

Adoption was not left to the system's merits. Every rep had a 90-minute session on the workflow they personally ran, not a tour of the platform, and the pipeline report that had taken two days was rebuilt first and shown to the sales managers in week one — on the reasoning that people adopt a system when they expect it to help them do the work in front of them, and that a visible early win is worth more than a complete configuration (Venkatesh et al. 2003).

8. 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.

Records migrated. 96,000 of 214,000, with the remaining 118,000 deliberately excluded under the stated rule and exported to cold storage rather than deleted.

Duplicate account rate. From 17 percent to 2 percent, resolved during migration rather than after it, because merging in the source before the load tends to be cheaper than merging in the target afterwards.

Field-level fidelity. 99.7 percent on contacts and 99.2 percent on deals against a pre-agreed floor of 99.5, with the deal shortfall isolated to one identified failure class.

Deals carrying a close date. From 61 percent to 98 percent, achieved by making the field required at stage entry rather than by correcting history.

Time to produce a rep-level pipeline report. From about two days of manual export and reconciliation to minutes, which was the constraint that started the engagement.

Quote turnaround. From 3.5 days to 1.1.

Cutover read-only window. Planned at 36 hours, actual 11.

Support tickets. From 47 in week one to 6 in week four.

Annual licence cost. From roughly $16,800 to roughly $58,000, before implementation cost. This is the figure most likely to decide whether the architecture above is right for a given firm.

9. Limits

The figures are modelled rather than measured, as stated, and show the shape of the method rather than evidencing its results.

The cost increase is the study's most important limit. A distributor with the same data problems and no reporting constraint would be better served by remediating Zoho in place, and the fact that this engagement did not test that alternative is a weakness in the evidence rather than an argument against it. Nothing here establishes that migration was the cheapest available fix; it establishes what a migration costs when it is done deliberately.

The retention decisions in section 4 are specific to a business with a buying cycle measured in months. A firm with multi-year capital sales, or one with a regulatory retention obligation, would keep materially more and should not read the three-year activity cut-off as a benchmark.

The fidelity floor of 99.5 percent was negotiated, not derived. It is a number the business was willing to accept, and a different business would set it elsewhere. What transfers is that it was set in advance and in writing.

The platform behaviours described — the asynchronous bulk extract, the multi-object import and its association handling — were verified against documentation current in August 2026, and the linked documentation rather than this study should be treated as authoritative. The picklist behaviour in section 5 is an observation from this implementation, not a documented guarantee, and should be tested rather than assumed.

10. What a Second Attempt Would Do Differently

Three things, and the first is the one most likely to transfer.

The picklist reconciliation would happen before the rehearsal rather than being discovered by it. Every source picklist's distinct values are enumerable with a query, and comparing that list against the target property's definitions is an afternoon of work that could have removed the largest single fidelity failure in the project. The values that broke it were not typing errors but legitimate entries the target's representation did not admit, which is the distinction that decides whether the remedy is correction or redesign (Wand and Wang 1996).

The closed-lost retention decision would be taken with the sales manager who used those records in the room. The rule — a record moves if someone can name the question it answers — was applied correctly, and the person who had the question was not asked. That is a failure of consultation rather than of method, and it is the kind that makes a good rule unpopular.

The rollback window would be shortened from fourteen days to seven. Fourteen was chosen for comfort, and the cost of holding it was that the delta of changes needing manual replay grew every day it stayed open, which made exercising it steadily less feasible while making everyone feel steadily safer. An option that becomes less usable the longer it is held should be sized honestly.

11. Conclusion

The parts of this migration that could go wrong technically mostly did not. The extract worked, the import worked, the associations arrived, and the weekend ran short of its window. What appears to have determined the outcome was a set of decisions taken before any of that: which records had a reader, what fidelity would be accepted, what would be left in the system it already belonged in, and how long the way back would stay open.

A migration is where a firm is forced to say out loud what its data is for. Thornquist moved 96,000 records and left 118,000, and the second number was the harder work and the more valuable one. The alternative — moving everything because it is there — produces a new system containing an old system's accumulated disorder, at which point the firm has paid for a migration and bought a copy.

References

Batini, Carlo, Cinzia Cappiello, Chiara Francalanci, and Andrea Maurino. 2009. "Methodologies for Data Quality Assessment and Improvement." ACM Computing Surveys 41 (3): Article 16. https://doi.org/10.1145/1541880.1541883

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

Hong, Kyung-Kwon, and Young-Gul Kim. 2002. "The Critical Success Factors for ERP Implementation: An Organizational Fit Perspective." Information & Management 40 (1): 25–40. https://doi.org/10.1016/S0378-7206(01)00134-3

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

Reinartz, Werner, Manfred Krafft, and Wayne D. Hoyer. 2004. "The Customer Relationship Management Process: Its Measurement and Impact on Performance." Journal of Marketing Research 41 (3): 293–305. https://doi.org/10.1509/jmkr.41.3.293.35991

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

Venkatesh, Viswanath, Michael G. Morris, Gordon B. Davis, and Fred D. Davis. 2003. "User Acceptance of Information Technology: Toward a Unified View." MIS Quarterly 27 (3): 425–478. https://doi.org/10.2307/30036540

Wand, Yair, and Richard Y. Wang. 1996. "Anchoring Data Quality Dimensions in Ontological Foundations." Communications of the ACM 39 (11): 86–95. https://doi.org/10.1145/240455.240479

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 documents a migration onto the platform this firm is compensated to implement, and reports a threefold increase in licence cost as a consequence of that move. Section 1 states the case against migrating and section 9 states that the cheaper alternative — remediating the incumbent system in place — was not tested. Readers should weigh the commercial interest accordingly.

Acknowledgments

The sales operations analyst who reconciled 500-record samples field by field, three times, found the one defect that every automated check in the plan would have passed.