The Definitive Guide to Migrating to monday.com

monday.com Ltd. (styled in lowercase as monday.com) was founded by Roy Mann, Eran Zinman and Eran Kampf in 2012, launched its platform in 2014, and is headquartered in Tel Aviv, Israel ¹. The company went public on Nasdaq in June 2021. monday Work Management is the general project-and-process product inside a broader Work OS that also includes monday dev, monday CRM, monday service and monday campaigns, all built on the same underlying mondayDB engine and board model.

The typical monday Work Management customer is a delivery team — 20 to 500 people — that runs cross-functional projects, sprints or repeatable processes and wants Gantt views, dependencies, time tracking and recurring tasks in the same workspace as the documents and Updates that go with them.

Compared with Asana or ClickUp, monday positions on the elasticity of a board model where every project artefact is a customisable board rather than a fixed task list; compared with Jira or Microsoft Project, it positions on a flatter learning curve and a visual Kanban-first delivery view that delivery leads can adopt without an admin function.

The shapes of migration that actually land on monday Work Management tend to fall into four patterns. First, Asana, Trello and ClickUp exits, driven by teams that grew out of a single-list tool and want multi-board structure with dependencies and time tracking baked in. Second, Jira moves, usually a non-engineering function (marketing, operations, PMO) that wants the same workflow rigor without the Jira admin surface area.

Third, spreadsheet and legacy replacements — teams running projects on Excel, Google Sheets, Smartsheet or a homegrown database where the schema is loose and the project is really a re-architecture. Fourth, Microsoft Project and Wrike consolidations, where the parent organisation standardises on monday and pulls smaller-team tooling onto it. Each shape has a different profile: an Asana move has clean object parity but no dependency-column equivalent; a Jira move has rich workflow that does not transfer across at all.

What makes migrating *to* monday Work Management easier than the category average is the board model itself — every project artefact is a board you can shape exactly to your process, and the native CSV/Excel importer ships under the Add → Import items button on any board with up to 8,000 rows per file ¹⁰.

What makes it harder than the average is column-type discipline: monday boards do not enforce a schema at the platform level, so the same field on two boards can drift into different types and break Connect Boards and Mirror columns silently ⁴⁶. Pricing is also per-seat across the entire account, billed in tier-stepped seat blocks, so teams that bring in stale users to preserve historical task ownership inflate the seat count and the annual bill.

Automations (recipes), dashboard widgets, time-tracking session history and the Updates thread on each item do not import — they are rebuilt or recreated from documentation. Teams that scope for that work up front finish on time; teams that assume parity do not.

Teams that scope for the rebuild work up front finish on time; teams that assume parity do not.

monday Work Management is built around a simple primitive — the board — and everything else composes from it. A workspace contains folders and boards; a board contains groups (which you typically map to a sprint, phase or stage); a group contains items (which map to tasks); items can have subitems (which map to subtasks); and items carry column values plus an Updates thread and a Files column for attachments ⁸⁰.

Before you can map a field on the source side, you need to know exactly which destination board the row belongs on, which column type each value will store into, and what will serve as the upsert key. The table below summarises the objects you will touch in a monday Work Management migration.

There is no platform-enforced unique identifier on a monday board — item names are not unique, and the system always assigns an internal numeric Item ID on create. To upsert deterministically you create a Text or Number column on the destination board, fill it from the source export with a stable external ID (UUID or source platform PK), and use that column as your match key in the ingest job ¹⁵.

Connect Boards columns link items across boards — a Task item links to one or more Project items, and a Mirror column then pulls through specific Project fields onto the Task view without duplicating storage. This is how cross-project dependencies are modelled. Mirror columns are read-only by default and recompute when the source column changes.

Column types are where the schema actually lives. The catalogue below covers the column types that carry the load on a Work Management migration and the limits you need to plan around.

Relationships in monday Work Management are modelled through Connect Boards for cross-board references and through the Dependency column for in-board task dependencies. There is no master-detail or cascade-delete construct — deleting a parent item does not delete its subitems or its connected items, so any cascade behaviour from the source has to be replicated via automation recipes.

The single best predictor of a clean monday Work Management migration is how much work you do on the source side before the first import button is pressed. monday does not deduplicate items on import — it will create two separate Task items for the same task name if you let it — so cleansing has to happen in the export file, not in the destination.

monday does not deduplicate items on import. Two rows with the same task name become two separate items — clean the file, not the board.

