Most estimates cover the development effort to convert the applications. On a large portfolio, the coexistence period alone can rival it, because both environments run and are paid for until the last application moves. Then there is the refactoring done on O11 before anything moves at all, the re-testing of every converted application against behaviour it already had, the retraining of developers on a different architecture, and the delivery capacity spent reproducing functionality that already works.

There is also nothing forcing the timing, which surprises organizations that have been planning around a deadline. OutSystems had committed to supporting O11 at least through March 2029. That was a floor, but most of the market read it as an expiry date. OutSystems' current support terms contain no such date, committing instead to support both platforms for as long as there is demand, with at least five years of notice before that changes.

So the pace is yours to set, which turns the decision into a financial one. Is the migration worth what it actually costs, and does anyone in the organization have the full number?

That does not make the migration a bad idea. New capability lands in ODC, including the AI features OutSystems is investing in, and for teams that need elastic scale or regional data placement the cloud-native architecture is a genuine improvement on a VM-based one. OutSystems is a capable enterprise platform and ODC is a serious product.

What the conversion actually involves, which costs get left out of the estimate, and how to compare the three options honestly is the subject of the rest of this article. Some organizations will read it and decide to convert. Others will stay on O11 for another few years, which is now a fully supported position rather than a delay tactic. Both are defensible. Committing to either without costing it properly is not.

What OutSystems says about the transition

OutSystems' own position is more reasonable than a lot of the migration content online suggests.

The strategy is coexistence rather than replacement, and it has hardened into a unification message. OutSystems now positions O11 and ODC as one platform rather than a predecessor and a successor: O11 remains the base for enterprise-scale, heavily customized, and on-premises workloads, while ODC handles new cloud-native and AI development. Its own framing is that customers no longer have to worry about an O11 to ODC migration at all.

Read that carefully before writing a business case. The vendor whose new architecture you are planning to move to is telling you that you do not have to move.

OutSystems also provides real tooling for the transition. In November 2025 it released the O11 to ODC Conversion Assessment Tool, the first component of a new App Conversion Kit. Installed from Forge onto your own O11 infrastructure, it assesses applications for conversion readiness by identifying the code, data, and infrastructure patterns that will not carry over. That is a meaningful improvement on assessing a portfolio against the published patterns manually.

There is also data interoperability between the two platforms. ODC applications can consume O11 entities as external entities, without migrating the underlying data first. For anyone planning a phased approach, that removes one of the harder sequencing problems, since applications can move before their data does.

Taken together: OutSystems has removed the deadline, built assessment tooling, and supports running both platforms indefinitely. This is not a vendor forcing a march.

The cost problem is real anyway, and it sits in the work the tooling does not do.

What actually changes between O11 and ODC

ODC is not a version upgrade. It is a different application architecture, and the differences are structural rather than cosmetic.

The module concept is gone. O11 organizes code into applications containing modules. OutSystems' own documentation states that the module concept does not exist in ODC, that the nearest equivalent is an asset, and that the way O11 groups modules into an application has no ODC equivalent, because each asset has its own lifecycle and apps are linked by weaker dependencies. A portfolio built around a module-based reference architecture therefore needs its structure redesigned rather than translated, and on large estates this is often the bulk of the preparatory work.

Traditional Web Applications have no path across. ODC builds reactive web and mobile apps; the Traditional Web model does not carry over. If any part of your portfolio is still Traditional Web, it has to be rebuilt as Reactive before conversion tooling is relevant to it at all. Teams that completed a Reactive migration years ago are in a materially better position than those that did not.

Custom code moves to a different model. OutSystems documents that ODC replaces O11 Extensions with external libraries. They remain the way to extend apps with .NET code, but instead of Integration Studio you use the External Libraries SDK, develop in your own .NET IDE, and upload the result into the ODC Portal. That is a different build and deployment path, not a rename. Code that assumes in-process execution, shared state, or low-latency local calls needs rethinking, and the extensions that break are usually the ones nobody has touched in five years.

Deployment and isolation change. ODC is containerized with independent application lifecycles, which is the point of the architecture. Applications that were implicitly coupled through shared modules in O11 need explicit contracts in ODC.

The database engine changes. O11 runs on SQL Server or Oracle. ODC uses Amazon Aurora Serverless with PostgreSQL compatibility. Any hand-written SQL in your portfolio has to be reviewed against PostgreSQL syntax, queries against external databases need ANSI-92 syntax, and DateTime attributes are stored in UTC. For estates with significantly advanced SQL, this is usually the most expensive single item on the list, and it is why the Assessment Tool has a data-patterns category at all.

