Before You Ship a Task App, Test Its Data Export

A task app can look great during a demo. You create a task, assign it to someone, add a deadline, and move it across a board.

Then you click Export.

The download contains task titles and dates. The comments are missing. Attachments are only links. Completed work has disappeared because a filter was active.

The file opens, but it does not contain everything the team expected.

For developers, this is a useful reminder: an export button is a feature with its own requirements. Downloading a file is only the first step.

I run WhatsOnTech, where we publish guides about software and everyday business technology. This article looks at a question that matters to both software buyers and developers: can people take their work with them in a form they can actually use?

The example below uses a fictional task app. It is a suggested testing approach, not a claim that I tested every product mentioned.

Disclosure: I run the website linked in this article. This article was prepared with AI assistance.

Decide What the Export Is Supposed to Do

Before choosing a file format, decide why someone needs the export.

A manager preparing a weekly report may only need task names, owners, deadlines, and status.

A team moving to another app may need much more: descriptions, comments, checklists, attachments, and the relationships between records.

Someone recovering from data loss needs a tested restoration process.

These are different jobs.

An export designed for reporting can be useful without recreating an entire workspace. The problem starts when the interface calls that file a complete backup.

Write a clear description of the feature before building it:

Export the selected tasks and their main fields for spreadsheet reporting. Comments and attachment files are not included.

That explanation may sound less impressive than “Export everything,” but it sets an expectation the product can meet.

Understand the Work Before Choosing the Fields

A personal reminder and a shared project do not carry the same amount of information.

“Send the invoice” might need a title, deadline, and completion status.

“Prepare the new website homepage” could involve several people, review comments, image files, subtasks, and approval history.

This difference also matters when choosing software. Our Microsoft To Do vs Trello comparison explores the distinction between simple lists and work organised into stages.

For developers, the lesson is to export the information that gives a task its meaning.

A card titled “Update the page” is not very useful after migration if the page address, feedback, and assigned person have been lost.

Start by listing the fields people rely on during normal work. Then decide which export includes each field.

Use a Small Dataset With Deliberate Edge Cases

Testing with three tasks called “Task 1,” “Task 2,” and “Task 3” will miss many problems.

Instead, create a small test workspace with records that challenge the export.

Include:

• Two tasks with the same title but different IDs.
• One completed task and one archived task.
• A task without a deadline.
• A description containing commas, quotation marks, and line breaks.
• Text in more than one language.
• A task with several checklist items.
• Two attachments that share the same filename.
• A task with more than one comment.
• A deadline with a specific time.
• A date-only deadline with no time attached.

Record what you expect before downloading anything.

For example, your fictional workspace might contain 12 tasks, 7 comments, 4 checklist items, and 3 attachments.

Those counts give you something concrete to compare against. They are not proof of completeness by themselves, but they make missing data easier to notice.

Use invented information for this test. Real customer records are unnecessary.

Make Export Scope Visible

A common source of confusion is the difference between “what I can see” and “everything in the workspace.”

If a user filters the screen to show open tasks, should Export include only those tasks?

Either behaviour can be reasonable. It needs to be explicit.

The export screen could offer:

• Current filtered view.
• All tasks I am allowed to access.
• Include completed tasks.
• Include archived tasks.

Show a summary before the download:

This export includes 12 tasks, including completed tasks. Archived tasks are excluded.

For larger systems, the export should also explain its timing. If a team changes records while a long export is running, the resulting file may contain information collected at different moments.

Use a consistent snapshot where practical, or document how the export handles changes during generation.

The user should not have to guess what “all” means.

Choose CSV or JSON for a Clear Reason

CSV is useful for rows and columns. People can open it in a spreadsheet, sort tasks, and create simple reports.

JSON can represent nested information such as a task with several comments and checklist items.

Neither format guarantees completeness.

Format	Useful for	What needs attention
CSV	Spreadsheet reports and simple transfers	Nested records, text formatting, dates, and spreadsheet interpretation
JSON	Structured records and custom migration tools	Schema documentation, relationships, and importer compatibility
ZIP package	Records plus attachment files	File organisation, missing files, and a contents summary
PDF	A readable snapshot	Limited usefulness for importing structured data

A well-documented CSV may be more useful than an unexplained JSON file.

For a structured export, include a format version, export time, field descriptions, and a clear explanation of how records connect.

Keep stable identifiers. Two tasks with identical titles should remain distinguishable after export.

Learn From a Real Export Limitation

Trello provides a practical example of why these details matter.

According to Atlassian’s export documentation, board members can export raw JSON, while boards in Premium Workspaces can also be exported as CSV. Comments are not included in the CSV export.

For Workspace exports, including raw attachments is a separate option. Without it, the export links to attachments hosted on Trello.

Atlassian also states that importing the exported JSON or CSV to recreate a Trello board is not currently supported.

That does not make the exports useless. It means exporting, reporting, migration, and restoration are separate capabilities.

When evaluating any app, check the documentation for the exact export option you plan to use. Different formats and export levels can include different information.

Check Attachment Files, Not Just Their Names