Treat the source export as raw material that needs to be shaped to monday's expected formats — task names trimmed, dates rewritten to ISO-8601 with the JSON wrapper required for programmatic loads, Status and Dropdown values matched character-for-character to destination labels, assignees resolved to monday user IDs or emails of users that already exist on the account, and time-tracking durations converted from any source unit (hours, minutes, decimal hours) to monday's session-interval shape.

Source-side prep

• Audit and dedup the source database before export. Excel's *Data → Remove Duplicates*, Google Sheets' *Data → Data cleanup → Remove duplicates*, or a third-party dedup tool keyed on task ID and parent-project ID — monday will not catch case-only or whitespace duplicates.
• Match picklist values exactly to monday Status and Dropdown labels — including casing and punctuation. The importer creates a new Status label on the fly for any unmatched value, which silently bloats the column past its 40-label ceiling on Status ⁴⁶.
• Decide the project hierarchy before export. Will each source project become one board, one group, or a row on a portfolio board? The cleanest pattern is: portfolio board (one row per project) connecting via Connect Boards to one delivery board per project, with groups representing sprint or phase.
• Stamp a stable external ID on every record in the source export — a UUID or the source platform's primary key — so re-runs and Connect Boards linking are deterministic ¹⁵.
• Decide what is in scope for historical activities. Comments/Updates do not have a documented bulk-import path, so historical discussion is either logged manually, attached as a Long Text *Legacy comments* column on the parent item, or imported into a parallel comments board you build ¹³⁷.

Destination-side prep

• Provision users first, ideally via Okta, Microsoft Entra ID or Google Workspace single sign-on, and assign seats and roles before importing — the People column resolves by monday user ID, and rows whose assignee cannot be matched land with no person set ⁵².
• Build the workspace, folders and boards from the right monday template — Project Management, Single Project, Agile Sprints, or a custom blueprint — so the column schema is sensible before you load. Rebuilding column-by-column later is slow ⁸⁰.
• Pre-create every custom column on the right board with the right column type. Type-conversion in place is limited; once a Numbers column exists, you cannot retroactively change it to Status without recreating it and losing the data.
• Add the Dependency column and configure its mode (Flexible, Strict, or No-action) before importing tasks — only one Dependency column is allowed per board, and the mode determines what happens when a parent moves ³⁴.
• Set Required columns (Pro+ tier) only *after* the initial import — required columns block item creation when the value is missing and fail the import outright ⁷¹.

People prep

Cutover only works if humans cooperate. Lock down a source-system freeze window — typically 24 to 72 hours — and communicate it to every department. Train delivery leads on the item card, the Updates thread, the Timeline (Gantt) view, the Workload view and the Dependency column before go-live.

A clean Asana-to-monday move of under 5,000 tasks runs one to two business days; a complex Jira-to-monday migration with rebuilt automations, multi-board structure and historical comments runs two to twelve weeks. Build the human runway accordingly.

monday Work Management exposes three load paths and the right one depends on dataset size, board count, and whether the load needs to be repeatable. The UI importer covers most one-shot migrations under 8,000 items per board. The bulk ingest job pattern handles programmatic, repeatable, and very large loads. Third-party staging tools sit on top of both and add transformation and dedup layers.

UI importer (CSV / Excel)

The native importer lives on every board under Add → Import items → From Excel or From CSV ¹³. It accepts CSV, XLS and XLSX. The wizard auto-detects columns, lets you map each source column to an existing board column or create a new one of an inferred type, and runs the load synchronously for files under a few thousand rows. Items land in the group you select.

Three limits matter. Files can carry up to 8,000 rows and 100 columns per import (only the first 50 columns are mapped on a new-board import) ¹⁰. Status column labels are capped at 40 unique values ⁴⁶; if the source has more, collapse them in the file before import.

The importer also does not deduplicate — rows with the same item name create new items every time. The UI importer is the right call for one-shot loads under 5,000 items per board, or any time you want a visual column-mapping review before commit.

Bulk ingest jobs

For larger loads, monday exposes two bulk-load job patterns. The ingest_items job accepts up to 10,000 rows per job and is available to any caller; the backfill_items job is admin-only and raises the cap to 20,000 rows for the one-time seed before users go live ¹⁵. Both jobs accept a CSV uploaded to a pre-signed URL and return a job_id polled with fetch_job_status.

