What Happens in a Data Migration to monday.com? A Consultant's Walkthrough

If you have built something real in Jira, Asana, Trello, Smartsheet, or wherever your team lives today, this piece is for you. You are not starting from a mess. You are moving a working system, and the question is simply how to bring it across intact. That question has a more specific answer than most people expect, because monday.com has already published a lot of detail about exactly what each import route can and cannot do. Read together, that detail tells you almost everything a migration consultant is actually paid to know.

Not as monday.com documents it. Its help centre publishes seven named importer articles: Excel, Asana, Basecamp, Jira Server, Google Sheets, Trello, and Zendesk. Two more import routes sit entirely outside that section and outside its label, so to anyone searching, that section reads like the complete list when it is not: a separate Excel importer built specifically for monday CRM, and a separate guide for moving Jira data into monday dev. On top of those nine, monday.com documents an import path buried inside its Jira Cloud integration article, an import path inside its QuickBooks integration article, three guides for moving data between monday.com's own products, a copy-and-paste method, and a bulk import API with two different endpoints.

That is not a criticism of monday.com's documentation. It reflects how many genuinely different products monday.com now sells, each with its own import needs: monday AI work platform, monday CRM, monday dev, monday service, and monday campaigns. But it does mean that anyone who tells you "monday.com's import limit is X" is telling you something incomplete, whatever X is. The honest starting point for any migration is figuring out which of these routes actually applies to your data, because the answer changes the numbers, the supported fields, and sometimes the plan you need.

Here is what monday.com prints, route by route, as of today.

The spreadsheet importer on the monday AI work platform accepts a file with up to 100 columns and 8,000 rows, whether you are importing into a new board or an existing one. On a new board, though, only the first 50 columns actually come across. Go over either limit and the import is rejected with an error message rather than silently cut down.

The Google Sheets importer is a different tool with a different ceiling: 3,000 rows and 20 columns, and the importer itself always creates a new board. monday does publish a way into an existing board, from the board's own import menu, but says it only adds new items and is not a full mapping of columns. If your sheet is bigger than 3,000 rows, monday.com does not reject it. It cuts the import off at that point, and it does not say whether you are told. That is worth knowing before you assume Excel and Google Sheets behave the same way, because they do not.