Hosting is no longer a straight choice between cloud and on-premises. In March 2026 OutSystems released ODC Self-Hosted, which runs applications, data, and AI agents in its own private cloud or on-premises Kubernetes. It is a hybrid model rather than true self-hosting: platform services, including build and deployment, stay with OutSystems while runtime applications run in your infrastructure. That satisfies data residency requirements. It does not satisfy an air-gapped or fully sovereign one, and the option is new enough that ecosystem support is uneven.

An enterprise architect reading that list will recognize the pattern: this is a re-architecture with a familiar visual language, not a port.

Why there is no automated conversion path

OutSystems' own documentation is candid about this.

Its conversion patterns documentation splits the work across two phases. Before conversion, O11 applications are adjusted so they are compatible with ODC. After conversion, further changes are required before the new ODC applications will be published. The Assessment Tool identifies the patterns involved and supports planning the target architecture, and the same documentation states that OutSystems is still developing automation to handle some of the conversion itself. As of writing, assessment is automated. Conversion largely is not. This is the claim in the article most likely to change, so check the current state of the App Conversion Kit before relying on it.

The reason is architectural, not a gap in the roadmap. A converter can translate syntax. It cannot decide how a module-based architecture should be decomposed into applications and libraries, because that decision depends on ownership boundaries, release cadence, and team structure. Those are organizational facts the tooling has no access to.

Three practical consequences for planning.

Assessment is not estimation. The tool tells you what needs fixing. It does not tell you how long fixing it will take in your codebase with your team, and schedules go wrong in the distance between those two numbers.

Preparation happens on O11. Much of the refactoring work is done in your existing environment before anything moves. That work has real cost and produces no visible new functionality, which makes it politically difficult to fund.

The long tail is the problem. Straightforward applications convert reasonably well. The ones carrying five years of accumulated custom code, unusual integration patterns, and undocumented behavior consume disproportionate effort, and they are rarely the ones sampled during a proof of concept.

The costs that get missed

Most O11 to ODC estimates cover developer effort for conversion. That is one line in a longer list.

Dual running. During coexistence you pay for both environments. This is the largest omitted cost on most business cases, and it scales with how long the transition takes rather than with how many applications you move. On a large portfolio phased over two or three years, the cumulative dual-licensing and dual-infrastructure cost can rival the conversion effort itself. Coexistence is the right strategy technically. It is expensive, and OutSystems' own recommendation of a phased approach makes budgeting for it non-optional.

Pre-conversion refactoring on O11. Reactive migration where Traditional Web still exists, architectural restructuring away from modules, custom code rework. Weeks to months of effort delivering nothing a business stakeholder can see.

Re-testing. Every converted application needs functional and regression testing against behavior it already had. Where organizations lack automated test coverage, and many O11 portfolios do, this is manual work multiplied by application count. Behavioral parity, not a feature checklist, is the acceptance criterion, and proving it is more expensive than most plans assume.

Retraining. Developers competent in O11 are not automatically productive in ODC. The architectural model differs, the deployment model differs, and the custom code execution model differs. Budget for a learning curve and a temporary velocity drop, not just a training course.

Integration rework. Every downstream consumer, connector, and scheduled job is a dependency. OutSystems interoperability covers a good deal of this, spanning data access, logic calls between the platforms, and single sign-on across both estates. What it does not cover is the systems on the outside: third parties calling your applications, scheduled jobs owned elsewhere, and integration contracts you do not control.

Opportunity cost. The largest number and the one nobody puts in a spreadsheet. For the duration of the conversion, a portion of your development capacity is reproducing functionality that already works. Nothing new ships from that capacity. On a two-year phased programme, that is two years of roadmap not delivered, and it should appear in the business case as an explicit figure rather than as an assumption.

Post-conversion adjustment. Per OutSystems' documentation, work continues after conversion before applications can publish. Plans that end at cutover are incomplete.

The three realistic options

The third column is the one most organizations leave out of the analysis, usually because changing vendors feels like a larger decision than changing architecture. Worth noting that both require re-implementation. Neither is an upgrade. Once you accept that your team will rebuild the portfolio either way, the two options sit much closer together than they appear on a slide, and leaving one of them uncosted means choosing without knowing what the alternative would have been.

A decision framework

Work through these in order. The first two are disqualifying, so answer them before doing any estimation work.

1. Does a hybrid hosting model satisfy your regulator? ODC Self-Hosted runs your applications and data in your own infrastructure, but OutSystems retains the control plane, including build and deployment. If your obligation is data residency, that works. If it is air-gapped operation or full sovereignty over the toolchain, it does not, and the decision is between staying on O11 and moving to a platform that does.

2. Is any of your portfolio still Traditional Web? If yes, price the Reactive migration first as a separate project. It is a prerequisite, not part of the conversion.

3. How large and how coupled is the portfolio? As a rule of thumb rather than a benchmark: under roughly ten loosely coupled applications, conversion is a manageable project. Above fifty, or with heavy inter-module coupling, you are running a multi-year programme and the dual-run cost becomes the dominant number.

