What Happens to Your Data When You Leave OutSystems

The question nobody asks until it's too late

When teams evaluate OutSystems, they think about speed to market, developer productivity, and total cost of ownership. Nobody asks about data portability. Why would they? You're just starting. The idea of leaving hasn't crossed your mind.

Years later, when licensing costs have doubled and the platform is dictating your roadmap, the question suddenly matters a great deal. You look at the applications you've built — the customer records, transaction histories, workflow states, audit logs, years of accumulated business data — and you ask: can I take this with me?

The answer is more complicated than it should be.

Your data lives in a real database — sort of

One of the less-discussed facts about OutSystems is that underneath the visual models, your data does sit in a standard relational database. SQL Server or Oracle for on-premises deployments, and typically SQL Server for cloud-hosted environments.

This sounds reassuring. A relational database is portable. SQL is universal. In theory, exporting your data should be straightforward.

In practice, there are three problems.

Problem one: access. If you're self-hosted (on-premises or in your own cloud), you likely have direct database access. You can connect with standard tools, run queries, and export tables. That's the good news.

If you're cloud-hosted on OutSystems Cloud, the situation is entirely different. OutSystems manages the infrastructure. You don't have direct database access. You can't SSH into the server. You can't connect with SQL Server Management Studio. Your data exists on servers you cannot reach, in a database you cannot directly query.

OutSystems provides some workarounds — you can expose data through REST APIs, use Integration Studio to create custom queries, or request database snapshots through support. But these are workarounds, not data access. There's a difference between owning your data and being allowed to ask for parts of it through approved channels.

Problem two: the schema isn't yours. Even when you can access the database, what you find there isn't the clean, normalized schema you might expect. OutSystems generates database tables from your entity definitions in Service Studio. The resulting schema carries OutSystems-specific conventions throughout.

Table names are prefixed with the module (eSpace) they belong to. Column names follow OutSystems naming conventions, not yours. Foreign keys reference OutSystems internal IDs. System columns track creation dates, update timestamps, and internal flags that your application logic may or may not depend on.

None of this is accidental or malicious. It's the natural consequence of a platform that abstracts away the database layer. You designed entities in a visual model; the platform turned them into tables. The translation was never meant to be human-readable, because you were never supposed to look at it directly.

Problem three: the data model is scattered. In a well-designed modern application, related data lives in related tables with clear relationships. In OutSystems, your data model is fragmented across modules.

A customer entity might live in one eSpace. Their orders in another. The workflow state governing order fulfillment in a third. References between these entities exist as OutSystems references — they work inside Service Studio, but in the raw database, they're just integer foreign keys pointing across module boundaries. Understanding which table references which, and why, requires knowledge of the OutSystems application structure, not just the database schema.

For a team trying to export data, this means you can't simply dump the database and load it into a new system. You need to understand the application's architecture to understand the data.

Cloud-hosted: the silent lock-in

The distinction between self-hosted and cloud-hosted deployments is critical when it comes to data portability, and it doesn't receive nearly enough attention.

With self-hosted OutSystems, your organization controls the infrastructure. You have database credentials. You can set up replication, run backups on your schedule, and extract data using standard tools. The data is locked into an OutSystems-shaped schema, but at least you have physical access to it.

Cloud-hosted customers have no such luxury. OutSystems manages the servers, the databases, the backups, and the network. Your access to your own business data is mediated entirely through the OutSystems platform.

Consider what this means in a migration scenario. You want to leave OutSystems. You need your data. Your options are:

1. Build REST APIs that expose every entity — time-consuming, and you're building throwaway code on the platform you're trying to leave. Rate limits and pagination add complexity. Binary data (documents, images stored as BinaryData attributes) is particularly painful to extract through APIs.

2. Request a database snapshot from OutSystems support — possible, but at OutSystems' discretion and timeline. You may receive a backup file, but it comes without documentation of the schema. Mapping tables back to your application logic is your problem.

3. Use the Platform Database Metamodel APIs — OutSystems exposes system tables that describe the database structure. With enough effort, you can reconstruct which entities map to which tables. This is not a documented migration path. It's reverse engineering.

None of these options are what a company accustomed to managing its own infrastructure would consider acceptable data access. Yet for cloud-hosted OutSystems customers, this is the reality.

It's worth noting that this isn't unique to OutSystems. Most cloud-hosted low-code platforms impose similar constraints. But OutSystems markets itself to enterprises that would never accept this level of data dependency from any other vendor. The disconnect between OutSystems' enterprise positioning and its cloud data access policies is striking.

