← All case studies
CRM

Centric Software

Centric Software is an enterprise PLM/retail software company that acquired two businesses — Contentserv and ShoppingFeed — each with their own CRM stack (HubSpot + Pardot for Contentserv; HubSpot for ShoppingFeed). Metawork designed and built the integration that consolidates both acquired companies' marketing and sales data into Centric's central Salesforce CRM, enabling unified reporting, lead routing, and pipeline visibility across all three entities.

Duration 13 months
Tasks 241
Meetings 67

Recently touched

  • 2026-05-30 Importing 8k from HS(SF) to SF(Centric) Frozen
  • 2026-05-28 Start sync companies from Shoppingfeed to Salesforce on lifecycle change In Progress
  • 2026-05-14 strategy for handling deals/contracts during cutover Frozen
  • 2026-05-13 Trigger sync to SF Done
  • 2026-04-22 Wrong lead linking in HubSpot Done

The situation

Centric Software is an enterprise PLM company. In the span of about eighteen months they acquired two adjacent businesses — Contentserv (running HubSpot + Pardot) and ShoppingFeed (running HubSpot). Each acquired company brought its own pipeline shape, its own lifecycle stage definitions, its own routing rules. Salesforce was already the system of record at Centric proper.

Until the consolidation work began, every sales meeting that needed «what’s our pipeline across all three entities» started with somebody exporting CSVs from two HubSpot instances and pasting them next to a Salesforce report. Marketing ran on three uncoordinated lifecycle models. Lead routing was manual. Deal-level reporting across the merger was effectively impossible.

The brief

Metawork was brought in to design and build the integration layer that consolidates both acquired-company CRMs into Centric’s Salesforce — without forcing the Contentserv and ShoppingFeed teams to abandon the HubSpot interface they actually liked working in.

Two non-negotiables shaped the architecture:

  1. Salesforce as the single source of truth for sales reporting, forecasting, and cross-entity pipeline visibility.
  2. HubSpot stays in the daily flow for the acquired teams' marketing ops — segmentation, sequences, automation, MQL routing.

That meant building a real bidirectional sync, not a one-way migration.

What we built

The full breakdown is in the tables below. The headline shape:

  • A Make.com routing fabric that syncs contacts, companies, and leads in both directions between each HubSpot instance and Salesforce.
  • Field-level mapping across three different schemas, including lifecycle stages, MQL definitions, and Pardot campaign attribution (the pi__campaign__c field on Salesforce, used for closed-loop reporting back to marketing).
  • Bulk migration for the historical backlog: ~20,000 Contentserv contacts and accounts, plus ~8,000 ShoppingFeed contacts, all moved into Salesforce as the central record, with queue-based processing to handle volume.
  • Conflict resolution + deduplication baked in — the sync engine decides which side wins for each property, per entity, with explicit rules instead of last-write-wins guesswork.
  • Notes + campaign attribution preserved: HubSpot notes become Salesforce ContentNote records; Pardot campaign IDs propagate so marketing attribution survives the move.

What’s running today

The sync engine is in production. As of writing, it has eliminated the manual export/import work that used to happen for every cross- entity report — contact, company and lead data now flows automatically in both directions. The team has stopped opening CSVs.

Roughly 1,168 hours over the engagement, across discovery, architecture, build, bulk migration, and the post-launch stabilisation pass. Split across two formal projects (the architecture phase and the build-and-deploy phase, linked below).

What’s not done yet — and why

We want to be precise about scope rather than oversell outcomes.

  • Deal-level sync is not built yet. The current scope covers contacts, companies, and leads. Deal sync (and the historical deal migration that goes with it) is a separate phase, sized but not scheduled.
  • HubSpot users feel the cost. The Contentserv and ShoppingFeed teams were used to HubSpot’s interface, automation tools, and reporting. Salesforce as their system of record is functionally complete but ergonomically a step down for them. Some of that gap closes with training; some of it closes when we get to deal sync; some of it is a tradeoff the leadership team accepted for the sake of unified reporting.
  • We haven’t claimed a deal-velocity improvement because we don’t have data that supports one. The honest outcome is "fewer manual exports, unified contact/company/lead surface, deal sync still pending." The forecasting and velocity numbers come after the next phase.

What’s reusable

Multi-CRM consolidation after an acquisition is a recurring shape — one we expect to see again. Patterns we’d lift directly into the next engagement:

  • Bidirectional from day one. A one-way «migration» forces the acquired team off their daily tool too early. Two-way sync buys time for the cultural transition and removes the «data is in two places» conflict that kills adoption.
  • Make.com as the routing fabric for high-volume bidirectional syncs across schemas that don’t map cleanly. The queue-based execution model handles the bulk migrations without bespoke ETL.
  • Make the schema mapping a deliverable, not a side effect. The Miro and Google Sheets artifacts from the discovery + mapping phase remain the source of truth for «why is this field mapped this way» — worth its own delivery box.
  • Sequence the scope. Contacts/companies/leads first. Deals next. Reporting last. Don’t try to do all three lifecycles in one sprint — the conflict resolution work compounds.

What it means for you

If you’re a sales or ops lead post-M&A and reading this, the takeaway is: you don’t have to force everyone onto one CRM on day one. A well-architected bidirectional sync buys you the unified reporting at the top without breaking the working ergonomics underneath. The tradeoff is real engineering work — Centric ran for about a year on this — but the alternative is either incomplete data or an angry acquired team. Pick the engineering work.

If that’s the shape of what you need, talk to MetaBot and we’ll scope it.


What was built

Area Description
Discovery & Architecture System stack mapping for Contentserv and ShoppingFeed; stakeholder interviews with sales, marketing, and ops leads across all three companies
Data & Logic Mapping Field-level mapping of HubSpot (Contentserv + ShoppingFeed) properties to Salesforce schema; lifecycle stage logic, MQL routing, workflow and list definitions
HubSpot → Salesforce Sync Bidirectional Make.com integration: Contentserv contacts/companies/leads → Salesforce; ShoppingFeed contacts/companies → Salesforce; with conflict resolution, deduplication, and error handling
Salesforce → HubSpot Sync Reverse sync: Salesforce contact/account/lead changes reflected back into both HubSpot instances
Bulk Migration 20k+ Contentserv contacts and accounts migrated to Salesforce; 8k ShoppingFeed contacts imported; queue-based processing for high-volume runs
Notes & Campaign Attribution Salesforce ContentNote creation from HubSpot notes; Pardot campaign fields (pi__campaign__c) mapped for marketing attribution

Projects

  • Phase 2

    Full build and deployment of the bidirectional HubSpot↔Salesforce integration designed in Phase 1, covering both acquired companies (Contentserv and ShoppingFeed) and the bulk migration of historical…

    What we built

    • HS(CS/SF) Contact+Company → SF
    • SF Contact+Account → HS(CS/SF)
    • SF Lead → HS(CS)
    • Importer Queue
    • ContentNote Creator
    Read case study
  • Salesforce + HubSpot Marriage

    GoogleSpreadsheet - Logins + Data Mapping

    Read case study