OutSystems 11 (O11) is the mature enterprise platform running on .NET with SQL Server, supporting on-premises and cloud deployments. ODC (OutSystems Developer Cloud) is the cloud-native next generation, built on Kubernetes with Aurora PostgreSQL, fully managed on AWS. O11 offers more legacy integration options; ODC offers auto-scaling and lower operational overhead. Most large enterprises are still on O11 as of early 2026. New greenfield projects with no legacy constraints should evaluate ODC seriously.
Two Platforms, One Vendor
OutSystems made a strategic bet in the early 2020s: rebuild the platform from scratch as a cloud-native, container-based system. The result is OutSystems Developer Cloud (ODC). However, the majority of OutSystems' enterprise customer base is still on OutSystems 11 (O11), the mature .NET-based platform that has been in production since 2001. In November 2025, OutSystems announced that O11 and ODC would be unified as a single platform strategy — with O11 support extended indefinitely. This guide compares both platforms on every dimension that matters for a purchasing or migration decision.
Prerequisites
- Familiarity with basic OutSystems concepts (no hands-on required — this is a decision guide, not a build tutorial)
- An understanding of your project's requirements: existing legacy systems, team size, compliance needs, cloud vs on-premises constraints
Step-by-step guide
Compare the Architecture and Infrastructure
Compare the Architecture and Infrastructure
**OutSystems 11 (O11):** - Runtime: .NET on Windows Server - Database: SQL Server (most common), Azure SQL, or Oracle - Deployment: OutSystems Cloud (AWS-hosted), on-premises (customer-managed), or hybrid - Module model: Apps contain multiple Modules. Modules are compiled separately. - Architecture pattern: 4-Layer Canvas (End-User → Core → Foundation → Orchestration) - IDE: Service Studio (desktop, Windows/Mac beta) - Management: Service Center (operations) + LifeTime (deployment pipeline) **OutSystems Developer Cloud (ODC):** - Runtime: Containers on Kubernetes (AWS) - Database: Amazon Aurora PostgreSQL - Deployment: Public cloud only — fully managed SaaS - Module model: One App = One Module. No separate module hierarchy. - Architecture pattern: Domain-Driven Architecture - IDE: ODC Studio (browser-based, any OS) - Management: ODC Portal (replaces both Service Center and LifeTime) **Key implication:** If your organization requires on-premises deployment, air-gapped environments, or non-AWS cloud (Azure, GCP), O11 is your only option today. ODC is AWS-only, cloud-only.
Expected result: You understand the infrastructure requirements of each platform and whether your organization's deployment constraints eliminate one option immediately.
Review the Feature Comparison Table
Review the Feature Comparison Table
The following features exist in O11 but NOT in ODC as of early 2026: - **Traditional Web apps** — O11 only. ODC supports Reactive Web and Mobile only. - **SOAP Web Services** (consume or expose) — O11 only. ODC uses REST exclusively. - **Business Process Technology (BPT)** — O11 only. ODC has ODC Workflows (different implementation). - **Session Variables** — O11 Traditional Web only. Not available in Reactive or ODC. - **Integration Studio** (custom .NET extensions) — O11 only. ODC uses External Libraries (.NET 8, Lambda). - **Integration Builder** visual connectors (SAP, Salesforce, Dataverse) — O11 only. ODC uses direct API calls. - **Multi-tenant applications** — O11 only. The following features exist in ODC but NOT in O11: - **Auto-scaling containers** — ODC scales to zero and back up automatically. - **ODC Portal** unified console — combines deployment pipeline, monitoring, and configuration in one place. - **Secret Settings** (encrypted configuration values) — ODC only. O11 uses Site Properties (not encrypted at rest by default). - **App Security dashboard** with built-in vulnerability scanning — ODC only. - **Stages** (Dev → Test → Production) with container-based promotion — ODC only. O11 uses LifeTime environments.
Expected result: You can identify which O11 features your current or planned application depends on and determine whether ODC equivalents are available.
Understand the IDE Differences
Understand the IDE Differences
**Service Studio (O11 IDE):** - Desktop application (Windows installer required; Mac beta available) - Right panel: Interface, Logic, Data, Processes tabs - Processes tab contains BPT flows and Timers - Modules referenced via Ctrl+Q Manage Dependencies - Deploy via 1-Click Publish button (Green = ready) - Debug via Debugger tab with breakpoints in action flows **ODC Studio (ODC IDE):** - Browser-based — no install required, works on any OS - Layout nearly identical to Service Studio - No Processes tab (Timers are in app settings; ODC Workflows are a separate visual tool) - No inter-module dependencies (one app = one module; cross-app calls use Public Service Actions) - 1-Click Publish equivalent: Deploy button in ODC Studio - ODC Portal handles environment promotion (not done from the IDE) **Practical impact:** Switching from O11 to ODC Studio has a small learning curve but is not a ground-up relearn. The visual metaphors (entities, aggregates, action flows, screen editor) are identical. The main adjustment is the absence of the module dependency system.
Expected result: You know which IDE applies to your platform choice and what adjustments developers from an O11 background will need to make when working in ODC Studio.
Apply the Decision Framework
Apply the Decision Framework
Use this decision tree to guide your platform choice: **Choose O11 if ANY of these are true:** 1. Your organization requires on-premises or hybrid cloud deployment 2. You need to maintain existing O11 applications (most enterprises) 3. Your integration landscape includes SOAP services that cannot be replaced with REST 4. You need multi-tenancy built into the platform 5. Your app uses BPT processes that are not yet modeled in ODC Workflows 6. You have significant Integration Studio extensions (.xif files) with .NET code **Choose ODC if ALL of these are true:** 1. Cloud-only (AWS) deployment is acceptable 2. Greenfield project — no existing O11 codebase to migrate 3. No SOAP dependencies 4. Team is comfortable with no-module architecture 5. Auto-scaling and zero-ops infrastructure is a priority 6. Budget: ODC starts at $36,300/year — confirm this fits your budget **The nuanced middle ground:** Many organizations run O11 and ODC in parallel. New applications go on ODC; existing O11 apps stay on O11. OutSystems supports coexistence via a strategy of secure cross-platform service calls.
Expected result: You have a clear recommendation for your project based on the decision criteria. If the answer is not clear, the 'coexistence' strategy is documented and viable.
Assess the Migration Path from O11 to ODC
Assess the Migration Path from O11 to ODC
OutSystems provides a **Conversion Assessment Tool** (GA November 2025) that analyzes an O11 application and produces a readiness score for ODC migration. The tool identifies: - O11-only features used (SOAP, BPT, Session Variables, Integration Studio, Traditional Web screens) - Entity attribute type mismatches (O11 SQL Server types vs ODC Aurora PostgreSQL types) - Module dependency complexity - Estimated migration effort **Migration phases:** 1. Run Conversion Assessment on your O11 modules 2. Resolve O11-only feature dependencies (replace SOAP with REST, BPT with ODC Workflows, Session Variables with Client Variables) 3. Refactor multi-module architecture to single-module per app 4. Test in ODC Studio development environment 5. Stage promotion via ODC Portal **Timeline expectations:** A simple CRUD application with no legacy integrations: 1-4 weeks. A complex enterprise app with BPT, SOAP, and multi-module dependencies: 3-12 months. **Database differences to note:** O11 uses SQL Server syntax — `TOP 10`, `GETDATE()`, `+` for string concat. ODC uses PostgreSQL syntax — `LIMIT 10`, `NOW()`, `||` for string concat. Advanced SQL queries (not Aggregates) must be rewritten for the correct dialect.
Expected result: You understand the migration effort required for your specific O11 application and have a phased plan for moving to ODC if that is the goal.
Complete working example
1=== O11 VS ODC SIDE-BY-SIDE REFERENCE ===23INFRASTRUCTURE:4 O11 | .NET on Windows Server, SQL Server/Oracle/Azure SQL5 ODC | Kubernetes containers on AWS, Aurora PostgreSQL67DEPLOYMENT:8 O11 | Cloud (AWS), On-Premises, Hybrid9 ODC | Public Cloud (AWS) only — fully managed SaaS1011IDE:12 O11 | Service Studio (desktop Windows/Mac)13 ODC | ODC Studio (browser-based, any OS)1415APP STRUCTURE:16 O11 | Apps → Modules (4-Layer Canvas)17 ODC | Apps = Modules (Domain-Driven Architecture)1819MANAGEMENT:20 O11 | Service Center (ops) + LifeTime (deploy pipeline)21 ODC | ODC Portal (unified: ops + deploy + config)2223CONFIG:24 O11 | Site Properties (not encrypted by default)25 ODC | Settings + Secret Settings (encrypted)2627O11-ONLY FEATURES:28 - Traditional Web apps29 - SOAP consume/expose30 - Business Process Technology (BPT)31 - Session Variables32 - Integration Studio (.xif extensions)33 - Integration Builder (SAP, Salesforce)34 - Multi-tenancy35 - On-premises deployment3637ODC-ONLY FEATURES:38 - Auto-scaling to zero containers39 - Unified ODC Portal40 - Secret Settings (encrypted)41 - App Security dashboard42 - Container-based stage promotion4344SQL SYNTAX DIFFERENCES:45 O11 (SQL Server) → ODC (PostgreSQL)46 TOP 10 → LIMIT 1047 GETDATE() → NOW()48 'a' + 'b' → 'a' || 'b'49 ISNULL() → COALESCE()50 NOLOCK hint → not supportedCommon mistakes
Why it's a problem: Assuming all Forge components work on both O11 and ODC
How to avoid: Check the compatibility badge on each Forge component. Some components use Integration Studio extensions (.xif) which are O11-only. Look for components labeled 'ODC Compatible'. The ODC Asset Library also has a growing set of ODC-native components.
Why it's a problem: Starting an ODC project and realizing mid-build that a key integration (e.g., SAP via Integration Builder) is O11-only
How to avoid: Audit all integration requirements before choosing the platform. If SAP OData, Salesforce via Integration Builder, or SOAP services are needed, O11 is required today. ODC integrations require custom REST API implementations.
Why it's a problem: Trying to replicate the O11 multi-module architecture in ODC
How to avoid: ODC's 'one app = one module' design is intentional. Instead of multiple modules, use separate ODC apps that communicate via Public Service Actions. Redesign your architecture around domains, not technical layers.
Why it's a problem: Using advanced SQL queries from O11 unchanged in ODC
How to avoid: ODC uses Aurora PostgreSQL, not SQL Server. Rewrite SQL Server-specific syntax (TOP, GETDATE, ISNULL, NOLOCK) to PostgreSQL equivalents (LIMIT, NOW(), COALESCE). Test every advanced SQL query in the ODC Studio SQL editor.
Best practices
- Run the OutSystems Conversion Assessment Tool before starting any O11-to-ODC migration — it saves weeks of discovery
- For new O11 projects, avoid SOAP and BPT if ODC migration is a future goal — use REST and timers instead
- In O11, use the 4-Layer Canvas architecture strictly — this makes eventual migration to ODC's domain model much easier
- In ODC, use Secret Settings for all credentials and API keys — they are encrypted and managed per environment
- Test advanced SQL in ODC early in development — PostgreSQL syntax differences from SQL Server catch many teams off guard
- Run O11 and ODC in coexistence during migration rather than attempting a big-bang switch — minimize business disruption
- Engage OutSystems Professional Services for migrations involving BPT processes — BPT-to-ODC-Workflows conversion is non-trivial
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
We are an enterprise team currently using OutSystems 11 with the following characteristics: 15 modules, Integration Builder for Salesforce, 3 BPT processes for employee onboarding, SOAP integration with our legacy ERP, and deployment on-premises. Evaluate our readiness for migrating to OutSystems Developer Cloud (ODC). List the specific blockers, estimate relative effort for each, and suggest a phased migration approach.
I am starting a new greenfield web application project and evaluating OutSystems ODC vs O11. The app needs: PostgreSQL or SQL Server database, REST API integrations with third-party services, role-based access control, and cloud deployment. Which platform would you recommend and why? List any ODC limitations I should know about before starting.
Frequently asked questions
Will OutSystems shut down O11 now that ODC exists?
No. At the November 2025 ONE Conference, OutSystems explicitly announced that O11 support is extended indefinitely and that O11 and ODC are unified as a single platform strategy. Enterprises with large O11 investments can continue on O11 with full vendor support while evaluating ODC for new projects.
Can O11 and ODC apps communicate with each other?
Yes, via a coexistence strategy. O11 apps can expose REST APIs that ODC apps consume, and vice versa. The recommended pattern during migration is to keep business logic in O11 apps while exposing it as versioned REST APIs, then incrementally replace O11 modules with ODC apps as migration progresses.
What database can I use with ODC? Can I connect to my existing SQL Server?
ODC uses Amazon Aurora PostgreSQL as its internal database — you cannot change this. For integrating with existing SQL Server or other external databases, ODC supports connecting via External Libraries (custom .NET 8 code) or REST/SOAP APIs. Direct external database connections like O11's Integration Studio-powered external tables are not natively supported in ODC.
How does ODC pricing compare to O11?
Both platforms are priced by Application Objects (AOs) rather than per developer seat. ODC starts at approximately $36,300/year for a standard tier including Dev, Test, and Production environments. O11 pricing is similar in structure but varies based on deployment model (cloud vs on-premises). Personal Edition development environments are free for both platforms.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation