How to export your data from Wrike

Wrike offers several export routes with different limits, and none of them is a complete account export on every plan. This guide sets out which route carries which data so you can plan a full extract before the contract ends.

On this page

How to export your data from Wrike starts with knowing what each route carries

Whether your driver is a renewal, a price change, a data residency requirement or a plain exit decision, the first step is knowing which Wrike export route carries the data you need. Wrike's Excel export is available on every plan, but it is capped at 65,000 rows and does not include comments or attachments. The full account backup is the route for attachments, and it is available on Business and above. BI Export applies only on Pinnacle and Apex. No Wrike-specific sources were supplied for this section, so confirm the row limit, how files are handled in each export, and which entitlements your plan includes in Wrike's current help documentation and with your account team before you plan a migration around them.

Map your project data to these routes before anyone runs an export. Tasks, dependencies, assignees and dates usually fit the Excel export if the total stays under the row limit, so count tasks across every folder and project you need to move. Comments and attachments are a separate problem and need the account backup or another retrieval path. Ask your Wrike administrator which plan the account is on, whether the backup can be generated by a user with the right role, and how long the file is retained for download. Those answers decide whether one export is enough or whether you need several passes, which affects the effort your internal team or an implementation partner will spend on the move.

Keep a record of what each export contains, because the gaps determine the rebuild work. Note which fields, custom columns, request forms, workflows and automation rules were present in the source and which were not. Also check whether any Wrike data sits outside the account backup, such as integrations or reports you rely on for governance. OpenProject's Excel import and any attachment handling will be easier to plan if you have a clear inventory of what arrived, what needs manual reattachment and what must be recreated by hand. The Wrike help center is the place to confirm these details before you commit to a timeline.

Which Wrike data exports, by method, format and limit

This table compares the three Wrike export routes you are likely to use: the Excel export, the full account backup and BI Export. Read each row for what it carries, who can run it and what to confirm before you plan a migration. The main takeaway is that the Excel export is the practical starting point for structured project data, while attachments depend on your plan.

Export methodWhat it carriesFormat and limitWho can run it and what to confirm
Excel export (all plans)Tasks, dates, dependencies, assignees, custom fields, folders and projectsExcel file, 65,000-row limit; split large workspaces into several exportsAvailable on every plan. Confirm which dependency and custom field columns appear in your export before you rely on them
Full account backup (Business and above)Attachments and the account data Wrike includes in the backupArchive of account data, with attachments includedBusiness and above only. Confirm with Wrike which fields, comments and folder structures are present in the backup you receive
BI Export (Pinnacle and Apex)Structured data for business intelligence reportingStructured export intended for BI tools; confirm the exact format with WrikePinnacle and Apex only. Confirm the export schedule, the tables included and whether it reproduces task relationships for rebuilding in OpenProject

What Wrike exports leave out, and how teams recover it

Wrike's Excel export covers rows and fields but leaves out several things teams rely on. Some gaps have a documented route, such as the full account backup on Business and above. Others depend on what Wrike confirms in writing, so they need a re-entry or archive plan. Assign each gap to a named owner before the export starts.

Comments and discussion threads

The Excel export does not carry task comments, so the reasoning behind many decisions disappears unless someone captures it. Ask Wrike in writing whether the full account backup includes comment threads on your plan and in what format. If it does not, each project owner should copy decision-bearing comments into the matching OpenProject work package description or a linked wiki page before the subscription ends. Keep a short index of which tasks were summarized and by whom.

Attachments and files

Attachments are not part of the Excel export. On Business and above, the full account backup is the documented route for them, so confirm how the files are laid out and whether file names keep a reference to their task. Match each file to its task before import. Where a file cannot be matched, a project lead downloads it manually from the task and records the source in a mapping sheet. Upload the files to OpenProject or to a linked Nextcloud instance under one retention rule.

Request forms and intake fields

Request forms collect structured input at intake, but a spreadsheet export stores only the resulting task fields. Export a sample of submitted requests, then list each form question, its field type and any routing rule attached to it. Rebuild those questions as custom fields on the matching OpenProject work package type. Decide whether intake moves to an OpenProject form or to a separate tool, and keep historical requests as archived records for audit.

