How to Move a Creative Project Out of Miro: A Step-by-Step Guide

What you walk away with

• An honest decision about whether to move everything, some of it, or nothing
• Your boards sorted into the four categories that determine what happens to each
• A clear picture of what actually survives an export, before you rely on it
• A rebuild order that keeps the team working during the transition
• A split arrangement that keeps Miro for facilitation without paying for it to be an archive

The one rule that decides whether it works

Migrate the projects, not the boards.

The instinct is to move 340 boards to a new tool and end up with 340 boards nobody opens somewhere cheaper. That is not a migration, it is a relocation of a filing problem, and it is why most tool switches disappoint: the new tool inherits the old tool's mess plus the cost of the move.

What deserves to move is a small number of *live projects*: the work that is still being decided, still being referenced, still changing. Everything else is either an archive (export flat, store somewhere cheap, never look at it again) or genuinely dead. In practice, teams find that of a few hundred boards, ten to thirty are living work. Migrating thirty boards well is a week. Migrating 340 badly is a quarter, and it ends with a worse version of what you had.

1. Decide whether you should actually leave

Before any export, be honest about which problem you have, because three of these are not solved by switching tools.

Good reasons to move. Per-seat pricing that punishes the way you actually work, freelancers, clients, and occasional collaborators who need to see the board and cost a seat each. Boards that are session artifacts rather than living project homes, so work you need daily is buried in workshop debris. Needing the visual work to sit next to writing, planning, and assets rather than in a separate whiteboard silo. A canvas that has become slow at the scale your projects reached.

Bad reasons to move. Nobody maintains the boards (they will not maintain them elsewhere either). One person dislikes the interface. The workshops themselves are unproductive, which is a facilitation problem that travels with you. A hope that a new tool will impose structure, which no tool does.

Reasons to stay, at least partly. If your core use is running frequent live workshops with large groups, Miro is the strongest product in that category and it is not close. Its facilitation kit, timers, voting, private mode, presentation flow, is deeper than the alternatives, and if you run sessions for a living, leaving entirely will cost you more than the license does.

The most common right answer for creative teams is a split: Miro stays as the workshop room, and project work moves to a home built for continuity. Steps 4 and 7 assume that; if you are leaving entirely, the same steps apply with more moving.

2. Sort every board into four categories

Do not open the export menu yet. Take the board list, sort by last modified, and put every board in one of four buckets. This is two hours for a few hundred boards, and it is the whole project.

Two things reliably surprise people here. First, how enormous the dead pile is: for the studio it was 300 of 340, and the freedom of that number is worth the two hours by itself. Second, that most "important" workshop boards belong in the second category, not the first. What matters from a session is the decision it produced, one paragraph, plus a flat image of the board for context. The 200 sticky notes were the working material, and nobody has read them since the day they were written.

If you cannot decide a board's category in fifteen seconds, it is dead. Genuine live work announces itself.

3. Know what actually survives the export

Check this before you promise anyone a date, because export shape drives the rebuild plan.

Miro's export options are, broadly: a board backup file that only Miro can reimport, PDF and image exports that preserve the visual layout but nothing structural, and CSV export that covers card-type content. There is also an API, which is the only route to structured extraction at scale and needs someone comfortable writing a script. Verify the current specifics on your plan before relying on any of them, since export capabilities differ by tier and change over time.

What that means in practice:

• Visual layout survives as an image, not as objects. A PDF of a workshop board is a fine archive and a useless starting point for editing.
• Spatial meaning does not survive at all in text exports. If the fact that a cluster sat next to another cluster carried the meaning, only the image carries it.
• Comments, mentions, and version history generally do not travel. If a decision lives in a comment thread, extract it to text before you leave, or it is gone.
• Embeds and linked files are pointers. They will need re-linking, and some will be broken already.

Practical order: export flat archives (PDF or image) for everything you are keeping in any form, first, before touching anything else. It is cheap insurance and it makes the rest of the project reversible.

4. Extract decisions from session artifacts before anything else

This is the highest-value hour in the migration and the one most teams skip in the rush to move boards.

For every board in the session-artifacts category, write one short block: the date, the question the session addressed, what was decided, who decided it, and what was explicitly rejected. Attach the flat image. That block, five lines, replaces a 200-note board completely for every future purpose anybody actually has.

Do this while the people who attended still work with you. The studio found four decisions nobody could reconstruct, including one about client-file naming that had been silently causing an argument every few months for two years, because the reasoning existed only in the heads of two people who had since left. Extraction is not archaeology; it is capture before the knowledge finishes evaporating.

5. Rebuild live projects in the right order

Now the actual move, project by project, not board by board. For each live project, rebuild in this order:

1. The project home first. Create the container with the structure the project needs, then fill it. Rebuilding structure and contents at once produces a copy of the old mess.
2. Decisions and current state. What is true right now: the approved direction, the current version, the open questions. This is what makes the new home immediately usable, and doing it first means the team can switch before the migration finishes.
3. Live working surfaces. The boards still being edited, rebuilt rather than pasted. Rebuilding is faster than it sounds, because half the content was already dead, and a rebuilt board is one someone understands.
4. Reference material. Pinned assets, brand elements, recurring frameworks, ideally as reusable templates rather than copies.
5. Archive images last. Flat exports attached where relevant, for the "what did that session look like" case.

Move one project completely before starting the next, and let the team work in the new home for that project immediately. Half-migrated projects with people working in both places is how migrations produce two sources of truth, which is worse than either tool alone.

A rule that saves a lot of pain: nothing gets rebuilt unless someone can say what it is for. "We might need it" means flat archive, not rebuild.

6. Set the conventions on the way in

