Don't Run the Import Again: How We Finished an Insightly to HubSpot Migration

This post is a Loncom Consulting case study - how we migrated a business from Insightly to HubSpot after a first import had already landed part of the data, and why the second import is where most Insightly to HubSpot migrations actually go wrong.

The first import had done what first imports usually do. Some contacts, companies, and deals made it into HubSpot. Some didn't. The team had been working in HubSpot since, editing records as they went. The only link between those HubSpot records and their Insightly originals was a set of ID sheets in the client's clean-up workbooks, and the obvious fix, running the import again, was the fastest way to double the database.

What Was Actually in Insightly

The source was an Insightly XML export, plus the To-Clean-Up workbooks the client's team had been using to reconcile the earlier attempt. On the surface it looked like a standard CRM: contacts, organisations, opportunities, and tasks. Underneath, three things made it anything but standard.

First, the XML export had no pipeline or stage names, so opportunities and projects arrived with no record of where they sat in the sales process. Those names only existed in the workbooks. Second, Insightly Projects were doing two jobs at once: some were genuine equipment installation projects with a pipeline and stage, while others were really equipment records, known internally as "Equipments", stored as projects because Insightly had nowhere better to put them. Third, the water filters at each customer site lived in up to four fixed "slot" fields on the organisation record, not as records of their own.

Notes, emails, and leads were agreed as out of scope from day one, which kept the migration focused on the records the business actually runs on.

What Breaks When You Migrate Insightly to HubSpot?

Every object in this migration had its own way of going wrong. Here is where each Insightly record type landed in HubSpot, how it was matched or routed, and what a straightforward re-import would have done to it.

On narrow screens, scroll sideways to see the full table. Risk reflects how likely each object was to end up duplicated, misrouted, or silently incomplete if it were simply imported again.

Genuine installation projects belonged in HubSpot Projects, but equipment needed a home of its own, so we repurposed HubSpot's Appointments and Listings objects, both of which a Super Admin has to activate first, as Equipments and Water Filters. The routing rule is strict on purpose: anything short of a known pipeline, a known stage, and the Equipment Installation category lands in Equipments, where it can be reviewed rather than half-built into a pipeline.

It's the same gap between "imported" and "actually correct" we hit on a Pipedrive to HubSpot migration where forty custom fields never made the trip. Tools move the data. Knowing what the data means is the real work.

How We Built It: Match First, Write Second

Instead of a one-off script, we built an importer that can run as many times as needed and always arrive at the same result. Every contact, company, and deal passes through three matching layers, in order, and the first hit wins.

The matching order for every contact, company, and deal. Ambiguous matches are reported, never guessed.

The workbook ID maps come first because they already link HubSpot records to their Insightly originals from the earlier attempt. Email, domain, or deal name is only used when the match is unambiguous on both sides, and if an email points at a HubSpot record that another Insightly record has already claimed, nothing is updated or created. The record goes to manual review.

Every matched record is then stamped with its Insightly ID, so matching gets faster and safer with each run. It's the same audit-first thinking behind our WinMan-HubSpot integration architecture: know exactly which record you're touching before you touch it.

Matching decides which record gets updated. Write rules decide which fields. Each mapped field carries one of three modes. Migration-only fields are overwritten whenever the value differs. Shared fields a person may have edited in HubSpot, such as name, email, phone, address, and description, are only filled when they're empty. Pipeline, stage, and owner are protected: set on create, and on update only when HubSpot has nothing there. Blank values from Insightly are never written, so the import can't erase anything, and nothing is ever deleted or merged.

Associations were rebuilt from the links in the XML export: contacts to companies, deals to companies and contacts, and projects or equipment to their company and deal. Existing associations are read first, so the report shows only real gaps. Links between two organisations were reported but never created automatically, because the link itself doesn't say what the relationship is.

Pipeline and stage names were matched from the workbooks to HubSpot pipelines by name, and anything unresolved went into the dry-run report instead of being guessed. That report was the sign-off document: every create, update, and skip per object, with field-by-field differences, project routing, new associations, and warnings. A dry run performs every read a live run does and writes nothing. The live run only happened after the client approved it.

