Moving from spreadsheets to monday.com without losing the team

I have watched a technically flawless migration fail because of a Monday morning.

Everything was moved correctly. Board structure was clean, automations tested, historical data intact. The announcement went out at 9am on a Monday: from today, we use monday.com. By Wednesday half the team was back in the spreadsheet “just for this week” and the CRM was already out of date, which made it useless, which proved the sceptics right.

The data migration is maybe 30% of the work. Here is the other 70%.

Before you move anything

Find out what the spreadsheet is really doing

Every long-lived spreadsheet has features nobody documented. A conditional format that means something. A tab someone uses for a weekly report. A column that is technically unused except by one person for one critical thing once a quarter.

Sit with the two or three heaviest users and have them walk you through a normal week. Not “explain the spreadsheet”. Ask them to do their actual job while you watch. You will find at least one thing that never came up in the requirements conversation, and if you miss it, that person becomes your loudest opponent.

Decide what you are deliberately not moving

This is the part people skip, and it is where most of the value is.

A spreadsheet accumulates junk: columns that made sense in 2019, statuses nobody uses, three fields that mean roughly the same thing. If you move all of it, you have rebuilt the mess in a more expensive tool.

Write two lists: what moves, and what dies. Then show the second list to the team before you build. Some of it will come back, and that is fine, but the conversation is much easier now than after launch.

Clean the data where it is

Deduplicate, standardise, fix dates, in the spreadsheet, before import. Sorting out 200 inconsistent company names is tedious in Excel and genuinely painful once they are monday.com items with linked records attached.

Specifically:

• One header row, no merged cells, no blank rows in the middle
• Dates in one consistent format, ideally ISO (2026-07-30)
• Status and category values from a fixed list, spelled identically every time
• Numbers as numbers, no currency symbols or thousands separators in the cell
• One thing per column. Split Contact into name, email and phone now

The import itself

monday.com’s Excel and CSV import is good. Three things worth knowing:

Import into a board you already structured. Do not let the importer create columns for you. Build the board first with the columns and types you decided on, then map the spreadsheet into it. Auto-created columns come out as text and converting them later is worse than doing it right.

Import in two passes when you have linked boards. Load the Contacts or Accounts board first, then the Deals board, then connect them. Trying to create both sides plus the relationship in one import is where things go sideways.

Test with 20 rows. Import a small slice, check every column type came through correctly, especially dates and numbers, then delete and do the full run. Ten minutes that saves an afternoon.

The rollout sequence that works

This is the part that decides whether it sticks.

Week 1: parallel, with the spreadsheet still the source of truth

Both systems live. monday.com is the copy. Ask two or three volunteers, not the whole team, to work in monday.com and tell you what is annoying.

You are not testing whether the board works. You are collecting the list of small frictions that would otherwise become the reason people rejected it.

Week 2: fix the frictions, then flip the source of truth

Address what came back. Then announce that monday.com is now the real one, and the spreadsheet is read-only reference.

Critically: make the spreadsheet read-only for real. Not “please stop using it”. Remove edit access. A spreadsheet you can still edit is a spreadsheet people will edit, and then you have two sources of truth and neither is right. This is the single highest-leverage decision in the whole migration.

Week 3: run one real meeting from it

Take your existing pipeline review or project standup and run it entirely from monday.com. Do not prepare a separate deck. If the board cannot support the meeting, that is the most valuable bug report you will get, and you want to find it in week 3 rather than month 3.

This is also the moment adoption actually happens. People update the board because their manager is going to look at it in a meeting, not because of a training session.

Week 4: remove the fallback and train properly

Archive the spreadsheet somewhere retrievable but not convenient. Now run the real training session, because now people have questions grounded in use rather than sitting through a feature tour.

What to say when someone asks why

You will get asked, usually by whoever built the spreadsheet. Have a specific answer ready, and make it about their life, not about the company:

• “You will stop being the person everyone messages for a status update”
• “Nobody will overwrite your row again”
• “You will not have to rebuild the report every Friday”

“It is more scalable” convinces nobody. “You get your Friday afternoon back” convinces people.

The mistakes worth avoiding

Launching on a Monday. Launch on a Tuesday or Wednesday. Monday is the busiest, least patient day of the week, and if something goes wrong you have four days to fix it rather than discovering it Friday afternoon.

Training before use. A training session on a tool nobody has touched is a session people forget. Let them poke at it first, then train.

Moving history you do not need. Three years of closed deals feels valuable and is usually noise. Move open work plus 12 months of closed. Keep the rest in the archived spreadsheet, retrievable if anyone actually asks. In my experience nobody does.

Building the dashboard first. You do not know what people will fill in yet. Wait three weeks, then build reporting on reality.

If you want the sequence as something you can tick off, the migration checklist is this article as a working board.