4. What specifically do you need from ODC? Name the capability. If the answer is elastic scale, regional data placement, or the AI tooling landing in ODC, that is a real business case. If the answer is that ODC is the future, that was a deadline argument, and the deadline no longer exists.

5. What does your license cost look like in three years at your current application growth rate? Not this year's figure. If that number is the actual problem, converting to ODC does not solve it, because the commercial model travels with you.

6. Do you have automated test coverage? If not, add substantial re-testing cost to any conversion estimate, and consider building coverage first regardless of which option you choose.

Run the Conversion Assessment Tool before committing to any number. It runs on your own infrastructure at no additional licence cost, and it supports mapping your O11 architecture onto an ODC target and defining conversion plans, not just listing findings. Whatever you decide afterwards, you will decide it with better information.

If you have already started

Many readers are mid-programme rather than pre-decision. Four things worth doing this quarter.

Re-baseline against the current support position. If your programme was justified by a 2029 deadline, that justification no longer holds. It does not follow that you should stop. It means the pace is yours to set, and a timeline built on urgency may no longer be the right shape.

Set a decommissioning date for each O11 component. Phased migrations rarely fail at the start. They stall once the visible applications have moved, and both environments end up running permanently: double the maintenance, none of the payoff. A date in the plan, tracked as a milestone, is what prevents that.

Sequence by dependency, not visibility. Applications that unblock others go first, regardless of how uninteresting they are to describe in a steering committee.

Recheck the dual-run budget against actual pace. If phase one took 40% longer than planned, your coexistence window has extended by the same proportion, and so has the cost. Update the number before someone else discovers it.

Where a different platform fits the comparison

If your reason for moving is architectural, ODC is a reasonable destination and the rest of this article is about doing it properly.

If your reason is commercial, the calculation is different. Licensing by application object means cost rises as applications grow, and converting to ODC does not change that model. Nor does it change what you hold at the end of the contract. What an export gives you is a codebase your team maintains by hand from that point on, which is a different asset from a running low-code portfolio. How much that matters is disputed between vendors and independent reviewers, so it is worth testing against your own team rather than taking either account.

Where those are the drivers, a re-implementation you are already funding is the natural moment to compare destinations rather than assume one. Betty Blocks is one such option, where licensing is not tied to application growth and generated code is exportable. Whether it fits depends on which of the six questions above is your real constraint, and other platforms will suit other answers.

The point is not the destination. It is that a re-implementation is the cheapest moment you will ever have to change your mind, and running the comparison costs you a week.

Frequently asked questions

Is OutSystems 11 being discontinued?

No. The earlier commitment was supported at least through March 2029, which was a floor that much of the market read as an expiry. OutSystems' current support terms publish no end date at all, committing instead to support both platforms for as long as there is continued and viable demand, with at least five years of notice if that changes.

Is there an automated tool to convert O11 apps to ODC?

Partially. The O11 to ODC Conversion Assessment Tool, generally available since November 2025, analyzes your portfolio and reports what needs fixing per application. OutSystems states it is working on conversion automation for some patterns, but preparation and post-conversion adjustment remain manual today.

How long does an O11 to ODC migration take?

It depends on portfolio size, coupling, and whether Traditional Web applications are involved. Small, loosely coupled portfolios are a project. Large or heavily coupled portfolios are a multi-year programme, and the dual-running period lasts as long as the programme does.

Can O11 and ODC run at the same time?

Yes, and OutSystems recommends it. Data Fabric lets ODC applications consume O11 entities as external entities without migrating the data, which makes phased transitions practical. You pay for both environments throughout.

Can I run ODC on-premises?

Partly, since March 2026. ODC Self-Hosted runs applications, data, and AI agents on your own private cloud or on-premises Kubernetes, but platform services including build and deployment remain with OutSystems. It meets data residency requirements. It does not make the platform air-gapped or fully sovereign.

What happens to my C# extensions in ODC?

They are replaced by external logic, built and deployed through ODC's External Libraries SDK rather than packaged with the application. Extensions that assumed in-process execution or low-latency local calls need rework.

Will converting to ODC reduce my license cost?

Not by itself. Converting changes the architecture, not the commercial model, so if your cost is currently driven by how much you have built, it will still be driven by that afterwards. Check your own contract terms for both platforms before assuming otherwise. If licensing trajectory is the primary concern, it deserves a separate evaluation from the architecture question.

Should we consider a different platform instead?

It is worth pricing as a third option, particularly if your drivers are commercial rather than architectural, or if you need a deployment model ODC does not offer. Once the portfolio is going to be rebuilt either way, comparing destinations costs little, and the decision is difficult to revisit later.