Your data should never be the reason you stay
The longer a business uses a system, the more valuable that system becomes. Customer histories grow. Orders, projects, contracts, and decisions accumulate. Processes begin to depend on them.
That value should belong to the business that created it.
It is easy for software companies to say that customers own their data. The more useful test is practical: can you take it with you in a form you can understand and use?
Sapugo now lets you export the tables in a workspace as a SQL file. It gives you the table structures and the records they contain in a format you can inspect and keep. You can archive the file under your own retention policy, use it as the starting point for a migration, or hand it to the team responsible for your next system.
We would rather earn your continued use than make leaving unnecessarily difficult.
A useful export, not a copy of our machinery
An export should contain your business data—not the internal machinery of the product around it.
The SQL file contains the tables you created and their rows. It leaves out Sapugo's internal tables, pages, and views. That keeps the result focused on the part that belongs to your business and avoids mixing it with implementation details that would not help you somewhere else.
This is deliberately different from a workspace backup. A backup is designed to restore a workspace in Sapugo, including the information needed to operate it here. The SQL export is designed to take your tables out.
That distinction matters. Portability is not the same as cloning an entire application.
What “portable” honestly means
The export is plain SQL rather than a proprietary Sapugo format. It describes the tables and writes their records as SQL statements. The result is a native SQL dump that can be restored directly into compatible databases. Other SQL dialects may require conversion.
It does not pretend that a complete business system can be moved with one click. Views, permissions, forms, workflows, business rules, and integrations express behavior—not just data. Rebuilding that behavior elsewhere still takes work, and another system may model it differently.
What the export gives you is the essential starting point: your structured business records, with their table definitions, outside Sapugo and under your control. It reduces the largest practical barrier to moving on without making promises that no serious migration can guarantee.
Built for real workspaces
You create an export from the Backups section of a workspace. Sapugo prepares each table and shows progress while the file is created. When it is ready, you download a compressed file named tables.sql.gz.
The export runs separately from your day-to-day work and does not change the tables it reads. Only one export runs for a workspace at a time, so repeated clicks cannot create a queue of competing jobs.
Security applies throughout the process:
- Only the organization owner or a member with the specific export permission can create and download a file.
- The prepared file is encrypted while it is stored.
- Downloads require an authenticated request and are not exposed through a public link.
- The stored file is deleted after seven days. Each workspace can create one SQL file per day.
Ownership needs an exit path
Data ownership is not only a sentence in a policy. It is a product capability.
You should be able to keep independent copies of important records. You should be able to evaluate another system without first negotiating access to your own tables. And if Sapugo is no longer right for you, getting the core of your data out should be the straightforward part.
Good software should give you reasons to stay: usefulness, reliability, service, and the freedom to keep building. Your data should never be the reason you cannot leave.