Workflows and custom statuses

Custom statuses and the rules that move work between them live in configuration, so a spreadsheet export shows only the status label on each row. Document each status, its meaning and its allowed transitions from the Wrike admin settings. Then map each one to an OpenProject status and workflow. Check where two Wrike statuses will collapse into one OpenProject status, because that choice changes how historical reports read.

Approval history and decisions

Approval records are the item this topic cannot confirm from documented routes, so treat them as an open question for Wrike. Ask in writing which approval decisions, timestamps and approvers can be exported, and on which plans. If the answer is unclear, capture the approval state of active items while the subscription is still running, and file a dated record in a compliance folder. Compliance or legal should own the retention decision, not the project team.

What each Wrike plan tier can export

On Team and Free-to-Team accounts, the route you can rely on is the Excel export. It produces a spreadsheet of task and project data that you can filter, review and pass to another system. Treat it as the baseline extract. The supplied information does not place full account backup or BI Export on these tiers, so do not plan a migration around either until Wrike confirms it in writing.

  • Excel export on every plan: This is the only route the supplied information confirms for these tiers, so it sets the floor for what you can move.
  • 65,000-row limit: Each Excel export is capped at 65,000 rows. Large accounts need to split extracts by project or folder and count the rows in each file.
  • No comments or attachments: The spreadsheet carries structured task fields but not discussion threads or files. Plan a separate source for those.
  • Dependencies, assignees and dates: Run a test export on a small project and confirm which columns arrive, especially dependencies, owners and start and due dates.

Check your exact tier and contract terms with Wrike before you start, because plan names and included export features can change at renewal.

The export sequence for a complete Wrike extract

This sequence turns Wrike's separate export types into one verified, documented extract that the migration team can rely on. Each stage has a check, so gaps in rows, attachments or BI data are found before any data moves to OpenProject.

  1. Inventory projects, folders and workspaces

    The Wrike account administrator lists every workspace, folder, project and archived item that the migration must cover, with its owner and whether it is active. Record the plan tier, because it decides which exports are available: Excel on every plan, the full account backup on Business and above, and BI Export on Pinnacle and Apex. Confirm the list with the project owners so that no team's work is missed. The inventory is complete when every item has an owner and a scope decision recorded in a shared sheet.

  2. Export each workspace to Excel

    Export each workspace or folder to Excel from Wrike, using the export view that carries tasks, dependencies, assignees and dates. Excel exports are capped at 65,000 rows, so split any scope that would exceed the limit by folder or project, and keep the split rule the same for every file. Note that comments and attachments do not appear in these files, so they are handled in the next stage. The stage is done when every workspace in the inventory has at least one Excel file.

  3. Verify each Excel file before continuing

    The person who ran the export opens each file and compares its row count with the count shown in the matching Wrike view. They check that task names, dates, assignees and parent-child relationships are present and that no column is blank because of a formatting problem. Any file that is truncated or incomplete is re-exported with a narrower split. The stage is complete when every file passes these checks and the failures are logged with their fixes.

  4. Request the full account backup on eligible plans

    On Business and above, a Wrike account administrator requests the full account backup, which is the route for attachments that the Excel export omits. Save the backup file to a controlled location with access limited to the migration team. Open the archive and compare the attachment count with the number of files referenced in the Excel extracts to confirm nothing is missing. If the account is on a lower plan, record that attachments must be collected another way, and confirm the approach with Wrike before the migration plan is finalized.

  5. Export BI data where the plan allows

    On Pinnacle and Apex, an administrator exports the BI data that the reporting team relies on for portfolio views, so that the reporting structure is not lost in the move. Confirm with the reporting owner which datasets are needed, since BI output may not match the Excel layout. Store the exports next to the Excel files, and check that the row counts and date ranges match the Wrike reports they came from. The stage is complete when each required dataset is saved and checked, or when the team has recorded that the account's plan does not include this export.

  6. Record the extract manifest

    Create a manifest that lists each file name, source workspace, export date, row count, attachment status and the name of the person who produced it. Include the backup file and any BI exports, and note any file that was re-exported with a different split. The manifest becomes the reference for later reconciliation, so store it with the extract and keep it under version control or in a locked document. The stage is complete when every file in the extract has a manifest line.

  7. Obtain sign-off on the extract

    The migration lead confirms that the extract is complete, and the business owner of each workspace approves that its scope is correct. The data owner or IT security approver signs off on where the files are stored and who can access them. Record each approval in the manifest with a name, role and date, and keep any open exceptions listed. Only after this sign-off should the team begin mapping data into OpenProject, since later corrections are harder to trace back to a signed extract.

