Two things need separating. Your workbook's STRUCTURE, yes: attach the .xlsx or .csv file to your description and its columns and sheets are read, becoming fields and entities in the plan you approve before anything is built. Your ROWS, no: there is no universal import screen, the application ships with demo data, and history is brought over either by hand across the perimeter that actually matters, or in one go through the database — a standard PostgreSQL database that belongs to you. In the other direction, though, the exit is immediate: CSV export from every list, JSON export of every dataset.
The structure, yes — your workbook gets read
A management spreadsheet always holds an application in embryo: sheets are entities, columns copied from one sheet to another are relationships, and "OK / in progress / overdue" codes are statuses. You don't have to translate any of that yourself: the .xlsx or .csv file attaches directly to your description, it is read, and what it contains feeds the generation of the plan.
That plan is shown to you BEFORE anything is built, and it can be edited: rename a field, drop a column that was only a copy, fix the list of statuses. That is where fidelity to your way of working is settled — not afterwards.
Your rows, no — and it is better said plainly
There is no universal "upload your file" screen in generated applications today. The application ships with realistic demo data, there so you can judge the tool on the evidence; it is not your data, and it can be deleted. One exception: MEASUREMENT entities — readings, sensor series, tracks — do get a file import route, because a measurement arrives as a file and never through a form.
For everything else, two routes. Re-entering by hand across the perimeter that matters, which is far shorter than it sounds (see below). Or loading in one go through the database: it is a standard PostgreSQL database driven by Prisma, and the application's code belongs to you, so a developer — or you, if you are comfortable — loads a CSV into it with a short script. Not supplied ready-made; simply possible, which is not the case in a closed tool where the database is never shown to you.
The history that matters is smaller than you think
The fear of "losing everything" assumes everything must come across. In practice, what serves day to day is the live set: open files, active clients, actual stock. The rest is archive, and an archive does not need to live inside the working tool — the spreadsheet switched to read-only keeps it perfectly well, and stays consultable.
So the migration that works is gradual: new cases in the application from week one, the live set brought over next, the spreadsheet frozen as an archive at the end. It is a few evenings' work rather than a project, and it has the merit of making you reread what you carry over instead of duplicating ten years of clutter.
The other direction: getting your data out, right now
The import question hides a more important one: will you be able to leave? Every list in the application carries a CSV export button for the rows on screen — filters included — in the format spreadsheets open correctly without any fiddling. The application's settings additionally offer a JSON export of each dataset.
On top of that comes what really sets it apart: the application's code exports as a ZIP archive or pushes to GitHub, and the database is yours. A tool you can walk out of in three clicks has no need to hold you: that is the best test to put any software through before pouring your data into it.