Use ingest_items for ongoing sync work and backfill_items exactly once — at the start, before users touch the board. Both jobs accept the same column-mapping payload as the UI importer. Choose the bulk-job path when the load is over 5,000 items per board, when you need to populate Connect Boards and Dependency relationships at scale, or when the migration needs to be repeatable and audit-logged from your side.

Third-party staging tools

Tools like Fivetran, Airbyte, Stitch, Workato, Make and n8n sit between the source and monday. They are used in two ways: (a) reverse-ETL, where the source loads into a warehouse, gets transformed in SQL, then syncs into monday; and (b) staging-and-validate, where the tool handles file generation, type coercion and dedup before feeding the bulk-ingest job. Getint and Unito add a packaged Jira/Asana/Trello-to-monday flow that preserves comments and attachments as a paid add-on.

For one-time migrations, the value of an iPaaS layer is repeatability under failure; for ongoing syncs (the post-migration phase), they become the system of integration.

Mapping is where every migration earns its scars. The decisions you make in your mapping spreadsheet — which board, which column type, which Dependency mode, which Connect Boards link — determine whether the Gantt view works on day two, whether automations fire correctly on day five, and whether your delivery leads trust the data on day thirty.

Work board by board, top to bottom of the import order: a Portfolio board first (so each project board can link back to a portfolio row), then per-project Task boards, then subitems for subtasks, then Connect Boards links, then dependencies, then time-tracking history, then Updates and attachments where in scope.

Project hierarchy and task structure

Most source PM tools nest a hierarchy — Asana has Workspace → Project → Section → Task → Subtask; Jira has Project → Epic → Story → Subtask; Trello has Board → List → Card → Checklist. monday's native hierarchy is Workspace → Folder → Board → Group → Item → Subitem ⁸⁰.

The clean mapping is: source-project → monday board (one board per project), source-section/sprint → monday group, source-task → monday item, source-subtask → monday subitem. Epics, themes and other higher-level constructs map best to a separate Portfolio board, with each Epic linked to the per-project board via Connect Boards.

Excel imports treat subitems as flat items by default — the importer brings them in as top-level items, and you then convert them to subitems either manually one at a time or by running a second-pass load that creates subitems against the parent's Item ID ³⁷. Plan for the second pass; do not assume a single CSV will produce the hierarchy.

Task dependencies

monday models task dependencies through a single Dependency column per board, configured at column-creation time with one of three modes: Flexible (date shifts are suggested), Strict (date shifts are enforced), or No-action (the link is informational only) ³⁴. The Dependency column is gated to the Pro and Enterprise plans.

Only one Dependency column is allowed per board — if your source models multiple dependency types (finish-to-start, start-to-start, finish-to-finish), monday will collapse them into a single "depends on" link unless you replicate the type as a separate Text or Dropdown column.

Dependencies are loaded in a second pass after items exist, because the Dependency column references Item IDs and those IDs are assigned by monday on create. The pattern is: (1) export source dependencies as a (predecessor, successor) edge list; (2) import items and capture each row's monday Item ID in a lookup keyed on your external-ID column; (3) iterate edges and write the Dependency column value.

Time tracking history

The Time Tracking column logs work intervals on each item as a sequence of start/stop sessions, and clicking into a cell opens the history and log where each session can be manually edited ¹³⁸. The column carries the total automatically.

To preserve historical session data from a source like Toggl, Harvest or Jira Tempo, export each row as (item-id, start-timestamp, end-timestamp, user-email) tuples and load them into the Time Tracking column as a JSON history payload — the column accepts a session list, with the running total derived from the sessions.

If the source only stores aggregate durations per task rather than individual sessions, the simplest preserving pattern is to load a single backdated session per task covering the aggregate duration, with the source assignee as the session owner. A parallel *Legacy Hours* Numbers column on the same item gives reporting an unambiguous total that does not depend on session resolution.

Comments and Updates threading

monday's per-item Updates thread carries threaded comments, mentions, rich-text formatting, file attachments and replies. The catch: there is no documented native path for bulk-importing historical Updates with original authors and timestamps preserved as the original posting metadata — community threads from monday users trying to backfill years of comment history are unresolved ¹³⁷. Updates can be created programmatically, but each call posts as the loader at the current timestamp, not as the original author at the original time.

The patterns most teams adopt: (a) post each historical comment as a new Update with the original author and timestamp prepended in the body text as [2024-03-12, Jane Smith]: …, accepting that the metadata is in the body rather than the structured field; (b) attach a Long Text *Legacy comments* column on the parent item with the most recent N comments inline, formatted for readability; or (c) keep the source platform in read-only archive for 12 to 24 months and link out via URL.

