Enterprise CRM Integration

Impact

Problem

A large education group had 300,000+ contacts in a legacy TMS (training management system). Their B2B and B2C sales teams used HubSpot to follow up leads and manage deals, but the actual transactions were recorded in the TMS. Marketing had no visibility from campaign effort through to sales numbers, because the data lived in two disconnected systems.

The legacy TMS had been heavily customized over the years and was messy. Synchronizing two very different systems required careful control over which platform was the source of truth for each data point, and the integration could not corrupt existing data in either system.

My Role

Led integration design and implementation. Worked directly with three teams on the client side: marketing (campaign requirements), B2B/B2C sales (lead follow-up and deal workflows in HubSpot), and their tech team (legacy TMS database and API endpoints). Their tech team handled the legacy system interfaces; my side handled calling those interfaces, designing the sync logic, and managing data consistency between the two systems.

Key Decisions

• Why the technology pivot from PHP to Mulesoft?

  I initially built the integration in PHP. When development reached the testing phase, the client's IT director mandated a switch to Mulesoft. I had never touched Mulesoft before. I designed the flows with a decoupled architecture: main flows handle step-by-step orchestration, sub-flows implement each specific task, passing payloads between stages. HubSpot interactions and GET/POST requests are isolated sub-flows, so when API versions change, only the affected sub-flow needs updating, not the entire integration. I learned the platform from zero and delivered the full migration within 3 months.

• How did you manage source of truth across two systems?

  This was the hardest part. Every data field needed a clear owner. Contact profiles: TMS is source of truth. Lead status and deals: HubSpot. Transactions: TMS, synced to HubSpot for reporting. Getting this wrong would mean sales teams working off stale data or marketing targeting the wrong segments. Each sync direction had to be designed and validated with the respective team before going live.

• What would you do differently?

  Reduce HubSpot API calls. The design processed the previous day's data sequentially. Early on this took 2-3 hours. About 2 years after launch, it had grown to 4-5 hours as data volume increased. The sequential approach was always going to hit this bottleneck. If I were to redesign it, I would batch API calls more aggressively and parallelize where possible.

Architecture

Visual evidence withheld due to client confidentiality.

Legacy TMS (300K+ contacts, transactions, enrolments)
  |
  |-- Client's tech team manages DB + API endpoints
  |
  v
Mulesoft ESB (Anypoint Platform)
  |
  |-- Data transformation: DataWeave + JavaScript/Python
  |-- Field mapping between TMS and HubSpot schemas
  |-- Error handling, logging, environment management
  |
  |-- Sync: TMS > HubSpot
  |     Contact profiles, transaction data, enrolment records
  |     Scheduled batch processing (daily)
  |
  |-- Sync: HubSpot > TMS
  |     Lead status updates, deal progression
  |
  v
HubSpot CRM
  |-- B2B + B2C sales teams: lead follow-up, deal management
  |-- Marketing: campaign targeting against full contact base
  |-- Reporting: full pipeline from marketing effort to sales

Transferable Pattern

Synchronizing data between systems with different schemas and ownership rules. Applicable to any omnichannel operation: syncing POS with e-commerce, CRM with warehouse, or any two systems where "which platform is the source of truth" must be decided per data field.

Tech Stack