How to export your data from Miro

How to export your data from Miro before the contract ends

A renewal, a price increase, a data residency requirement or a decision to exit usually forces a full export of Miro boards before the contract ends. Miro documents several export paths: images, PDFs, CSV tables, .rtb board backups and, on Enterprise, a board export API. None of them produces an editable board that opens outside Miro, so every export is an archive or a reference copy, and the new platform will need to be rebuilt from it. Plan the archive around what each format keeps and what it drops, and decide early which boards need a full archive and which can be recreated.

Plan and owner settings decide what each member can export. Board owners, team administrators and viewers may see different export options, and the options can depend on how a board is owned and shared. Before the export window opens, run an inventory: list every board, its owner, its plan context, and whether it holds comments, attachments or embedded content. Then test one representative board of each type with a standard member account, so you learn what your actual users will receive. Ask your Miro account team whether the Enterprise Board Export API is enabled for your organization and who can generate the credentials it requires.

The .rtb files work as restore points inside Miro. They are capped at 1 GB per board and restore only into Miro, so they protect against loss but do not give you a migration path. Keep them as a record and check your largest boards against that limit early. For the Enterprise API, confirm with your account team which fields carry comments and how the archive is structured. This page covers only documented export paths. Confirm current limits in Miro's help center and with your account team before you rely on any of them, because export options can change with plans and product updates.

What Miro exports, in which format and under which limits

This table lists each Miro data type, the export method, the output format, who can run it, and the documented limits. Read it as a checklist of what you can take out of Miro and what you must confirm in Miro's current documentation before a migration. The main takeaway is that only the Enterprise Board Export API is documented as a full archive with comments, and the .rtb backup is the only editable-looking format, which restores only into Miro.

Data type	Export method and output	Who can run it	Plan and limits
Board images	Board export to an image file for a board or selected frame. Output is a static picture with no editable shapes.	Member or owner, depending on sharing and export settings. Confirm in Miro's documentation.	Confirm plan requirement and whether comments are included in the image.
PDF pages	Board export to PDF. Output is a fixed layout for viewing and printing, not an editable board.	Member or owner, depending on board permissions. Confirm for your workspace.	Confirm page size, scaling for large boards and whether comments appear.
CSV tables	Export of table content from a board to comma-separated values. Output covers table data only.	Confirm which roles can export tables in your workspace.	Covers tabular content only, not the spatial layout of sticky notes or shapes. Confirm plan requirement.
.rtb board backup	Board export to a Miro backup file in the .rtb format. Output is a backup that Miro itself reads.	Member or owner, depending on settings. Confirm for your plan.	Up to 1 GB per file. Restores only into Miro, so it is not a portable board format.
Full archive with comments (Enterprise Board Export API)	API-driven export of board content, including comments, for archiving. Output format and fields must be confirmed against the API reference.	Admin or API token holder with the required scope. Confirm the permission model.	Enterprise plan requirement per Miro's documentation. Confirm rate limits, batch sizes and the exact output schema.

What does not leave Miro and what to do about it

The documented export paths carry images, PDFs and CSV tables out of Miro, but they do not carry the structure, connections and settings that make a board work as a shared workspace. Each card below names one of these gaps, the practical workaround, and what to confirm with Miro before you rely on it.

Editable board structure

Images, PDFs and CSV files are read-only snapshots, so shapes, text blocks, arrows and layout cannot be edited after export. The .rtb backup keeps the editable board, but it restores only into Miro. Plan to rebuild active boards in Excalidraw or Nextcloud Whiteboard, which store drawings in an open JSON format, and keep the original .rtb file with the archive so the source board remains readable. Ask Miro whether the .rtb file can be opened by any tool other than Miro before you assume it can be used for anything else.

Sticky note and frame relationships

Grouping, frame membership and the position of sticky notes inside frames are visual cues that flat exports flatten into a single picture. A CSV table keeps the text of each note but loses where it sat on the board. For workshops that depended on clusters, such as affinity mapping, record each cluster name and its notes in a table before export, then rebuild the groupings with frames or labelled sections in the target tool. Confirm with Miro which export paths preserve frame names or card positions in any form.

App and integration connections

Embedded apps, integration links and data pulled from other tools do not come along in an image, PDF or CSV export. A board that showed live Jira tickets or a linked document will show only the last rendered state, if anything. Make an inventory of every connected app and embedded object per board, note the source system and the owner of each connection, and decide whether the target tool will link to the source directly or hold a static copy. Confirm with your Miro administrator which integrations are installed on each team, since these settings are not part of a board file.