Custom workflow status and recurring tasks

Custom workflow statuses live in the Status column, color-coded with up to 40 labels per column ⁴⁶. For each board with a non-default workflow, configure the Status column labels before importing — order them left-to-right to match the workflow progression so the Kanban view groups make sense.

If the source has more than 40 statuses, either collapse adjacent values during transform or split the status into a *Status* column (a coarse 4–6 label workflow stage) and a *Sub-status* Dropdown column (the fine-grained value).

Recurring tasks are not a column — they are built as an automation recipe. The pattern is Every time period, create item in group, configured under the Automate button on the board; periods can be daily, weekly, monthly or a custom interval ¹³⁹.

Migration implication: a recurring task in the source platform should be migrated as a single template item plus an automation that recreates it on schedule, not as 52 backdated weekly rows. Build the recipe inventory from the source first, prioritise the top recurring patterns, and rebuild those before go-live.

Custom-column mapping strategy

Resist the urge to map every source custom field one-to-one. Migrate only the columns used by an active process, report or dashboard in the last 12 months. Excess columns weaken governance, slow board loads, and make Connect Boards and Mirror columns harder to audit. monday boards have no documented hard cap on columns per board, but past ~50 columns the item card becomes unwieldy and delivery leads stop trusting the view.

For picklist fields whose source values do not match the destination, either: (1) extend the destination Status/Dropdown column with the missing labels, (2) collapse adjacent values during transform, or (3) introduce a parallel Text column that holds the legacy value verbatim. Formula columns (Pro+ tier) do not import — monday recomputes them on-platform — so any source formula must be rebuilt as a monday Formula column expression ⁴⁰.

Files and attachments

Files attach to items via the Files column or inline in Updates. The cap is 500 MB per item ⁸⁸; if files exceed that, the supported path is to zip them or upload from Google Drive, Dropbox, Box or OneDrive via the cloud-storage integration. Large attachment estates (hundreds of GB) typically use the cloud-storage link pattern, with a deep link stored in a URL column on the item.

Storage allowance is tier-dependent — Free gets 500 MB, Basic gets 5 GB, Standard gets 20 GB, Pro gets 100 GB, and Enterprise is effectively unlimited. Plan for storage tier consumption before you bulk-upload — the account-wide cap aggregates across every board, not just the project boards in scope.

Audit trail, ownership and original timestamps

monday's per-item Activity Log captures column-value changes for a retention period that scales per plan — 1 week on Basic, 6 months on Standard, 1 year on Pro and 5 years on Enterprise. The system-managed Created timestamp is stamped to import day and cannot be overwritten through the standard create or ingest paths. To preserve the original audit trail, create *Legacy Created Date* and *Legacy Created By* columns on every board and populate them from the source export.

Ownership via the People column works only if the monday user ID or email exists at the moment of import; rows whose assignee cannot be resolved land with no person set, which silently breaks downstream owner-based automations. Account-level activity audit logging is Enterprise-only; lower tiers see per-item history in the Activity Log panel but not account-wide events.

Validation is the bridge between the import finishing and users being allowed in. Field-engineering practice on monday Work Management migrations follows a three-stage validation: a test load of 10 percent of items with stakeholder spot-checks, the full load with real-time monitoring of item counts and Dependency-column integrity, and a 30-day post-migration data-quality audit. The most reliable signal is having delivery leads verify their own boards — they know what right looks like better than any reconciliation script.

Build a reconciliation queries spreadsheet that compares source and destination on each of these counts. Anything outside a 0.5 percent variance gets investigated before users get login access.

• Total items per board vs source — minus deliberately excluded rows (archived projects, closed-won deals, completed-and-purged tasks).
• Total subitems per parent item vs source — confirming the second-pass subitem conversion did not orphan rows or duplicate the parent.
• Total dependencies per board — count edges in the source dependency graph and confirm the Dependency column in monday carries the same edge count, with edge direction (predecessor → successor) intact.
• Sum of time-tracked hours per board per assignee vs source — a non-trivial variance usually signals a session-history payload error or a unit mismatch (decimal hours vs HH:MM).
• Status label distribution per board — group items by Status label and confirm no rogue labels were created on the fly by mismatched source values ⁴⁶.
• Connect Boards link counts — for cross-project links, count Task→Portfolio links and compare against source-derived expected counts; missing links cause silent Mirror column blanks.
• People column distribution — group items by assignee and confirm no item landed unowned that should not have, and no row landed on a Legacy Owner placeholder when an active assignee existed.
• Unique-identifier integrity — count distinct external-ID values across all imported boards; any duplicates indicate the dedup transform missed cases (monday will not catch them).

