Monday.com to HubSpot migration.
Boards were never a CRM. Monday is a superb work tracker that a lot of teams press into service as a CRM. The migration is less a data move than a modelling exercise, because the thing you are moving from does not have contacts, companies or deals — it has boards.
A board knows the row. It does not know the customer.
Every board is its own little database with its own columns, and the relationship between them is a mirror column that only resolves inside Monday. Ask which customers you spoke to twice this quarter and there is nowhere for the answer to live.
The mirror column means nothing outside the board.
Monday — the board boundaryWhat does not exist on the other side.
There is no contact object
People are text in a column, or an item on a contacts board, or both, spelled differently. Building a real contact and company model from that is the migration, and deduplication is most of the effort.
Mirror and lookup columns
They display a value from a linked board and have no independent existence. Exported, they are empty or stale. Each one has to become a real property or a real association.
Subitems have no equivalent
Subitems map to associated records, line items or tasks depending on what they are actually being used for, and different boards use them for different things.
Board automations
Automation recipes are per board and frequently duplicated across boards with small variations. They rebuild as a much smaller set of HubSpot workflows once the model is shared.
Status columns are not stages
Status labels drift, get renamed and mean different things per board. Pipeline design starts from what the sales process actually is, not from the labels that accumulated.
Files, updates and mentions
The conversation lives in item updates with mentions and attachments. It carries as notes on the new record, but threading and mentions flatten, which is worth knowing in advance.
The sequence, start to cutover.
Discovery
Object counts, custom fields, automation and the integrations that will break on the way out, read from the source system rather than from a questionnaire.
Mapping
Field by field, including what will not carry across, agreed and signed before anyone exports anything.
Dry run
A complete rehearsal into a sandbox portal, reconciled against source counts so the gaps surface a month early rather than on cutover night.
Automation rebuild
Workflows, sequences and routing rebuilt to the new model rather than transliterated from the old one, which is how a migration inherits a decade of workarounds nobody remembers writing.
Cutover
A dated switch with the legacy system read-only for a defined window, and a rollback that was tested rather than assumed.
Post-migration support
A named engineer through the first full reporting cycle, which is when the questions actually arrive.
Delivery should probably stay.
The common mistake is moving everything. Monday is better at project delivery than HubSpot is, and the right answer is often a CRM in HubSpot and delivery staying in Monday, joined so a closed deal creates the project without anyone re-typing it. We will tell you when that is the cheaper, better outcome.
What people ask before they commit.
Should we move everything off Monday?
Usually not. Sales and customer data belong in a CRM; project delivery is often better where it is. We draw the line and build the integration across it rather than forcing one tool to do both jobs badly.
How long does it take?
Three to six weeks. Board count and how inconsistently they are structured matter more than the number of items.
Can we keep our board views and dashboards?
Not directly. HubSpot reporting is built on objects and properties rather than board columns, so dashboards are rebuilt. The upside is they then work across the whole business rather than per board.
What happens to our automations?
They get consolidated. Most Monday accounts have the same recipe copied across a dozen boards; once there is one shared data model that becomes one workflow.
Will the team resist the change?
Some will, because Monday is pleasant to use. That is why we build the rep-facing views first and keep required fields to the ones that drive a decision.
Where people go from here.
A model, not a board.
Tell us what you are running
What the system does today, where it breaks, and when it has to work. An engineer reads it — you get an answer inside one business day, not a sequence.