Merging Two CRMs Into HubSpot

You cannot stop selling for a week

The client had outgrown SugarCRM and chosen HubSpot. Straightforward decision. Except that ten years of commercial history lived in the old system, and the business had to keep quoting, selling and supporting customers while the data moved.

The technical migration is a known quantity. Doing it around a company that never stops working is the actual project.

Why this one was hard

Ten years of customisation had turned SugarCRM into a very complicated structure, and almost none of it mapped one-to-one onto HubSpot.

The standard records were full of custom properties built up over a decade. The CRM also held custom record types of its own, each carrying its own data and linked to the standard records through associations. Every property and every relationship needed a decision on where it belonged in HubSpot: a standard object, a custom property, or a custom object built for the purpose. These decisions depend on how the client actually works, so they were made with the client, not for them. And all of it, ten years of it, in large volumes.

Two examples show what that meant in practice.

• Leased equipment. Every piece of equipment leased to a customer was a record of its own, in its own table. It was an asset register living inside the CRM, and standard HubSpot has nothing like it. It needed a structure of its own, still linked to the standard records it relates to.
• Contracts. These were not subscription contracts. They carried their own terms and attachments, with no line items and no link to deals, closer to a document archive than a sales agreement. They moved into a new custom object designed for them.

Data quality made it harder

Ten years of use leaves its mark, and in a structure this complex, quality problems multiply. A duplicate or an invalid record is one problem in a simple CRM, but here it could sit across several linked records.

So the migration needed more than transformation. It needed correction and cleaning, and decisions about which records should not move at all: duplicates and invalid records were identified and kept out, so the new system did not inherit them.

The rehearsal

The weekend was uneventful because it was not the first time.

Every export and every transformation was tested in advance. A week before the real migration, we ran a full mock migration of the whole dataset. It exposed the problems, and we fixed them while the