Research into how 1,000 companies handle CSV import revealed a recurring problem. Customers are still asked to prepare, correct, and split data outside the product before they can use it.

The research was conducted at Updog, a CSV and Excel importer for web apps. AI tools assisted with drafting and editing this article.

Over six months, we collected around 50 public signals about data import each week from companies in different countries. These came from product documentation, company blogs, LinkedIn posts, and other public discussions. During that time, we connected with more than 1,000 people on LinkedIn whose companies had published material about their import workflows and problems. The findings below bring together the recurring problems described in those sources.

Research findings

  • Around 30% described correcting the source file and uploading it again.
  • Around 29% described fixed templates, prescribed headers, or a specific column structure.
  • Around 14% documented row or file-size limits on imports.
  • Around 11% documented update restrictions, duplicate risks on re-import, or replacement rules that can remove existing data.
  • Around 5% described spreadsheet imports performed by support, onboarding, or implementation teams.

These requirements can overlap. A customer may need to reshape a spreadsheet, split it, and correct rejected rows before the same import is complete.

Fixing errors means going back to Excel

The file uploads, validation finds a problem, and the user gets an error report. Now they need to open their spreadsheet, locate the affected cells, correct them, save, and upload again. If the next attempt reveals another problem, they repeat the trip.

In some documented workflows, errors arrive by email in an attached file. The user reads that report but makes corrections in the original file. Two files are needed to fix data the application has already inspected.

The application knows which row failed and why. Showing the error beside an editable cell lets the user make the correction where the problem was found. Filters can narrow the view to invalid rows, while bulk edits handle repeated mistakes.

Updog uses an embedded spreadsheet for this. Users can filter invalid rows, edit cells, and replace repeated values while validation checks the result. Corrections happen before submission, without another upload.

The same trip back to Excel can begin before validation, when a file has to be reshaped to fit a template.

Templates make users reshape data the product could match

The customer already has an export from their old system, but the application asks them to copy it into another spreadsheet. Documented requirements include preserving column names and order, keeping unused columns, and matching category names exactly, including case.

A template is useful as an example. Making it the only acceptable shape adds preparation whenever another system exports the same information differently. Work Email and email can describe the same field. Likewise, Eng may mean the department the application calls Engineering.

Column matching brings the first decision into the import flow. Value matching handles the second, letting users resolve a department name once for the column instead of correcting every occurrence. The application supplies its fields and allowed values, while users confirm the remaining matches beside their data.

Row limits make users split and track their files

A file can match every required field and still exceed an import limit. The research found documented limits of 500 records per upload, with instructions to split larger files. At that limit, 10,000 records mean 20 uploads, each with its own validation and result.

If one batch fails and another succeeds, the user also has to remember which files to retry. They divide the data, name the pieces, track progress, and check that nothing was missed or uploaded twice.

A low limit may keep validation times, rendering costs, or server requests manageable. A commercial import component can also impose a plan limit. Asking users to split their files makes them work around those implementation and pricing constraints.

Updog is built to work with around one million rows in the browser. Its grid draws visible cells on a canvas instead of rendering the whole dataset as an HTML table, and filtering uses a worker. Practical capacity still depends on column count and available memory.

For customers bringing 10,000 or 50,000 rows, the value of that capacity is headroom. The file stays one dataset, and the interface helps locate the rows that need attention. Large-file support needs both capacity and tools to work on the data.

Once the whole file can be imported, the application needs to decide what to do with its rows. A first import may create records. Bringing the same file back to update them needs different behavior.

Bringing a file back can create duplicates or overwrite data

A user exports contacts, changes a few phone numbers, and imports the file again. They expect the existing contacts to receive those changes. Whether that happens depends on record identity and the meaning of the other cells.

The research found workflows where an absent ID column means creating records rather than updating them. In those same workflows, an empty cell in a mapped column can overwrite the existing value. A blank intended to leave a field unchanged can therefore clear it instead.

The review step should show which rows create records and which change existing ones. Empty cells need a clear meaning. Matching incoming rows against existing data using a stable key helps distinguish creates from updates, while change tracking lets the integration identify new, edited, and deleted rows.

The backend still controls permissions, duplicate prevention, and safe retries. A file that passed validation has not necessarily reached the database. After a partial save, the application needs to identify what succeeded and what still needs attention, so the user can continue without reconstructing the application's state in a local spreadsheet.

Support becomes part of the import flow

Some documented onboarding flows ask customers to fill out a spreadsheet and send it by email or live chat for the team to import. Completion depends on support availability, so customers may wait longer during busy periods.

Assistance can be valuable during a complicated migration. Routine file preparation creates a different kind of work. Someone checks the format, requests corrections, resolves mismatched values, and runs the import while the customer waits to use the data.

Giving customers tools to map, validate, and correct their own files can remove those routine handoffs. The same tools can help support prepare difficult files, leaving human help available for decisions that need it.

Give import the same care as the rest of the product

In 2026, AI can make an importer faster to build. These workflows show how much work the resulting product can still leave to the user. Data keeps moving between products, and importing it remains part of the experience customers depend on.

For teams whose main product is elsewhere, a capable ready-made importer is worth evaluating early. Test it with a real customer file, correct errors, and check what happens on a repeat upload. Choose one that handles that work well, then focus engineering time on the product your customers came to use.