If you talk to OutSystems about ODC, the message is clean: ODC is the future. Cloud-native, container-based, modern architecture. O11 is the legacy platform. The direction of travel is clear.
That’s not wrong. But it’s also not the full picture, and making a platform decision based on it will cost you.
The honest version: ODC is genuinely the right choice for some organisations right now. For others, it’s the right choice in two years. For others, O11 is still the correct answer today and will be for a while. The decision depends on where you are, what you’re building, and what you’re willing to trade.
This is the framework we use when clients ask us which platform to build on.
What actually changed between O11 and ODC
ODC isn’t a new version of O11. It’s a different architecture.
O11 is a traditional three-tier application platform, application server, database, presentation layer. It runs on infrastructure you control or that OutSystems manages. It has a 20-year production track record. The tooling is mature, the community is large, the documentation is deep, and the edges of the platform are well understood.
ODC is cloud-native from the ground up. Applications run as containers. The database layer is abstracted, you don’t own the database in the same way. The deployment model is fundamentally different. The integration patterns are different. The module architecture is different. The security model is different.
These aren’t incremental changes. They’re architectural shifts. Which means experience on O11 doesn’t transfer completely to ODC, and assumptions you’d make on O11 will get you into trouble on ODC if you carry them across uncritically.
Where ODC wins
New builds with no legacy baggage.
If you’re starting from scratch, building a new product or internal tool, with no existing integrations and no O11 codebase to carry forward, ODC is worth serious consideration. The architecture is cleaner, the scalability story is stronger, and you’re building on the platform OutSystems is actively investing in.
Cloud-native requirements.
If your organisation has mandated cloud-native infrastructure, containers, auto-scaling, managed services, ODC aligns with that naturally. O11 can run in the cloud but it isn’t cloud-native in the same way ODC is.
Simpler integration surface.
ODC’s REST-first integration model is cleaner than O11’s for straightforward API integrations. If your external dependencies are modern REST APIs with good documentation, ODC handles them well.
Smaller, focused applications.
ODC’s architecture is well-suited to bounded, focused applications, a customer portal, an internal tool, a workflow application. The constraints of the platform are less of a problem when the scope is contained.
Where O11 still wins
Existing O11 platforms.
If you have a substantial O11 codebase, years of development, live integrations, business-critical workflows, you are not migrating to ODC in the near term. The migration path exists but it’s not a lift-and-shift. It’s a rebuild with reference to the original. For a platform of any meaningful size, that’s a multi-year programme.
Complex integrations.
O11’s integration tooling is mature. SOAP, REST, SAP connectors, custom extensions, direct database connections, twenty years of enterprise integration patterns are well-supported and well-documented. ODC’s integration layer is improving but it isn’t there yet for heavy enterprise integration requirements.
Multi-tenancy at scale.
O11’s multi-tenant patterns are established. The site property model, the entity-level tenant scoping, the Timer architecture, these are understood, battle-tested, and documented. ODC handles multi-tenancy differently, and the patterns are still maturing.
Advanced SQL and data layer control.
In O11 you can drop into Advanced SQL with full control over your queries, execution plans, and indexes. ODC abstracts the data layer more heavily. If your application has significant reporting or analytical requirements that need precise query control, O11 gives you more to work with today.
Large development teams.
O11’s LifeTime deployment and team collaboration tooling is mature. ODC’s equivalent is newer and has fewer capabilities today. For a large development team working across multiple applications, O11’s operational tooling is more developed.
The questions that actually determine the answer
Do you have an existing O11 platform?
If yes, stay on O11 unless you have a specific, compelling reason to migrate and the budget and timeline to do it properly. “ODC is the future” is not a compelling reason. A business case with a migration plan, a cost model, and a realistic timeline is.
What are your integration requirements?
List every external system your OutSystems platform needs to talk to. For each one: is it a modern REST API or something older? Is there a connector for it? What happens when it goes down? If your integration surface is complex, legacy systems, SOAP services, direct database connections, SAP, O11 is the safer choice today.
What are your data and reporting requirements?
If you need complex reporting, significant analytical queries, or precise control over your data layer, O11 gives you more headroom. If your data requirements are standard CRUD with simple reporting, ODC handles it fine.
What’s your team’s experience?
An experienced O11 team building on ODC is not starting from zero, but they’re not starting from their full capability either. The patterns are different enough that there will be a learning curve and a productivity dip. Factor that into your timeline and budget.
What’s your 3-year horizon?
If you’re building something you expect to run and grow for the next five to ten years, the platform trajectory matters. OutSystems is investing heavily in ODC. O11 will be supported for the foreseeable future but the innovation is on ODC. If you’re building for longevity, the direction of platform investment is a relevant input.
The migration question
Should you migrate from O11 to ODC?
Honest answer: probably not yet, unless one of the following is true.
You’re at the start of a major rebuild anyway, new requirements that would require significant rework on O11 regardless, so the migration cost is partially absorbed.
Your O11 platform is small enough that migration is a months-long project rather than a years-long one.
You have a specific ODC capability that O11 genuinely can’t provide and that capability is business-critical.
For most organisations with meaningful O11 platforms, the correct answer right now is: invest in your O11 platform, watch ODC mature, and plan a migration for when the platform gaps close and the tooling catches up. That’s probably a 2–3 year horizon for most complex platforms.
Migration for the sake of being on the “right” platform is expensive and rarely delivers proportional value. Migration because ODC genuinely serves your requirements better than O11 is a different conversation.
What we actually recommend
New build, limited integration complexity, cloud-native mandate: ODC.
Existing O11 platform, complex integrations, large team: stay on O11, plan migration carefully.
New build, complex enterprise integrations, large team, significant data requirements: O11 today, ODC migration in 2–3 years when the platform matures.
Existing O11 platform, small scope, considering ODC for a new adjacent application: ODC for the new build is worth evaluating, running both in parallel is a legitimate strategy while you assess.
The platform decision isn’t permanent. But it’s also not free to get wrong. Take the time to make it on your requirements, not on the direction of the marketing material. It’s exactly the kind of question that should be settled in discovery, before anyone scopes a build.