How to verify that the Wrike export is complete

Start by treating the export as unverified until you have counted it against the source. For each Excel file, compare the number of task rows with the task count visible in the Wrike folder, project or filtered view you exported from. Do this per file, not only for the whole account, because a file that reaches the 65,000-row limit will be silently short. If any file lands at or near that ceiling, split the export by folder or project and recount. Record the counts in a simple reconciliation sheet, with the Wrike figure, the row count and the difference, so that the comparison can be repeated later and shown to a PMO sponsor or auditor if needed.

Next, confirm that the fields you depend on survived the export. Open each file and check that task titles, start and due dates, assignees, and dependency references appear in columns you can map to their target, and that the date and time values parse as dates in your spreadsheet tool rather than as text. Sample at least a few tasks with parent tasks, multiple assignees and dependencies, and compare them line by line with the live Wrike task. Note what the export does not carry at all, such as comments and attachments on the Excel path, so that gap is written down as a known exception and not discovered during cutover. For attachments, list the files in the full account backup and match them against the attachment references in the work you exported. Any reference without a matching file is a gap to resolve before the account closes.

Finally, protect the evidence and prove the data can be used. Store the original export and backup files as read-only copies, with checksums recorded at creation, inside your own storage such as a controlled file share or object store in your environment, and keep a separate working copy for transformation. Then run a test import into the target tool, which for this path is OpenProject, on a non-production instance, and check the imported counts and a sample of records against the reconciliation sheet. Confirm with your vendor and your own security team which copies you are permitted to retain after the account closes and for how long, because retention rules are set by your organization and your contract, not by the export format.

What to plan before the Wrike renewal or termination date

Each card is a question to settle with Wrike or your internal stakeholders before the contract ends. Together they decide whether the export is complete, who signs off on it, and whether anyone can still reach the data once access is cut.

When must the full extract be verified?

Ask your team to agree a date by which the full Excel extract and any backup file must be opened, counted and checked against the live Wrike workspace. Confirm with Wrike when your access will end and whether it changes at renewal, so the verification window closes before that point. A late discovery of missing tasks leaves little room to fix them after access is gone.

Which plan tier unlocks attachments

The standard Excel export does not carry comments or attachments, so confirm your current plan before assuming the files are included. Full account backups for attachments require Business or above, and BI Export is limited to Pinnacle and Apex. If you are on a lower tier, ask Wrike in writing what it will provide and at what cost before the renewal decision is made.

Who owns each export

Name one person for the task and project export, one for the account backup, and one for any BI data pull. Each owner should record what they exported, when, and where the file is stored. Without named owners, partial exports tend to be assumed complete by the next person who inherits the folder.

How long archived files are kept

Decide how long the extracts, backup archives and attachment folders will be retained, and who approves deletion. Check whether your internal policy or a regulator sets a minimum period for project records, and store the files on infrastructure you control. Confirm that the retention plan covers files copied out of Wrike, not only data still inside it.

Which access must stay open during export

Identify the admin and user accounts that must remain active until every export and backup has been downloaded and verified. Ask Wrike whether admin rights, backup permissions and BI access are removed at contract end or at a later date. Remove access only after the verification sign-off, and keep a record of who held it.

Questions buyers ask before exporting data from Wrike

Is the Wrike Excel export enough to move my projects?

For task lists with dates, assignees and dependencies, the Excel export is usually the starting point, but it does not capture everything. It is available on every plan, is capped at 65,000 rows, and does not include comments or attachments. Discussion history, files and request forms need a separate extraction path. Custom fields, statuses and workflow settings also have to be mapped by hand on the OpenProject side. Run a test export from one representative project before you agree on the migration scope, and compare the columns with what your teams actually use.