Sharing and permission settings

Board owners, team membership, editor and viewer roles and link sharing settings are account configuration rather than board content, so none of the export paths carries them. Before exporting, record who had edit access, who had view access, and whether any board was open to anyone with the link. Recreate these as Nextcloud sharing rules or collaboration room access in the target tool, and remove access from accounts that are leaving. Confirm with Miro whether the admin console or the Enterprise Board Export API lists sharing data per board.

Template and version history

Templates saved in your Miro account and the version history of each board are not part of the image, PDF or CSV paths. A template used for retrospectives or incident reviews becomes a blank starting point unless you save its layout as a board in the new tool. Version history is lost in the same way, so a board that changed weekly over a year leaves one snapshot. For boards with a long record, export a dated snapshot at each milestone and store it with the archive. Confirm with Miro whether the Enterprise Board Export API includes version history or only the current board with its comments.

Why a .rtb backup works as a safety copy

A .rtb file is a restore point that only Miro can read as a working board. Its main value is inside Miro: if a board is deleted by accident, or the account that owns it changes, the file lets you bring the board back in Miro. For a new platform, it gives you nothing to edit. Nextcloud Whiteboard and Excalidraw cannot treat it as a board of shapes, sticky notes and frames that people can move or revise. Treat each .rtb file as proof that a board existed in a given state on a given date, and store it where access is limited to the admins who run the export process.

This shapes the plan in three parts. Keep the .rtb files as a dated archive, named by board and export date, so you can show what a board contained before the cutover. For people who only need to read the content, export images or PDFs and place them in the new whiteboard's file storage or wiki. When comments must travel with the board, use the Enterprise Board Export API, which produces full archives with comments. Before you write a script against that API, confirm with Miro which fields and file types it returns for your plan, and ask your Miro admin who can run it.

Board size is the constraint to plan around. The 1 GB limit applies to each .rtb file separately, so a very large board may need to be split into several boards or exported in parts before it can be backed up. Start with an inventory: list each board with its owner, last edit date, approximate size and whether it has comments. Boards that exceed the limit move to the front of a manual export queue. Confirm the per-file limit, any guidance on splitting and whether export options differ by plan in Miro's own documentation, since these settings can change.

The sequence for a complete export and how to verify each step

This sequence produces a complete, verified copy of each in-scope board, starting with the .rtb archive and ending with a signed manifest. Each step creates an artifact and includes a check, so gaps are found while the source workspace is still available.

Inventory boards, owners and sizes
The workspace admin lists every board in scope with its owner, team, last edit date, frame count, comment count and data residency region. Export the list to a spreadsheet and sort it by owner so each person can confirm their own boards. This step is done when each board owner has signed off on their rows and the total matches the boards visible in the admin view. Nothing is exported until this list is approved.
Confirm plan and admin rights
Ask the workspace admin to confirm the Miro plan for the workspace and whether each board owner can run the export options you need. Export availability for images, PDFs and CSV depends on plan and owner settings, so test each option on one sample board before assuming it works everywhere. The Enterprise Board Export API requires the Enterprise plan. Record the plan, the admin account and the list of owners who can export. The workspace admin's sign-off is the gate before any export starts.
Export .rtb board archives first
Board owners export each in-scope board as a .rtb file, Miro's backup format, which is the copy Miro restores from. Store the files in a versioned location with the board ID and export date in each file name. To verify, import one sample .rtb into a test Miro workspace and compare its frame count and comments with the source board. Check each file size against the 1 GB limit for .rtb backups. Because .rtb restores only into Miro, label these files as archives. Record sign-off before exporting the next batch.
Run image and PDF exports
Owners export each board as images or PDF so people without Miro access can read the content. These files are read-only copies and cannot be edited outside Miro, so store them alongside the .rtb archives as readable references. To verify, count the pages or images against the frame count from step one, then open three boards at random and confirm that text and connectors are legible. The owner records sign-off for each board before the structured data step begins.
Pull CSV tables from structured boards
For boards that hold tables, such as a register, backlog or inventory built with Miro's table content, export CSV so the data stays usable in a spreadsheet or database. Boards without structured data can skip this step. To verify, compare row counts with the source table, confirm that headers match, and check that commas and line breaks inside cells survive when the file opens in a spreadsheet tool. CSV files carry no layout, stickies or drawing content, so keep them as data copies. The owner signs off per board.
Call the Enterprise Board Export API
For boards where comment threads are part of the record, the Enterprise administrator calls the Enterprise Board Export API, which is the route for full archives with comments. Confirm the endpoint, authentication method and output format in Miro's developer documentation before writing any script. Use a scoped token and revoke it after the run. To verify, compare the comment count in the output with the count recorded in step one for three sample boards, and confirm that each output file opens and parses correctly. Store the output with the matching .rtb archive and record sign-off.
Seal the archive and record a manifest
Gather every file into one archive folder with a manifest that lists each board ID, file name, file type, size and checksum. Generate checksums with a tool your team already uses and store the manifest with the archive. To verify, recompute the checksums on a copy in a separate location and confirm that every line matches. Record final sign-off from the board owners and the workspace admin in the manifest. The export is complete only when every board has an archive, a readable copy and a signed manifest entry.