A migration is the one moment when everyone is paying attention to structure, so spend it.

• Naming. Decide the pattern (client, project, artifact type, date) before you rebuild the second project, and apply it to the first retroactively.
• Depth. Keep the hierarchy about two levels deep. Deep nesting is how the 340-board pile happened in the first place.
• An archive location that is one click away and clearly separate. The reason boards accumulated is that archiving felt like deletion and deletion felt risky, so nobody did either.
• A named owner per project home. Not a maintainer of everything, just a person who decides what belongs where when it is ambiguous.
• A quarterly ten-minute sweep. Anything untouched in six months moves to archive. This one habit is what prevents the whole situation recurring in the new tool, which it otherwise will, on exactly the same timeline.

Write these five lines somewhere in the new workspace. Conventions that exist only in the migration lead's head last about six weeks.

7. Keep Miro for what it is best at

If you run live workshops, keep a small Miro presence and use it deliberately: sessions happen there, and within a day the decision block plus a flat image lands in the project home, where the work lives. The board can then be deleted or left to rot without cost, because the valuable output already left.

This split usually pays for itself twice. It removes the archive burden from your most expensive per-seat tool, so the license covers the few people who actually facilitate rather than everyone who might one day need to view something. And it fixes the original disease, which was never Miro's fault: session artifacts were accumulating in the place project work lived, so both jobs were done badly.

The failure mode to avoid is the half-split, where "some things" stay in Miro without a rule. Write the rule down in one sentence: live sessions in Miro, everything that outlives the session in the project home. A split without a stated rule becomes two sources of truth within a month.

Common mistakes

• Migrating boards instead of projects. 340 boards nobody opens, relocated. Sort first; ten to thirty boards are usually the real live set.
• Opening the export menu before sorting. The sort is the project; the export is the easy part.
• Trusting text export to carry spatial meaning. If the arrangement was the meaning, only the image has it.
• Leaving decisions in comment threads. Comments generally do not travel. Extract to text before you leave.
• Rebuilding contents and structure simultaneously. You get a faithful copy of the mess you were escaping.
• Half-migrating several projects at once. Two sources of truth, which is worse than the tool you were leaving.
• Skipping conventions during the move. The only moment everyone cares about structure, wasted, and the pile regrows on schedule.
• Leaving Miro entirely when you run real workshops. You will miss the facilitation kit within two sessions and quietly resent the new tool for not being a workshop product.

How this went for the 340-board studio

The sort took an afternoon and produced: 302 dead, 21 session artifacts, 12 live projects, 5 reference boards. The number itself changed the mood of the project, because "migrate 340 boards" is a quarter and "rebuild 12 projects" is a fortnight.

Flat PDF exports of everything in the keep piles came next, about an hour of clicking, and made the rest reversible. Then the decision-extraction pass over the 21 session boards, which took a morning with two people talking through them and surfaced the four orphaned decisions, including the naming argument that had been recurring for two years.

The rebuild ran one project at a time over nine working days, structure first, current state second, live surfaces rebuilt rather than pasted. Two of the twelve "live" projects turned out to be dead once someone had to articulate what they were for, which is the rebuild rule doing its job.

They kept Miro on a small plan for workshops, with the one-sentence rule written at the top of the new workspace. Six months later the new home had 34 items and a quarterly sweep, the freelancer seat problem was gone because viewers cost nothing in the new tool, and the thing they mentioned unprompted was not the price: it was that the moodboards now sat next to the project plans and the client decisions, so preparing for a client call stopped being a scavenger hunt across three tools.

The tools you will actually use

Where the work goes depends on what your boards actually were.

• Staying partly in Miro is right if you facilitate frequently; its workshop kit is the deepest available. Just stop letting it be your archive.
• FigJam is the natural destination for teams whose design work already lives in Figma; the board sits next to the files it relates to. Less suitable if half your team does not use Figma, since the interface reads as design-team territory.
• Milanote suits teams whose boards were mostly moodboards and visual references; it is built for that and is pleasant at it. Weaker once the projects also need planning, writing, and structured work alongside the visuals.
• A canvas built for projects rather than sessions is the fit for the specific problem in this guide, and it is what Storyflow is: boards, moodboards, plans, documents, and decisions in one project home, so the material that outlives a session has somewhere to live that is not a whiteboard graveyard. Its AI reads the actual board, which helps in the migration itself, clustering a rebuilt board or drafting the decision block from what is on screen. Relevant to why teams leave Miro: it is priced per account rather than per seat, and collaborators and viewers are unlimited and free, so freelancers and clients cost nothing; paid plans start at 7.99 dollars a month billed annually. Live multi-cursor co-editing sits on the Max plan, which is the honest tradeoff, if simultaneous cursors during sessions are core to your work, that is Miro's home ground.
• The honest summary: for running live workshops at scale, Miro is better than the alternatives and worth paying for. For being the place a creative project lives between sessions, it was never the right shape, and that mismatch, not the price, is what the renewal quote is actually telling you.

You are ready

The renewal quote is rarely the real message. The real message is that a tool built for the hour a session lasts has been carrying six months of project life, and doing it badly, for years.

Sort before you export. Expect the dead pile to be enormous, and enjoy it. Extract the decisions while the people who made them are still here. Rebuild projects, not boards, one at a time, and spend the migration's attention on conventions. Then let Miro do the one thing it is genuinely the best in the world at, and stop asking it to be an archive.

Author

Justkay is a documentary filmmaker and the founder of Storyflow. He has helped creative teams untangle several hundred-board whiteboard piles, and built Storyflow because the material that outlives a workshop needed somewhere to live that was not another workshop board.