An attachment entry may contain a filename and a web address without containing the file itself.

That can work while the original account remains available. It may fail later if permissions change, the file is removed, or the link expires.

If an export promises attachment files, check that they are actually present.

Download a sample package, disconnect from the original service, and try opening the included documents and images.

Also test duplicate filenames. Two different files named “brief.pdf” should not overwrite each other.

A package can keep files in separate folders based on task or attachment IDs. A contents list can connect each file to its original record.

If a file could not be included, report it clearly. A successful download message should not hide skipped attachments.

Keep Dates and Text Meaningful

Dates deserve more attention than they usually receive.

“05/06/2026” can mean different dates depending on the reader’s locale.

A date-only deadline should remain a date. Converting it unnecessarily into a timestamp can make it appear on a different day in another time zone.

For timed events, use a documented representation with a time-zone offset or UTC convention. Where local scheduling matters, preserve the relevant time-zone information too.

Text needs similar care.

Check that:

• Commas stay inside the correct field.
• Quotation marks survive the export.
• Multiline notes remain attached to one record.
• Urdu and other non-English text remains readable.
• Identifiers with leading zeros stay intact.

A file that opens without an error can still contain changed values.

Compare actual field values, not just the appearance of the first few rows.

Separate Export, Sync, and Backup

These three features are related, but they serve different purposes.

An export provides a copy of selected information.

Sync carries changes between connected locations.

Backup is intended to support recovery under defined conditions.

A team may use all three.

For example, syncing a folder can make an exported file available on another computer. It does not automatically protect that file from a deletion that also syncs.

Our guide to cloud backup versus sync explains this distinction from the user’s perspective.

For your own app, describe recovery in practical terms:

• Which records can be recovered?
• How old can the recovery point be?
• How long are copies retained?
• Are attachment files included?
• What access is required to restore them?
• Has the recovery process been tested?

An occasional manual export can contribute to a backup plan. Its value depends on its coverage, storage, age, and whether someone can use it to recover the information they need.

Test the Return Journey

If your app promises restoration, test the complete journey.

Create a test workspace, export it, and restore it into a separate empty test environment.

Then compare the result with the original.

Check record counts, field values, attachment contents, and relationships. Make sure comments belong to the correct tasks and checklist items retain their completion status.

If the destination creates new IDs, verify that the relationships are mapped correctly rather than expecting every ID to remain unchanged.

Repeat the import.

Does it create duplicates? Update existing records? Refuse to continue? The behaviour should be deliberate and documented.

If your app supports export but not import, say so. Do not describe a readable archive as a tested restore package.

Never delete the original workspace just to find out whether restoration works.

Treat Spreadsheet Export as a Security Feature

User-entered text may behave differently after it leaves your application.

Some spreadsheet programs interpret values beginning with certain characters as formulas. This creates a risk known as CSV or formula injection.

Correctly escaping commas and quotation marks does not, by itself, solve that problem.

OWASP notes that protections depend on the spreadsheet application and how the file is opened, saved, and reopened.

For a related DEV discussion, see spreadsheet exports and formula-injection controls.

Keep the original data unchanged in your application. Apply suitable handling when creating a spreadsheet-facing export, and test it with the applications you support.

A separate machine-readable export may be appropriate when users need exact original values.

Export permissions also matter. The download must not reveal private fields or other users’ records simply because the export query has fewer restrictions than the normal screen.

Make Large Exports Honest About Failure

A small workspace may export quickly. A large one may require background processing.

Give the job clear states such as preparing, ready, failed, or completed with omissions.

If only part of the data was exported, say so. Provide a useful summary of what was included and what failed.

Avoid giving every download the same filename. A descriptive name with an export date makes older copies easier to distinguish.

Protect the generated file appropriately. A private workspace should not become a publicly accessible download.

If download links expire, tell users when they need to create another export.

Use a Release Checklist

Before releasing an export feature, check more than the download button.

Check	What a useful result looks like
Export scope	Included and excluded records are clear
Record counts	Counts match the selected scope
Text	Quotes, line breaks, and different languages survive
Dates	Date-only values and timed events retain their meaning
Attachments	Promised files are present and open correctly
Relationships	Comments and subtasks remain linked correctly
Permissions	Restricted records and fields stay restricted
Spreadsheet behaviour	Untrusted text is handled for supported applications
Repeated import	Duplicate handling follows the documented rule
Partial failure	Missing items are reported
Restoration	Tested if recovery is promised

Keep the test dataset so you can run these checks again when the data model changes.

A newly added field is easy to display in the app and easy to forget in an export.

Build the Exit Alongside the Entrance

Onboarding helps people bring their work into an app. Export helps them keep control of that work later.

Both deserve careful design.

Start with a clear purpose, test with realistic sample records, and explain the limits of each format. If you promise recovery, test recovery.

The goal is not to produce the largest possible download. It is to give people a copy they can understand and use for the purpose you promised.

Before shipping another task feature, try taking the existing work out of your app. What survives that journey tells you a great deal about the quality of the export.