Which export path fits which situation

On a lower Miro plan, export options depend on the plan and on the settings the board owner has chosen. Image, PDF and CSV exports may be available for some boards and not others, so confirm your access before you plan a migration around them. The board backup file is a separate path with its own limits.

Image and PDF exports: These give a visual record of a single board. Ask the board owner to confirm that export is enabled for each board you need.
CSV exports: These suit tables and lists on a board. Check a sample file to see which content it carries for your board types.
.rtb backups: These backups can be up to 1 GB, but they restore only into Miro. They protect against loss inside Miro, not against leaving the platform.
Owner settings: Ask the owner and your workspace admin whether export is switched on for the boards and the workspace.

A reviewer will receive static files such as images, PDFs and tables, not an editable board. Ask your admin to confirm in writing which export options your account has before you schedule the work.

What to plan before the renewal or termination date

Miro exports are slow to plan and easy to underestimate, so the decisions below need to be made before any board is touched. Each card names one decision or check that shapes the export, the storage and the data residency of the copies you create.

Set the export deadline early

Work backward from your contract end date and the notice date in your Miro agreement, then set an internal export deadline that leaves room for a second pass. Confirm with Miro's account team how notice must be given and whether access ends on the renewal date or after a grace period. Treat the notice date, not the expiry date, as the deadline for planning decisions.

Name owners for each board group

Assign a named person to every team or project that owns boards, including the people who can say whether a board is still in use. Owners decide which content matters, confirm that comments and sticky notes are complete, and sign off on the export. Boards without an owner are the ones most likely to be exported without review or lost.

Decide which boards to archive and which to rebuild

Sort boards into three groups: archive as images or PDFs, rebuild as editable Nextcloud Whiteboard or Excalidraw scenes, and delete. Miro's .rtb backups only restore into Miro, so a board that must remain editable outside Miro needs a rebuild plan. Keep the list in a spreadsheet so each decision has an owner and a date.

Confirm who holds Miro admin rights

Export options depend on plan and owner settings, so confirm which accounts are team admins, board owners and Enterprise administrators before the export starts. Remove or reassign owner roles that will leave the company, because boards owned by departed users can become difficult to export. Record the admin list and review it again before the final export.

Plan storage on your own servers

Decide where exported files will live before the first export runs, such as a Nextcloud instance under your control with its own backup schedule. Confirm the storage size needed for images, PDFs and CSV tables, and who can access each folder. Exports that land on personal laptops or shared drives outside your governance are a common source of later data sprawl.

Check residency of copies made during export

Exported files and any temporary copies you make should stay in a region your policy allows. Miro offers EU data residency on all plans, with Ireland as primary and Germany as backup, while US, Australian and Japanese residency is limited to Enterprise. Ask Miro in writing which region holds your boards today and whether any export step moves data elsewhere.

Questions buyers ask before exporting from Miro

How long does a full export from Miro take?

The duration depends on how many boards you hold, how large each board is, and how much of each board carries comments and attachments. No supplied figure gives a fixed duration, so the reliable way to answer is to measure it. Pick a representative sample of boards, export each one with the methods your plan allows, and time the work end to end, including the manual steps for naming files and checking results. Boards with dense sticky notes, many frames, embedded files or long comment threads take longer to review and to convert. Ask your Miro account team or administrator which export methods your plan and workspace settings allow, because that choice changes the work more than board count does. Then extrapolate from the sample, adding time for exceptions such as boards that fail to export or need owner permission.

Can our own team run the Miro export without outside help?