Client data was handled with the same caution. The importer connects through a HubSpot private app limited to the permissions it actually needs, the access token is kept outside the code, and the source exports, which contain personal data, are never stored in the code repository.

Records routed to manual review were resolved with the client as a separate pass. If a previous import has left your CRM in that state, it's worth treating as its own piece of work - see our approach to CRM data cleaning.

Tasks, Files, and Keeping Insightly in Sync

Tasks came from a separate export. Statuses mapped one to one, and each category became a call, an email, or a to-do. Because HubSpot requires a timestamp on every task, the importer falls back through due date, task date, start date, and creation date until it finds one. Tasks are matched by Insightly ID only, so anything created natively in HubSpot is never touched.

File attachments are the part most migrations leave behind. Each file was fetched from the Insightly API, uploaded to HubSpot, and attached to its record through a note dated to the original upload date, so it sits in the right place on the timeline instead of on migration day. Insightly's API allows 10 requests per second and a daily quota set by plan, starting at 1,000 requests a day on the free plan, so tasks are only checked when they show signs of carrying a file, and a local ledger lets an interrupted run resume exactly where it stopped.

Because the business kept working in Insightly during preparation, the importer also runs as an incremental sync from the Insightly API, passing only changed records through the same matching, routing, and reporting. It can't see deletions, because the Insightly API doesn't expose them, so those need a separate check before cutover.

The result is an Insightly to HubSpot migration that can be re-run at any point without creating a duplicate, erasing a field the team edited, or touching a record that was born in HubSpot, with a report for every run that shows exactly what changed and why.

What Should You Check Before an Insightly to HubSpot Migration?

If you're moving from Insightly to HubSpot, especially after an earlier attempt, these checks would have caught every issue in this case study before go-live. For the wider planning side, our Zoho to HubSpot migration guide covers what native tools transfer and what has to be rebuilt.

Frequently Asked Questions

Why not just use HubSpot's native Insightly sync?

For a simple move it can be a good start, but not here. HubSpot's Data Sync app for Insightly shares contacts, leads, opportunities, organisations, and custom objects, and custom field mappings need a paid Data Hub plan (formerly Operations Hub). Tasks, file attachments, and Insightly Projects aren't among its shared objects, and it can't reconcile records left behind by an earlier partial import.

Does the Insightly XML export include everything needed for a HubSpot migration?

Not in this case. It carried the records and their links, but not pipeline or stage names for opportunities and projects, which had to come from separate workbooks. Check what your own export contains before planning around it.

How do you avoid duplicates when re-running an Insightly to HubSpot import?

Match before you write: first against ID maps from the earlier import, then an Insightly ID stamped on HubSpot records, then email, domain, or exact deal name, only when unambiguous. Every matched record is stamped with its Insightly ID, so later runs match directly.

Where do Insightly Projects go in HubSpot?

It depends on what they really are. Here, a project became a HubSpot Project only with a known pipeline, a known stage, and the Equipment Installation category. Everything else went to an Equipments object built on HubSpot's Appointments object.

Do Insightly file attachments keep their original dates in HubSpot?

They can. Each file is attached through a note dated to its original upload date, so it appears in the right place on the record timeline instead of on migration day.

Can Insightly and HubSpot stay in sync while the migration is prepared?

Yes, in one direction. An incremental sync from the Insightly API picks up only records changed in Insightly and applies them to HubSpot through the same matching rules. The limitation is deletions: the Insightly API doesn't expose them, so records deleted in Insightly need to be checked separately before cutover.

How does Loncom Consulting approach an Insightly to HubSpot migration?

As a HubSpot Diamond Solutions Partner, we match before we move. We audit the Insightly export and any earlier import, map each Insightly object to the right HubSpot object, match records in layers so nothing is duplicated, and protect fields your team has already edited. Tasks, file attachments, and associations are migrated too, and you get a full dry-run report to sign off before the first live write.