How Equisoft Replicated Its Zoho Data Model Inside HubSpot Through 5 Custom Objects

Data Zoho Tracked Natively Had No HubSpot Home

1. Contract Terms Lived as a Single Uploaded File.

Zoho tracked contract details as a document attached to the deal, not as structured, queryable data. Left unresolved, contract status would have had no reportable home anywhere in the new CRM.

2. Product Installation Data Had No Dedicated Object.

Which software instance a client ran lived inside a Zoho-specific object type with no HubSpot counterpart. Without one, that tracking layer would have been dropped entirely at cutover.

3. Messaging Configuration Existed Outside Any Standard Field.

Third-party messaging setup was its own Zoho module, distinct from any contact or company property. Migrating without a matching structure meant that configuration data would end up in unstructured notes, if it survived the move at all.

4. Migrated Records Had Nowhere to Prove Themselves Before Going Live.

The five objects and their migrated records had to move into a HubSpot portal the UK team already used daily for other work. An unvalidated migration risked exposing a mismapped object or a broken view directly to end users on day one.

5. The Team's Daily Workflow Was Built Around Zoho's Own Screens.

Staff had learned Zoho's table views for these records over years of use. Building HubSpot's default views without matching that structure risked a workflow regression the team would have felt the day the migration went live.

How Campaign Creators Modeled Equisoft's Zoho Data Inside HubSpot's Custom Objects Framework

Campaign Creators scoped the five-object build as a distinct phase inside Equisoft UK's broader HubSpot onboarding, sequencing object design first, record view design second, and data migration and validation last so migrated records landed directly inside a structure the team could use on day one.

One Object Per Record Type

Zoho's contract, product-instance, messaging-configuration, product-contact, and product-license modules had no structural equivalent inside HubSpot's standard Contacts, Companies, and Deals objects. Campaign Creators modeled each as its own HubSpot Custom Object: Product Instances, Contracts, Messaging Details, Product Contacts, and Product Licenses. Building five distinct objects means each record type carries its own fields, its own creation form, and its own view, so no single Contact or Company record ends up holding data that belongs to a different kind of record entirely.

Records Migrated Straight Into Their Final Structure

The equivalent records already existed inside Zoho and needed to move into the new object structure without a second manual data-entry pass. Campaign Creators ran a one-time, API-based migration that moved the Zoho custom-module records into the five new HubSpot Custom Objects. Migrating directly into the finished object structure meant the UK team's first look at its own data was already inside the system it would use going forward, not a temporary holding structure.

Four Fields Tying Product Contacts to Their Accounts

Product Contacts needed a direct line back to the account it belonged to, not a standalone record. Campaign Creators defined Product Contacts with four fields: Product Contact Name, Product Contact Email, Product Contact Description, and Associated Company Name. The Associated Company Name field keeps every product contact tied to its account, so a contact record stays traceable to the business it came from.

Index Views and Create Forms for All Five Objects

The UK team needed to view and create records across five unfamiliar object types without losing the ability to trace each one back to the account it belonged to. Campaign Creators built dedicated Index Views and Create Record forms for all five objects, anchored by the Associated Company Name field on Product Contacts. Each object type stays visible on its own terms, with that association keeping every product contact traceable to its account.

Validated Before Reaching Daily Use

The five objects and their migrated records had to move into a HubSpot portal the UK team already used daily for other work. Campaign Creators delivered the entire build, including views, forms, and the migrated data, first into Sandbox, then moved it into Production only after that review. Staging the rollout this way gave Equisoft's team a checkpoint to catch a layout or field problem before it reached daily use.

HubSpot Views Modeled on Zoho's Own Screens

The UK team's daily workflow was built around Zoho's own table views for these records, not a blank HubSpot default. Campaign Creators designed the new HubSpot Index Views directly against Zoho's existing table views, matching the layout the team already used. The new views looked like the screens the team had used for years, not an unfamiliar layout introduced on day one.

Impact: A Data Model That Extends Without a Rebuild

Equisoft's five Custom Objects stand independently of Contacts, Companies, and Deals, so adding a sixth object, or a new field to one of the five, touches only that object's own structure. The Sandbox environment used to validate this build gives the UK team a tested space to check any future object or field before it reaches Production.

Solve Custom Data Modeling With Campaign Creators

Businesses migrating off a legacy CRM often find that the platform they are leaving held data types the new system's standard objects were never built to hold: a contract, a license, a product configuration, each treated as its own kind of record, not a property attached to a contact or a company.

Closing that gap takes more than turning on a generic custom-object feature. It takes modeling each record type on its own terms and building the property sets and views a team will actually use.

Campaign Creators builds that structure directly inside HubSpot's Custom Objects framework, reproducing the screens a team already trusts so the workflow carries over unchanged.

Talk to a HubSpot expert to see how Campaign Creators can build a custom data model around your existing tools.