Often yes, for a small number of boards that you only need as images, PDFs or CSV tables. The harder part is the inventory and the decisions: which boards to keep, which to archive, which to rebuild in a self-hosted tool, and who approves each one. Most teams underestimate the review step. Image and PDF exports lose the editable structure, and the .rtb backups only restore into Miro, so an internal team should plan for an archive that is readable outside the product. Outside help is most useful when the volume is large, when boards carry regulated or client data that needs a documented handling procedure, or when the target platform must be built and tested before cutover. Consider a small internal pilot first to learn where the effort actually sits.

What does the export need from our organization?

The export needs people and places more than tools. Plan for these items before work starts:

Administrator access to the Miro organization, so you can see all team workspaces and confirm the export settings that apply to each plan.
Named board owners who can confirm that a board is current, which boards contain sensitive content, and who may approve its copy.
Storage with enough free space and defined access controls for images, PDFs, CSV files and any .rtb backups, placed in a location your security policy approves.
A test workspace on the target platform, such as a Nextcloud instance or an Excalidraw deployment, so that imported or rebuilt content can be checked before anyone relies on it.

Confirm with your Miro administrator whether board owners can export on their own, because owner settings determine which boards can be exported at all.

Do we need the Miro Enterprise Board Export API for a complete archive?

You need it if you want full archives that keep comments, and it is only described for Enterprise accounts. The Enterprise Board Export API is the route for full archives with comments, while the standard image, PDF and CSV exports do not carry the same content. If your boards have little discussion, or the comments are not needed after the move, the standard methods may be enough and the API adds scope you do not need. If comments are part of the record, confirm with Miro whether your plan includes the API before planning around it. The API changes the work from clicking export on each board to scripting, handling paging, storing output and validating it. That means someone with engineering skills must own the job, and the output still has to be converted into something people can read after the migration.

What does a fixed-scope Miro export engagement cover?

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope. For an export project, a written scope would normally define which Miro workspaces and boards are in scope, which export methods will be used, where the output is stored, how sensitive boards are handled, which target platform is set up, and what acceptance checks prove the result. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that scope. DeployOpen does not publish a price list. Ask for the list of exclusions too, such as boards you decide to archive without review, and for the acceptance criteria you will sign off on. Ongoing support and upgrades of the target platform are available as retainers and are priced separately.

What costs apply to exporting from Miro and moving the data?

Cost has four components: staff time, storage, the target platform and any outside work. Staff time is the largest and recurs during review. Storage is usually one-time for the archive plus ongoing backup. Target platform costs depend on the choice. Nextcloud Server is free under AGPL-3.0, but Nextcloud Enterprise is sold per user, with list prices starting at 71.29 euros per user per year for the Standard tier at 100 or more users, according to Nextcloud's pricing page. Excalidraw+ lists a Plus plan at $6 per user per month, according to its pricing page, and states SOC 2 Type 2 compliance. Confirm current prices on each vendor's page, since list prices change. Ask any outside provider for a quote that separates one-time work from recurring support, and state how boards are counted in scope.

How DeployOpen scopes and delivers a Miro data exit

DeployOpen approaches a Miro data exit as a fixed-scope engagement that starts with an inventory of what each board, owner and plan can actually export. We then plan, build and document the self-hosted destination inside your own infrastructure, so the archive is verified before any board is retired.

How we scope

Inventory boards by owner, team and plan, noting which export formats each one supports today.
Record which boards need full archives with comments, which need images or PDFs, and which only need a restore reference.
Agree the scope, deliverables and timeline in writing before any export or migration work starts.

How we build

Set up the target whiteboard, such as Nextcloud Whiteboard or Excalidraw, inside your own cloud account, data center or air-gapped network.
Script or run exports where your Miro plan and admin settings allow them, and capture any gaps for manual handling.
Test a sample of exported boards for completeness, readable images, legible tables and correct file storage before bulk transfer.

How we hand over

Deliver a written record of every export method used, its limits and the boards that could not be moved in full.
Document the archive structure, naming conventions, access rules and the location of each file in your environment.
Provide a retention and disposal checklist so your compliance team can confirm the Miro copies are handled as agreed.

How we support

Support the rollout of the new whiteboards to teams after the export is complete, within the agreed scope.
Offer ongoing support, upgrades and continuous testing as a retainer if you want the platform maintained over time.
Confirm with your Miro admin and legal team which export rights and contract terms apply to your organization before you start.

How to export your data from Miro