monday CRM has its own, separate Excel importer (https://support.monday.com/hc/en-us/articles/14244473062290-Import-from-Excel-to-monday-CRM), with its own rules: files must have fewer than 50 columns and under 8,000 rows, and be no larger than 10 MB. monday does not say what happens if you break any of those three, which is itself worth knowing before you build the file. It does publish a consequence for a fourth rule in the same list: upload more than 100 files per account per hour and monday says you will receive a notification that you have reached your limit for the time being. It is a stricter column rule than the AI work platform importer's, which accepts a file of up to 100 columns and simply imports the first 50 when it is creating a new board.

The Trello importer caps at 10,000 rows at a time. Jira Server's own importer carries no published row limit but is restricted to Enterprise accounts, and monday.com has already flagged it for deprecation in favour of a newer Jira Data Center app.

Then there is the bulk import API, documented under the title "Importing items in bulk" (https://developer.monday.com/api-reference/docs/importing-items-in-bulk), which is the route built for volume. It runs two endpoints. The standard one, meant for ordinary use, accepts 10,000 rows per job. A second endpoint, reserved for account admins and meant for a one-time initial load, accepts 20,000 rows per job and does not consume the 19,000 items per hour account budget, though both endpoints share a ceiling of 100 import jobs per account per hour. Both cap at 150 MB per file.

Two more figures worth knowing if you are moving data monday.com already holds: moving items between monday.com's own products, from the AI work platform into monday CRM, is limited to 500 items at a time in bulk, and monday.com's own guide for moving Jira data into monday dev tells you to select about 100 items per batch, written with a tilde rather than as a stated limit.

Six different numbers across eight different routes. None of them contradicts the others. They are different tools for different jobs, and knowing which one you are actually using is most of the work.

In two places, and it is worth being precise about which two, because a false contradiction here would undercut the true ones. The first sits on the article most spreadsheet migrations start from. The second runs across four pages and shows up further down, in how monday.com's own documentation counts hierarchy levels. monday.com's own Excel import article (https://support.monday.com/hc/en-us/articles/360000219209-Import-files-from-Excel) contradicts itself on a single question: does re-importing a file update the items already on your board?

Its body documents an option called "Update matches" that does exactly that. monday.com's own words: "When importing an Excel file containing rows that already exist as items on the monday board but with new data, you can opt to update these existing items." The two sentences that follow are just as direct: "Any new data from your file will be added as separate new items." And: "Keep in mind, if the existing data matches the Excel data, it will remain unchanged; if it has been modified, it will be updated to match the Excel data."

Its own FAQ, elsewhere on the same page, answers a related question. The body's option sits under a heading reading "How do I import Excel or CSV data into an existing board?", so it describes the existing-board flow specifically. The FAQ's question is general and names no board type. Its answer names both: it says re-importing creates a new board, and that existing boards are not automatically updated. So the FAQ speaks directly to the flow the body's option belongs to, and answers it the other way. So a reader who asks monday's own question, on monday's own page, is told re-importing creates a new board, while the same page documents an import that updates matching items on a board that already exists. Do not resolve on monday's behalf whether the FAQ was meant to exclude the existing-board flow: monday does not say.

When a vendor's own body copy and its own FAQ disagree, the body is generally the part to trust, and that FAQ block is stale on a second question too: it says "Each column in your Excel sheet becomes a column in your monday.com board," where the body says only the first 50 columns come across when the import creates a new board. On the column question the FAQ is demonstrably behind the body. On the update question the practical guidance is the body's, because re-importing can update matching items if you choose the "Update matches" option, but monday has not said which of the two governs a re-import into an existing board, so confirm it on your own board before you plan around it.

One more thing is worth naming precisely, because it reads like a contradiction and is not, once you check what each number actually counts.

monday.com's help centre, on its page introducing the high-volume Data Set feature (https://support.monday.com/hc/en-us/articles/35918994965010-Introduction-to-Data-Set), states that "the batch import API supports up to 20,000 items at a time." monday.com's own developer documentation, describing the same API, says its standard endpoint accepts 10,000 rows per job and reserves 20,000 for a second, admin-only endpoint. That looks like the same number stated two ways, but both figures are correctly scoped once you read past the headline. The help centre's sentence opens "For large-scale migrations from external systems or existing boards," and it sits inside instructions for populating a newly created Data Set, which only account admins can create. The developer documentation describes its 20,000-row endpoint the same way, as "intended for a one-time, account-admin-only initial load". Its 10,000-row endpoint is for ordinary, everyday use. monday's own comparison table gives that endpoint's purpose as "Integrations, recurring imports, creating or updating items as part of normal board activity". Two endpoints, two jobs, and both ceilings are correct for the job each one describes. What does not line up is smaller and more useful: monday.com's help centre calls this "the batch import API", while the developer documentation titles that same API's page "Importing items in bulk". And the help centre sentence never names which endpoint it means, so a reader planning around the 20,000 figure cannot tell from that page alone that it requires an account admin and a one-time load. That is worth knowing. It is not monday.com disagreeing with itself about a number.

The second is the hierarchy depth question, and it is not just a difference in what two pages count. It is a real conflict in monday.com's own documentation, and unlike the first it does not sit on one page: it runs across four of them.

monday.com's developer documentation on the bulk import API says a multi-level board supports a maximum of 5 hierarchy levels, counting the top-level item itself as one of the five. A separate support article says you can add up to four levels of subitems beneath the item, which it calls level zero. Those two agree: zero plus four is five, one depth described from two different starting points.

A third monday.com page does not fit that pattern. Its developer guide to multi-level boards states plainly, "A multi-level board is a new board type that supports up to five layers of subitems." That page sets its own counting base against classic boards, calling classic boards "One level of subitems only" and, in the very next cell of the same table row, describing that as "the previous two-level structure." One level of subitems equals a two-level structure, so on this page's own arithmetic, "levels of subitems" excludes the item, the same base the support article uses. Read on that base, five layers of subitems is one level deeper than the support article's four. A fourth page, monday.com's developer reference for subitems, states that subitems "can be nested up to 5 levels deep", and the two pages were stamped less than two hours apart on the same day, 21 March 2026, which reads as one release batch. rather than one page's typo.

This is a genuine conflict in monday.com's own documentation, not a third counting base. The two pages that agree with each other, the bulk import documentation and the support article, are also the newer pair. The two that say five are older, and monday.com has not withdrawn either of them. So check the depth on the board you are actually building before you map a hierarchy to it, because monday.com's own pages do not agree on how deep you can go.

You will see a standard board's ceiling given as 10,000 items on every plan except Enterprise, which allows 100,000, with monday CRM carrying its own exceptions on top of that: up to 100,000 items per board across five boards on CRM Pro, and up to 1 million items per board on CRM Enterprise while that feature is in beta. Alongside those sit 5,000 on a multi-level board and 10 million on the high-volume Data Set surface. Different work surfaces and different plans, not a conflict.

One genuinely practical wrinkle: monday.com's own documentation warns that the monday CRM Excel importer, with its tighter 50-column rule, "may also appear on your AI Work Platform boards" as part of what it calls a new release. In plain terms, you cannot always tell which import rule applies just by knowing which monday.com product you bought. That single sentence, printed by monday.com itself, is the best argument on this whole topic for having someone check which importer you are actually looking at before you build your file.

This is the part a self-serve import rarely surfaces until after the fact, and it is where a consultant earns their keep.

Column types shrink on the way in. Import a spreadsheet into a brand-new board and monday.com can only create five column types from it: Number, Status, Email, Date, or Text. Import into a board that already exists and you get seven types instead: Numbers, Text, Date, Email, Dropdown, Timeline, and Phone. Anything else has to be reshaped by hand afterward.

Status columns have a hidden threshold. If a column has nine or fewer distinct values, monday.com's importer suggests it as a Status column. More than nine, and it suggests Text instead. Cross forty distinct values in a single column and the import fails outright, a hard limit rather than a suggestion.

Only the first tab of a multi-tab spreadsheet imports. Protected spreadsheets will not upload at all. Nothing lands in a board's Updates section. monday states that data cannot be imported to the Updates Section, and that the data will instead be imported to a column on the board, where you can change the column type or move it around. So update history arrives as a column of text rather than as updates, and turning it back into updates is manual work. Dates need to arrive in ISO format, four digits for the year, two for the month, two for the day, a rule monday.com states both for the Excel importer and, independently, for the bulk API.

Subitems are a genuine scope trap. monday.com's Excel article states flatly that subitems from Excel "will be imported as items onto your monday board," which then have to be manually converted to subitems afterward. That sentence carries no board-type marker of any kind. But monday.com separately documents a different Excel route, scoped specifically to multi-level subitem boards, where adding a Subitems column and naming each row's parent does build the hierarchy automatically on import. Both are monday.com's own documentation. monday does not say which of the two rules governs an Excel import into a multi-level board, so confirm the behaviour on your destination board type before you build the file rather than after.

Most third-party importers publish their own supported-field list, and for one of them monday.com is explicit about what gets dropped. The Trello importer carries the Trello task name, labels, and dates across, and states outright that descriptions, checklists, activity, and files are not supported. The Asana importer carries six fields: Name, Assignee, Completed, Notes, Due date, and Parent name. Basecamp's importer works only with Basecamp version 4, and monday.com publishes no field list for it at all. The Zendesk importer brings, by monday.com's own default list, the ticket subject, status, priority, three dates, and a link back to the original ticket. The Jira Server importer, available on Enterprise only and already flagged for deprecation, matches people by email address, falling back to the Jira display name when the email is not public in Jira, in which case monday says the display name on monday.com has to match the one in Jira. QuickBooks has no dedicated importer at all; monday.com's own recommendation is to export your QuickBooks data to CSV and run it through the standard Excel import, before setting up the ongoing QuickBooks integration rather than after.

None of this is a flaw in any of these tools. It is simply a lot of detail to hold in your head at once, and holding it is the job.

Yes, in its own words, more often than you might expect. A search of monday.com's own help centre for the phrase "paid services for setup" turns up eight articles, and seven of the eight name data migration specifically while pointing readers to go-to-partners, monday.com's own certified partner marketplace, for paid help.

monday.com's Implementation packages page (https://monday.com/w/service-offerings/implementation) is more direct still. Its comparison table carries a row reading "Consulting Support for Native Data Import", with an asterisk. Its footnote then draws a clear line: "Custom data migrations, custom integrations, and application development are not included." Anything past the native importers, in other words, is out of scope for the packaged offering and gets routed to an account manager or "our certified partner network."

monday.com's separate Services offerings page confirms exactly where that line sits. Under its Tailored services heading, one of three listed capabilities is to "Migrate live and historical data from any third-party platform into monday.com." That capability sits outside the standard packages entirely, in a category built for engagements that do not fit a template.

This is not Workiflow's argument. It is printed on monday.com's own site, twice, in two different ways. monday.com's own partner page also confirms there is a real tier ladder behind its certified partners, stating plainly that it "provides leads to partners in the Silver, Gold, and Platinum tiers." A consultant is not an alternative to monday.com's own advice here. Following that advice is what a consultant is for.

monday.com does not publish an end-to-end project duration for migrating a third-party system into monday.com. What it publishes is narrower, and it is worth knowing. Inside its Jira Cloud integration article, under a heading reading "How to import data from Jira", monday notes that only 100 to 150 Jira issues can be updated and synced with monday every five minutes, a ceiling it attributes to Jira's side rather than its own. That is a throughput rate, not a project plan, but on a 3,000-issue backlog it is the difference between an afternoon and a week. It is not the same as saying nobody publishes anything about migration duration, because several sources publish something adjacent to it, and each measures something different.

One migration monday.com's help centre does put a clock on is moving contacts from monday campaigns into a shared monday CRM board, a feature monday.com says is in Alpha testing and manually enabled for selected accounts, on the Pro and Enterprise plans. It states that a few hundred contacts finish in a minute or two, while monday.com puts lists of 10,000 contacts or more at 10 to 30 minutes. That is a monday-to-monday contact sync, not a third-party migration, and it is a genuinely useful worked example of what a real migration involves: contacts are matched by email only, several column types cannot come across at all, and once the boards are linked there is no self-service way to disconnect them.

monday.com's own blog, in a piece about building a CRM on monday.com, gives an effort estimate rather than a project duration: often 10 to 20 hours for structured, clean data, more if the data needs cleanup first. That is marketing content, not documentation, and it is an hours estimate for one piece of a larger setup, not a stopwatch on an entire migration.

monday.com also sells three-tier implementation packages running up to 8, 12, and 16 weeks. Those figures describe a full implementation engagement, configuration, boards, dashboards, and training, not a data migration, and they should never be quoted as migration timelines. That distinction matters, because it is the easiest mistake to make when reading monday.com's own pricing pages.

Workiflow publishes actual migration durations on its own data migration package page, which is a narrower and more directly comparable figure: about three to four weeks for its Essentials tier, covering one source system into one monday.com target with core objects, relationships, and up to roughly 10,000 records per object, and about five to seven weeks for its Professional tier, which adds attachments, history, custom mapping and transformation on top. Those numbers describe a full migration engagement rather than an hours estimate, which is the more useful comparison if you are trying to plan around a go-live date.

monday.com's own guide for migrating Jira data into monday dev is the clearest end-to-end method monday.com publishes for any third-party migration, and it is worth walking through because it maps closely onto what a paid migration engagement actually looks like.

It sets up the destination structure first, before any data moves. It then defines uniform data requirements across the team. Only after that does it build the integration tooling. And only then does it move data, in batches of roughly 100 items at a time.

That order, structure first, requirements second, tooling third, data last, is the whole method in one sentence. It matters because of a rule buried in the bulk API's own documentation: every Status and Dropdown label a CSV file references must already exist, active, on the column it maps to before the import runs, or that row fails. You cannot migrate data into a structure that has not been built yet, which is exactly why a consultant spends the early part of an engagement mapping fields and building the target board rather than touching your existing data.

The bulk API's requirements are specific enough to be worth knowing even if you never touch the API directly, because they describe the level of precision a real migration needs. Every CSV header past the first must be the board's exact internal column ID, not its display title, taken from the board's own schema. Every person value has to resolve to exactly one active user or team in the account, or that row fails. Dates need ISO formatting. And once a job starts, it stays running. monday.com's own documentation is direct about this: "Cancellation of a running job is not supported." That matters because monday's own guide for moving data between its AI work platform and monday CRM tells you to move a single item as a test before moving anything in bulk, and a real migration engagement does the same.

The same guide adds a second rule, in plainer language: "Do not use your existing boards and move items. We strongly recommend keeping your original data untouched." That single sentence describes what a consultant actually does in practice. The source system stays exactly as it is until the migration is validated. Nothing is touched, deleted, or repointed until the new board has been checked against it.

There is good news built into monday.com's own recovery rules, too. Deleted items can be recovered from the trash for up to 30 days after deletion, and archived items can be restored with no time limit at all. A migration that goes wrong on monday.com's side is rarely unrecoverable; it is usually just slower to fix than getting it right the first time.

Honestly, sometimes you do not. If your data lives in a spreadsheet, fits comfortably under 8,000 rows and 100 columns, and does not depend on subitem hierarchy or exotic column types, monday.com's own Excel importer will likely get you most of the way there in a single sitting, and if the file is over the row or column limit monday says you will see an error message asking you to reduce it. One thing to know before you start: monday also documents a failure that shows no error message at all. It calls this a silent failure, where the import window disappears without loading your data, and it names two causes, hidden formatting carried over from another application and a Status column with more than 40 unique labels. The same basic caution applies to a small Trello board or a modest Asana project: the field lists monday.com publishes for those importers are short enough to check by hand before you start.

Where it gets harder is volume, structure, and anything that has to survive without breaking a workflow already in daily use: multiple related boards, a hierarchy that needs to come across intact, status labels that have to exist before a single row lands, or a source system monday.com's help centre does not document an importer for at all. Smartsheet, ClickUp, and Wrike fall into that last category. A quoted search of monday.com's help centre for any of those three names returns nothing at all, and the same search engine returns results for other terms, so the silence is real rather than a broken query. monday.com's help centre does not document an importer for any of them. It does not prove monday.com cannot move data from them, because both the Excel importer and the bulk API are source-agnostic: if you can get your data into a correctly structured spreadsheet or CSV, where it came from does not matter to either tool.

That gap is exactly where Workiflow sits. Workiflow is a monday.com Platinum partner, a tier confirmed on monday.com's own go-to-partners directory, which also credits Workiflow with the 2025 Rising Star award for North America and lists Data Migration among its named services. Workiflow publishes a full catalogue of 57 priced monday.com packages, of which 24 are migrations, including named packages for Smartsheet, ClickUp, and Wrike specifically, alongside Salesforce, HubSpot, Jira, Asana, Airtable, Notion, and fourteen more named source systems. Every migration package runs from $3,500 at the Essentials tier to $8,000 at the Professional tier, and Workiflow's Trust Center states 69 continuously monitored controls across 10 domains, with its SOC 2 Type II and ISO 27001 audits both currently in progress rather than complete.

If your migration is small and contained, monday.com's own tools are genuinely enough, and there is no reason to spend money working around that. If it is not, the honest next step is a conversation about which of those 24 migration packages actually matches your source system, and what it would take to bring your data across without losing what makes it useful. Book a call with Workiflow to talk through your specific migration, or look through the full catalogue at Workiflow's packages index (https://workiflow.com/services/monday/packages) first.