The data you forgot about

When teams think about data migration, they think about their business entities: customers, orders, products, invoices. The data they defined and can see in Service Studio.

But OutSystems applications accumulate other data that's just as critical:

Process (BPT) data. If you use Business Process Technology — OutSystems' workflow engine — you have process instances, activity states, and execution histories stored in system tables. These represent the current state of your business workflows. Active processes, pending approvals, escalation timers — all of it lives in OutSystems system tables that aren't part of your entity model. Migrating without this data means losing the state of every in-flight process.

User and permission data. OutSystems manages users, roles, and permissions in its own system tables. If your application has thousands of users with specific role assignments, that mapping needs to come with you. It's not complex data, but it's easy to overlook until you realize your migrated application has no concept of who can access what.

Audit trails and logs. Many regulated industries require complete audit trails. If your OutSystems application logs actions to custom entities, that data migrates with your business data. But if you rely on OutSystems' built-in logging (the Service Center logs, LifeTime audit trails), those logs belong to the platform, not to you. Post-migration, that audit history is gone.

Site properties and configurations. Runtime configuration values stored as Site Properties in OutSystems have no equivalent in a standard application. They need to be identified, extracted, and mapped to whatever configuration mechanism your new stack uses — environment variables, configuration files, or a database-backed settings system.

Timer and scheduler state. If your application uses OutSystems Timers (scheduled jobs), the scheduling configuration and execution history are platform data. You need to identify every timer, understand what it does, and rebuild the scheduling in your target environment.

What a real data migration looks like

A responsible data migration from OutSystems isn't a database dump. It's a structured process that accounts for all of the complexity described above.

Step one: full inventory. Before touching any data, you need a complete map of every entity, every relationship, every system dependency. This means understanding the OutSystems application structure — not just the database. Which entities reference which? Which modules own which data? Where are the circular dependencies? What data is generated by the platform versus entered by users?

Step two: schema design for the target. The OutSystems-generated schema is not your target schema. You'll design a clean, normalized database structure for your new application — typically PostgreSQL for modern stacks — that represents your business domain without OutSystems conventions. This is an opportunity: the new schema can fix structural issues that were hard to change in OutSystems.

Step three: transformation scripts. With source and target schemas mapped, you build ETL (extract, transform, load) scripts that move data between them. This isn't a simple column rename. It involves resolving OutSystems internal IDs to natural keys, denormalizing or renormalizing data structures, converting data types (OutSystems' BinaryData to standard BLOB storage, their date handling to standard timestamps), and validating referential integrity in the new schema.

Step four: BPT and state migration. Active workflows need special handling. You can't just copy process tables — the new application won't have a BPT engine. Instead, you map the current state of each process instance to equivalent states in the new system's workflow. Completed processes become historical records. Active processes resume from their current step in the new environment.

Step five: validation. Row counts aren't enough. You need semantic validation — does the data make sense in the new context? Are relationships intact? Do calculated fields produce the same results? This is where most rushed migrations fail. The data looks complete until someone discovers that half the foreign keys don't resolve because a transformation step mapped IDs incorrectly.

The timeline question

Data migration is rarely the bottleneck in an OutSystems exit, but it's frequently underestimated. For a moderately complex application — say, 50-100 entities with BPT workflows — plan for the data migration workstream to run in parallel with application development for 4-8 weeks.

The critical path item is usually access. Getting database access from OutSystems (for cloud-hosted environments), understanding the schema, and building the initial entity map takes longer than the actual data movement. If you're considering a migration, start the data access conversation with OutSystems early — ideally before they know you're planning to leave.

Data portability is a choice — you just didn't make it yet

The data portability challenges described here aren't technical impossibilities. Your data can be extracted, transformed, and loaded into a modern database. The entity relationships can be mapped. The BPT states can be migrated. It's engineering work, not magic.

But it is work that requires deep understanding of both the OutSystems platform internals and the target architecture. It's not something a DBA can handle with a pg_dump and an afternoon. And it's not something OutSystems makes easy — because easy data portability would undermine the very lock-in that makes their licensing model work.

If you're evaluating your options, the first step is understanding exactly what data you have, where it lives, and what it would take to move it. That's what a migration assessment does — and it's the one thing you can do before making any commitments.

Your data is yours. Getting it back shouldn't require a legal team. But knowing what's involved helps you negotiate from a position of knowledge, not hope.