How does the 65,000-row limit affect large Wrike workspaces?

The limit applies to each export, so a workspace with more rows than the cap has to be split into several files, usually by folder, project or date range. Splitting creates two risks: duplicate tasks where items appear under more than one parent, and broken parent-child links that leave subtasks detached from their parents after import. Effort grows with total row count, the number of projects and how cleanly your folder structure maps to OpenProject projects. Ask for a row count per project before scoping, and confirm with Wrike how the limit applies to your plan and account.

Can I export attachments from Wrike on a lower plan?

Attachments are not part of the Excel export on any plan, so they need a different route. The full account backup that includes attachments is available on Business and above. Teams on lower tiers should confirm with Wrike whether an upgrade, a temporary plan change or a manual download is the practical option, because plan rules can change. File count and total size drive the transfer work and the storage the OpenProject host needs. Keep attachment references in the export so files can be matched to the right work packages after import.

How long does a full extract from Wrike take, and what drives it?

The duration depends on the size and shape of your workspace, not on a fixed rule, so this page does not give a number. The main drivers are the number of tasks and rows, the volume of attachments, the number of folders and projects that need separate exports, and how many custom fields must be mapped. Manual review of exported data, the number of people who approve each step and whether you run a trial import first also add time. Ask for a timeline stated in the written scope, with the assumptions listed so you can see what would move it.

What do we need from our Wrike admins and account owners?

Your Wrike admins and account owners control most of what an extract can include, so involve them early. You will need someone with export rights to run the Excel exports, an admin or owner who can run the full account backup on eligible plans, and a confirmed list of workspaces, folders and projects in scope. Someone must also decide who may receive exported files, how long copies are kept and when they are deleted. Name a contact who can answer questions about custom fields, status meanings and historical ownership during field mapping.

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

Your team can run the Excel exports itself if it has the access and the time. Outside help usually concerns the parts that take the most judgment: mapping fields and statuses, splitting files without breaking hierarchies, handling attachments, validating imports and rebuilding workflows in OpenProject. DeployOpen plans, implements, integrates and documents self-hosted platforms in the client's own infrastructure, and most engagements are fixed-scope with the scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope, and ongoing support is available as a retainer.

How should we protect exported Wrike data during the move?

An export contains names, email addresses, task descriptions and possibly personal data in custom fields, so treat every file as sensitive. Store exports in a controlled location with restricted access, record who holds copies, and delete working files once the import is validated and retained copies are approved. Check whether any data falls under a retention or residency requirement before you move it. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit reports or attestations.

How DeployOpen scopes and delivers a Wrike data exit

DeployOpen, a Chainscore Labs company, treats a Wrike data exit as a written, fixed-scope engagement that starts with an inventory of what the export can and cannot carry. We then build, test and document the extraction and the target OpenProject environment in your own infrastructure.

How we scope

  • Inventory which Wrike plan you hold, since the Excel export is available on every plan but the full account backup needs Business or above.
  • Record the projects, tasks, dependencies, assignees and attachments that must move, and which of them exceed the 65,000-row Excel limit.
  • Agree in writing which data types are in scope, such as comments, attachments and custom fields, and which are accepted as manual rework.

How we build

  • Set up the target OpenProject instance in your own or your provider's environment, with the database and hosting choices confirmed beforehand.
  • Map Wrike columns and fields to OpenProject work package attributes, then test the Excel synchronization on a sample project before full runs.
  • Retrieve attachments from the full account backup where your plan allows, and check file counts and names against the source.

How we hand over

  • Deliver a written record of each export, mapping table, import run and any rows or fields that did not transfer.
  • Provide a reconciliation report comparing project, task and date counts between Wrike and OpenProject, with the gaps listed.
  • Document administration tasks for the OpenProject instance, including backups, upgrades and user provisioning, so your team can run it.

How we support

  • Ongoing support, upgrades and continuous testing are available as a retainer after the handover is complete.
  • Support can cover later OpenProject upgrades, such as moving between the 17.x releases, with changes tested before they reach production.
  • Ask for the support terms, response expectations and out-of-scope items in the written quote before work starts.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.