On top of reconciliation, run a manual spot-check protocol: pick 30 random items across boards and verify each column value, dependency link and time-tracking total against the source UI. Pick five high-complexity projects and trace the full Connect Boards graph — Portfolio link, dependency chain, subitems and Mirror columns. If a non-trivial discrepancy shows up in three or more of the 30, halt the load, fix the root cause, and re-import the affected items by external-ID column.

Rollback on monday is per-item, not per-import. The Activity Log on each item supports undo of recent column-value changes, but there is no native bulk-undo for an entire import batch. The community-built LogBack app provides per-board undo for bulk-edit accidents, and the Rewind backup product offers granular per-board restore for items and columns. Neither is a one-click rollback of a 50,000-row ingest job.

The real rollback strategy remains: export everything before the import starts, stamp every imported item with an *Import Batch ID* Text column, and if catastrophe strikes, bulk-delete by that batch ID, then re-import from the cleaned source.

Cutover sequencing: (1) source goes read-only and the team is notified; (2) final delta export captures everything that changed during the test-import window; (3) delta is imported via ingest_items; (4) reconciliation runs; (5) Connect Boards links and Dependency-column edges are populated in a second pass.

Then (6) automation recipes for recurring tasks and notifications are turned on; (7) users get login access and a 48-hour hyper-care window with the migration lead on call; (8) source decommission is scheduled for 30 to 90 days out, never the same day.

The monday.com Partner Program tiers Diamond, Platinum, Gold, Silver and Bronze partners by certifications, customer count and revenue. For Work Management migrations specifically, partners with explicit Jira-to-monday, Asana-to-monday or Smartsheet-to-monday practices tend to ship cleaner than generalist implementation shops because they understand the dependency-graph, subitem-conversion and time-tracking-history mechanics that derail naive imports.

Partners commonly named in the Work Management corner of the market run fixed-scope migration packages alongside ongoing managed services. Pricing tiers tend to follow board count, item count and historical-data depth: a single-board, under-5,000-item move with no comments runs at the low end; a multi-workspace migration with dependencies, time-tracking history and Updates preservation runs at the high end.

Getint and Unito add a packaged Jira/Asana/Trello-to-monday flow with comment and attachment preservation as a paid integration — Getint is licensed per migration run rather than per seat, which makes it economical for a one-time backfill.

On the ETL and iPaaS side, Fivetran, Airbyte, Stitch, Workato, Make, n8n and Zapier all have monday connectors. Their role in a migration is rarely the migration itself — it is the staging layer that lands source data into a warehouse, the transformation layer that converts picklist values and resolves owner IDs to monday user IDs, and the ongoing-sync layer that takes over once the one-time migration is complete.

Airbyte and Fivetran are common picks for warehouse-first teams; Workato and Make are common where the migration is bundled with workflow automation rebuilds; n8n is used heavily for monday-side automation recipes post-migration where the team wants more control than the native automation builder offers.

Managed-migration cost ranges vary widely. An Asana-to-monday or Trello-to-monday move under 5,000 tasks with no historical comments and a single workspace often lands in the $2,500–$8,000 range. A Jira-to-monday project with dependencies, time-tracking history, subitem conversion and Updates preservation typically runs $15,000–$80,000, with the upper end driven by item count, dependency-graph density, historical-comment depth and the number of integrations that need rebuilding rather than re-pointed.

For teams that want to outsource the migration end-to-end, FlitStack specialises in monday.com Work Management migrations and handles the column-type design, project-hierarchy mapping, dependency-graph load, subitem conversion, time-tracking history preservation and validation work described in Sections 5 and 7 of this guide. Pricing is fixed-fee, based on item count and source platform, with separate line items for Updates-thread depth and Dependency-graph complexity so the scope is transparent before signature. Explore FlitStack →

This is one of several legitimate paths — the right choice for any given team depends on whether they want a Diamond/Platinum monday Partner, a packaged migration product like Getint or Unito, an iPaaS-first approach, or a specialist migration vendor.