Migration
HubSpot to monday CRM migration service
Every HubSpot object becomes a board, and that is both the good news and the whole project. monday CRM has no fixed schema: contacts, accounts, deals, activities and any custom object each become a board of items whose columns you define, linked to one another by connect-boards columns and read across by mirrors. Nothing has to be left behind for want of a slot, which is what separates this crossing from a move into a fixed pipeline tool. The work is designing those boards and their relationships before any row is imported, then rebuilding HubSpot workflows as automation recipes and HubSpot reports as dashboard widgets — both of which have limits your plan sets, and both of which are cheaper to get right on paper than on a live board.
The mechanics
How does HubSpot's object model map onto monday CRM boards?
One board per object: Companies become an Accounts board, Contacts a Contacts board, Deals a Deals board with the stage as a status column, and each custom object a board of its own. Associations become connect-boards columns, properties become typed columns, and workflows become recipes. The shape is yours to design, so it is designed first.
The order of operations is the same in every CRM move — freeze, export, map, load, reconcile, cut over — and it is set out generically on the CRM migration services page. What is specific here is that the destination has no opinion. HubSpot arrives with objects, properties and associations already defined; monday CRM arrives with a template of boards you are free to reshape, and a migration that copies HubSpot's structure one property at a time produces a set of boards nobody would have designed on purpose. The schema is the first deliverable, written before the export runs.
Boards, groups, items and columns are the whole vocabulary. A board is one table of records, a group is a labelled section inside it, an item is a row, a subitem is a child row, and a column is a typed field. That is enough to express every HubSpot object, but each one forces a choice. Does a deal pipeline become its own Deals board, or a group on a shared board, or a value in a status column with a Kanban view per pipeline? Are groups used for territory, for quarter, or for nothing at all? The answer decides what every automation, filter and dashboard widget can see, so it is made once, for the account, rather than board by board as the import goes along.
Associations survive, and that is the part to plan hardest. HubSpot lets a contact belong to several companies and a deal carry any number of contacts, each with a label such as decision maker or billing contact. A connect-boards column can hold several linked items, so those many-to-many relationships do not collapse the way they would in a one-organisation-per-person tool. What a spreadsheet import handles worst is precisely those links, so the load runs in two passes: records first, then the relationships written through the API and keyed on the HubSpot record ID stored on every item. Association labels have no native slot and become a column on the linking item, or a small board of their own where the labels genuinely carry logic.
Properties become columns, and the column type is a decision. A dropdown property becomes a status column with a fixed set of labels, and almost every recipe on the board will trigger off one, so the label set is designed with the automations in mind rather than copied from the HubSpot picklist. Owner becomes a people column, which means every user exists in the account before the first row loads. Calculation and score properties are loaded as static values, then rebuilt as formula columns where the formula still matters. Rich text becomes long text. Per-property history stays behind: monday keeps an item activity log from the moment the item exists, for a period set by plan, and knows nothing of what happened before.
Lifecycle stage has a home, but not the one it had. HubSpot keeps a lifecycle stage and a lead status on the same contact record. monday CRM separates a Leads board from a Contacts board and converts a lead into a contact, an account and a deal when it qualifies. So the lifecycle stages are sorted before export: which become items on the Leads board, which arrive as contacts with a lifecycle column, and which are archived rather than imported at all. Bringing every stage across as a contact leaves the Leads board empty and the qualification recipes with nothing to act on.
Matching, and the ID that turns reconciliation into arithmetic. HubSpot deduplicates contacts on email and companies on domain, so the export it produces through its own record export (opens in new window) is already fairly clean. An import into a board does not enforce uniqueness on either, which means a load run twice, or a delta load that overlaps the first, creates a second item for everyone without complaint. The defence is a column on every item holding the HubSpot record ID. Counts then reconcile by joining on a key rather than by eye, the relationship pass has something stable to look up, and any integration you keep has a foreign key to point at afterwards.
| HubSpot artefact | How HubSpot models it | Where it lands in monday CRM | The decision it forces |
|---|---|---|---|
| Companies | A company object deduplicated on domain, associated to any number of contacts and deals | Items on an Accounts board | Which columns are typed — industry as a status, size as a number — and what mirrors from Contacts and Deals |
| Contacts | Unique on email, able to belong to several companies with a labelled association to each | Items on a Contacts board, connected to one or more accounts | Where the association label goes, since the connect-boards column links but does not describe the link |
| Contacts with no deal yet | A contact carrying a lifecycle stage and a lead status | Items on the Leads board until converted, or contacts with a lifecycle column | Which lifecycle stages are leads, which are contacts, and which are archived instead of imported |
| Deals and pipelines | Several pipelines, each with stages carrying a probability and stage requirements | A Deals board with stage as a status column and a Kanban view, or one board per pipeline | One board or several, and how stage requirements are enforced when a status column cannot demand a field |
| Calls, meetings and tasks | Separate engagement types with their own properties such as call outcome | Entries in the Emails & Activities timeline, or items on an Activities board connected to the record | Whether history worth reporting on needs its own board, since a timeline entry is hard to chart |
| Notes and attachments | Engagements attached to the record timeline | Updates and files on the matching item | How far back to load, since every year of history rarely earns its place on a live board |
| Logged and tracked emails | Email engagements captured by the tracking extension or BCC address | monday's Gmail or Outlook integration, connected fresh at cutover | Whether historical threads are attached as updates, losing threading, or left in the mailbox that already holds them |
| Tickets | A service object with its own pipelines and SLAs | A tickets board connected to Contacts and Accounts | Whether the SLA logic is a recipe, a formula column, or a workflow outside the board |
| Custom objects | Purpose-built records — properties, vehicles, matters, installations — associated to the standard objects | A board of their own, connected to the boards they relate to | What one item represents, and which of its columns other boards need to see as mirrors |
| Custom properties | Text, number, date, dropdown, multi-checkbox, calculation, score and rich-text properties | Text, numbers, date, status, dropdown, formula, long text and other typed columns | Which enumerations become status columns that recipes can trigger on, and which stay dropdowns |
| Products and line items | A product library with line items attached to deals | A Products board, with line items as subitems on the deal or a connected board | Whether deal value is typed in, rolled up from subitems, or mirrored from a connected board |
| Workflows | Enrolment-based, with branches, delays, goals and re-enrolment settings | Automation recipes: a trigger, an optional condition, an action | Which rules rebuild as recipes, which move to a workflow tool, and which are retired on purpose |
| Sequences | Timed one-to-one email and task steps from a rep's mailbox, stopped automatically on reply | monday CRM's own sequences where the plan includes them, or a dedicated outreach tool | How a reply stops the cadence, and whether the plan you are buying covers it at all |
| Marketing emails, forms and landing pages | Built and hosted inside the portal, with send statistics attached | Mass email for the first, a monday form feeding a board for the second, nothing for the third | Which templates are worth recreating, and where the landing pages and their forms live next |
| Lists, reports and dashboards | Active and static lists feeding custom reports | Saved filtered views, and dashboard widgets reading from one or more boards | Which reports anyone opens, and which measure change over time rather than current state |
| Subscription types | Consent held per subscription type plus a marketable-contact designation | A status column per channel on the contact, with no built-in enforcement | How every sending path — mass email, sequences, external tools — is made to honour the column |
Consent is a column you design, and nothing enforces it for you. HubSpot refuses to email a contact who has opted out of a subscription type. A monday board holds whatever value the column holds, and every tool that sends — mass email, a sequence, an outreach platform reading the board through the API — has to be told to filter on it. Export every subscription state, write down the mapping onto the consent columns, load it, and reconcile the counts against the obligations set out in the FTC's CAN-SPAM compliance guide (opens in new window) before any sending is enabled. Nothing goes out until those numbers agree and every sending path has been shown to respect the column.
Sequence
What changes in the plan when the destination is monday CRM?
The order is unchanged: freeze, export, map, load, reconcile, cut over. What changes is where the judgement goes. Coming into monday CRM, it is spent on board design and the two-pass load that links items to one another, and on deciding which HubSpot workflows deserve a rebuild as recipes when every firing counts against a monthly allowance.
Design the boards before the export runs
The schema is yours to write, so write it: one board per object, the column type for every property, and which columns other boards read as mirrors. A board copied from HubSpot's property list has forty columns nobody scrolls to.
Load records first, then link them by ID
Items land in the first pass with the HubSpot ID in a column. The second pass reads the association export and writes the connect-boards links through the API. Relationships are the part a spreadsheet import does not carry, so they are never left to it.
Count the actions before rebuilding every workflow
Each recipe firing spends the plan's monthly automation allowance. A HubSpot workflow that ran quietly on every property change becomes a recipe that empties the allowance in a week, so volume is estimated per rule before any of them are built.
Workflows become recipes, and the allowance is the constraint
There is no converter between the two engines, and each workflow is read and rebuilt by hand. The structural difference is memory. A HubSpot workflow evaluates enrolment criteria against a record, walks it through branches and delays, and remembers that it has been through. A monday automation is a recipe: when a status changes to this, or a date arrives, or an item is created, then do one thing — notify an owner, move the item to a group, set a column, create a connected item. Rules that should fire every time an event occurs rebuild directly and are usually simpler than they were. Long nurture workflows with goal criteria and many branches do not fit and either simplify into two or three recipes or leave the board for a workflow platform with real branching, retries and a run history. The second constraint is commercial: plans carry a monthly allowance of automation and integration actions, and a rebuild that reproduces every HubSpot workflow as a recipe firing on every column change spends it fast. So each rule gets a volume estimate before it gets built, and the high-volume logic — syncs, enrichment, anything that loops — goes above the board rather than on it.
Reports become dashboard widgets, and the widget reads boards
A HubSpot custom report is a query over object data with history attached. A monday dashboard is a set of widgets — numbers, charts, a funnel, a leaderboard, a timeline — each reading from one or more boards, with the number of boards a dashboard can read from set by plan. Reports of current state rebuild well and often look better: pipeline value by stage, deals by owner, activities logged this week, open tickets by account. Reports of change over time do not, because monday computes stage duration and conversion from changes it witnessed, and it witnessed nothing before the import. That means time-in-stage and stage-conversion history stays behind whichever way the load is done, and the HubSpot reports worth keeping are exported and archived before cutover. It also means the board design decides the reporting: a stage held in a status column can feed a funnel widget, while a stage expressed as a group cannot feed the same widget the same way, and that is settled while the boards are still on paper.
Email, activities and what belongs to the mailbox
HubSpot's tracked and logged emails feel like CRM data because they sit on the timeline, but the mailbox holds the messages and the CRM holds a reference. monday CRM's Gmail and Outlook integrations connect to the same mailbox and start logging into the Emails & Activities timeline from that point, with historical threads staying where they have always been. Threads that genuinely need to be on the record — an agreed scope, a pricing exception — can be attached as updates, at the cost of threading. Calls, meetings and tasks are a separate decision: the timeline holds them, but a timeline entry is hard to chart, so a team that reports on activity volume by rep gets an Activities board connected to the records instead, and the recipes that create tasks write there.
Cutover, reconciliation and disposing of the export
Cutover runs one pipeline at a time. Item counts are compared in both directions on the stored HubSpot ID, connect-boards links are counted against the association export, consent counts are compared separately, and a delta load picks up whatever was created during the freeze window. The HubSpot portal stays live and read-only for a lookback period, because per-property history and marketing statistics do not migrate and are still worth being able to open — and because every form, meeting link, chat widget and tracking script still pointing at it has to be found and replaced before it can be switched off. One step is easy to skip: the export is a complete copy of your customer database sitting in a folder, on a laptop, and probably in a shared drive as well. Destroying those working files at the end of the project — deliberately, everywhere they were copied, along the lines of NIST's media sanitization guidelines (opens in new window) — is part of the work, not an afterthought. So is token ownership: the relationship pass and any integration you keep run through the monday.com API (opens in new window) on a token that inherits its creator's permissions, and a token owned by whoever ran the migration is a token that dies when they leave.
Where this sits next to the rest of the work
The same source lands very differently elsewhere. A team leaving HubSpot for a plain sales pipeline faces the opposite problem to this page — deciding what has no slot rather than designing the slots — and our HubSpot to Pipedrive migration page leads with that list. A team that wants the marketing suite, the funnels and the texting to come along rather than be re-homed is usually heading somewhere else again, and our HubSpot to GoHighLevel migration page covers that crossing. If you are coming to monday CRM from Pipedrive instead of HubSpot, the source is a fixed sales pipeline rather than a suite, and our Pipedrive to monday CRM migration page covers that move. Going the other way — off monday.com and onto HubSpot — is its own project, and our Monday.com to HubSpot migration page covers that direction. Once you have landed, making the boards work — label discipline, recipe design, the action allowance, connect boards and mirrors, API work — is the subject of our monday.com automation consultant page, which is the right read if you are already on the platform. Teams often move the delivery side in the same quarter; that is a different crossing with different objects, and our Asana to monday.com migration page covers projects, tasks, subtasks and dependencies rather than contacts, deals and pipelines. And if the honest answer on the call is that HubSpot still fits and the real problem is how it has been configured, our HubSpot automation consulting page describes that work instead, while how engagements work explains how a scope gets agreed before any of it starts.
The honest part
Why move from HubSpot to monday CRM at all?
Usually because the team already runs projects, onboarding or delivery on monday boards and wants the pipeline on the same surface, with a closed deal handing straight to the board that fulfils it. The trade is real: you give up a fixed CRM schema and a marketing suite for a work platform you have to design. Whether that trade suits you is what the first call is for.
| What | Treatment | Why |
|---|---|---|
| Company, contact and deal field values | Moves | They load cleanly once every column exists with the right type and every status label has been created first |
| Open deals and stage position | Moves | Stage, value, close date and owner land on a deal item once the status labels and the users exist in the account |
| Associations between records | Moves, in a second pass | Connect-boards columns hold several links, so many-to-many survives, but the links are written through the API rather than imported |
| Custom objects and tickets | Moves, as boards | Anything HubSpot held as an object becomes a board connected to the others, which is the strongest argument for this direction |
| Notes, files and logged activities | Moves deliberately | They attach to the matching item, which is worth doing for open business and rarely worth doing for all history |
| Products and deal line items | Moves | The Products board is built first, then line items attach as subitems or connected items — in that order, or the lines reference nothing |
| Lifecycle stage and lead status | Rebuilt as a Leads board and a lifecycle column | monday CRM separates leads from contacts and converts between them, so the funnel position is expressed by which board an item is on |
| Association labels | Rebuilt as columns | A connect-boards column links but does not describe, so the label lives on the linking item or on a small board of its own |
| Workflows | Rebuilt as recipes, or relocated | A different execution model and a monthly allowance, so each rule is re-expressed, volume-estimated and re-tested |
| Reports of current state | Rebuilt as dashboard widgets | Widgets read live board data, and most of what a sales manager opens weekly is a question about now |
| Per-property history, time in stage, conversion rates | Stays behind | HubSpot keeps a change trail per property; monday keeps an activity log from import onward, for a period set by plan |
| Marketing email content and send statistics | Stays behind | Send-level analytics belong to the system that did the sending, and templates are recreated rather than imported |
| Logged email threads | Re-established, not migrated | The mailbox owns the messages; both systems only hold a reference, so monday connects and starts logging from cutover |
| Forms, landing pages, meeting links, tracking code | Replaced | Anything still calling HubSpot keeps creating records there after cutover, and nobody notices for weeks |
You own the result outright: boards in your own monday account on your own tokens, recipes documented against the trigger that starts them and the allowance they spend, a column map showing where every HubSpot property went, a written note of where each function that left the CRM now lives, and an equally written note of what was left behind on purpose. If your own team would rather run the load, we will design the boards, build the column map and the relationship pass, and stay on as backup — and if the honest answer on the call is that HubSpot still suits you better than a set of boards would, that is what you will hear.
Questions
What HubSpot teams ask before committing to boards
Do HubSpot associations survive the move to monday CRM?
Mostly, yes, because a connect-boards column can hold several linked items. A contact linked to two companies stays linked to two accounts, and a deal keeps all of its contacts. What has no direct slot is the association label — decision maker, billing contact — which becomes a column on the linking item or a small board of its own. The links are written through the API in a second pass, keyed on the HubSpot ID stored on every item.
Do HubSpot workflows convert into monday automations?
No. A HubSpot workflow enrols a record once and walks it through branches and delays. A monday automation is a recipe — a trigger, an optional condition, one action — that fires every time the trigger occurs and counts against a monthly action allowance set by your plan. Stage-change, notification and date-stamping rules rebuild directly. Long branching nurture workflows either simplify into a few recipes or move to a workflow tool outside the board.
What happens to HubSpot custom objects in monday CRM?
Each one becomes its own board, linked to Contacts, Accounts or Deals by a connect-boards column. That is the reverse of a move to a fixed pipeline tool, where custom objects have nowhere to go. The decision is not whether the object fits but what one item represents, which columns are typed rather than free text, and whether the records other boards need to see arrive as mirror columns or as a rollup.
Can HubSpot reports and dashboards be rebuilt in monday CRM?
Reports of current state rebuild well: pipeline value by stage, deals by owner, activities this week, all as dashboard widgets reading from one or more boards, with the number of boards a dashboard can read from set by plan. Reports that measure change over time — stage conversion, time in stage, velocity — do not, because monday only knows history it witnessed after import. Those HubSpot reports are exported and archived before cutover.
How does marketing consent carry from HubSpot to monday CRM?
As columns you design, enforced by whatever does the sending. HubSpot holds consent per subscription type plus a marketable-contact designation; monday CRM has no built-in subscription model, so each channel becomes a status column on the contact and every send — mass email, sequence or an external tool — is filtered on it. The states are mapped on paper, the counts compared, and anyone unsubscribed anywhere lands as unsubscribed before any sending is enabled.
Free consultation
Tell us what is costing you the most time
Describe the process. You get a straight read on whether it is worth automating, roughly what it would take, and what we would tackle first — on a call that costs nothing.
- Under an hour, free, and no obligation
- Fixed price per stage, agreed before any work starts
- You own everything we build, documented and in your accounts
- If you do not need us, we will say so on that call
The form is the fastest way to reach us — we reply from a real person, usually within one business day.
Not sure which migration is right? See the CRM migration services overview.