O11 to ODC: The Strategy of Migration or Powerful Coexistence

For a decade, the architectural mandate for CIOs was clear: Migrate to the Cloud. But today, that mandate has evolved into a strategic crisis. Simply “being in the cloud” is no longer enough when your competitors are leveraging native cloud agility, autonomous scaling, and containerization.

As a leader running a massive OutSystems 11 (O11) footprint, you are facing a defining moment. O11 has served you well, offering rapid application delivery, but its architectural foundations remain monolithic and VM-centric. OutSystems Developer Cloud (ODC) is the future a complete architectural pivot to containerization and true microservices.

A “big bang” migration of your entire O11 portfolio to ODC is a strategic risk that will cripple your business operations, blow past your budget, and introduce catastrophic service failures.

The only viable pathway forward is Bi-Modal IT: a deliberate, strategic coexistence of O11 and ODC. This article will break down why this hybrid strategy is mandatory, the infrastructure reality driving this shift, the profound differences between O11 and ODC architecture, and precisely how to segment your BFSI and Manufacturing applications into the correct bucket.

1. Bi-Modal IT: The Strategy of Necessary Coexistence

Gartner popularized the concept of Bi-Modal IT, but today, for existing O11 customers, it is not just a theory; it is an operational survival tactic. Bi-Modal IT splits your technology portfolio into two distinct, integrated modes:

● Mode 1: The Stable Monolith (Reliability): This is your existing O11 environment. It focuses on the predictability of the Core System of Record. In BFSI, this is your general ledger; in Manufacturing, this is your on-premise inventory tracking system. It prioritizes stability over agility.

● Mode 2: The Containerized Agile Edge (Speed): This is ODC. It is designed for iterative, high-frequency releases, massive horizontal scaling, and Domain-Driven Design. It focuses on Systems of Engagement. This is your customer mobile portal or your real-time IoT manufacturing dashboard.

The Bi-Modal Coexistence Strategy (Mode 1 and Mode 2)

2. Infrastructure: The Driver Behind the Pivot (VMs vs. Containers)

As a CXO, you must understand the financial and technical drivers of this migration. Why is OutSystems transitioning to this microservices Architecture?

As the Digital Factory grows the landscape turns into a Large Monolith with a Portfolio of interconnected apps core systems and services connected to a single large database that can be manually virtually scaled. While development becomes fast its deployment and management gains inertia. With a Monolithic DB while transactions between tables and joins are fast a sudden spike in demand for an app can deteriorate the performance on other apps in the environment due to lack of isolation. This forces Organizations to Size for peak demand

Therefore, where applicable moving to microservices architecture for high isolation, dynamic scaling and better utilization.

Scaling Apps in Large Factories

Refer : Outsystems Domain Driven Design

Infra comparison between O11 and ODC

3. O11 vs. ODC Architecture: Understanding the Profound Divide

The most critical architectural difference is not the user interface or the low-code logic it is how data is handled and shared and therefore how the application boundaries are defined.

O11 (Modular):

An “Application” is just a folder for multiple modules. You can have dozens of modules (Core, Service, UI) in one app, leading to complex “circular dependency” nightmares if not architected properly.

In O11, a shared, monolithic database catalog allows “strong dependencies” (literal SQL Foreign Keys) between modules. Unified Data base and code reusability means that there is a very low latency between Code executions and data mashups.

But this also means entities are strong dependencies and therefore the source of “Leaky Abstractions” that make Large O11 factories slow to deploy.

Pros:

✅In-process communication

✅ All transactions in a single process

Cons:

❌ Everything deployed together

❌ Each runtime is published with all referenced elements

ODC (App-Centric):

The App is the unit of deployment. One App = One Container.

Apps: Contain your entities and UI. In ODC, Server Actions in Apps cannot be Public. If you want to share logic between Apps, you must use Service Actions (which are REST-based underneath). This ensures that if one app goes down or is being updated, it does not crash the whole environment.

This forces a “Service-Oriented Architecture” (SOA) where data is accessed via Service Actions or APIs, not direct entity references. database-per-service model In ODC, applications operate in isolation.

ODC strictly enforces a distributed, database-per-service model. Sharing data between Apps in ODC happens through APIs, not direct SQL database joins.

This also means that there are multiple hops for data between applications adding to latency.

Libraries: Purely for UI patterns and logic. Libraries cannot have entities (Except enumerations Static Entities) .

Pros:

✅ Independent deployments

✅ Build and publish different application elements independently

Cons:

❌ Inter-process communication that requires extra marshalling and networking

❌ Multiple processes require multiple transactions

Refer Link for more details on domain driven architecture.

The Architectural Divide (O11 Monolith vs. ODC Microservices)

Infra comparison between O11 and ODC

4. The Strategy Matrix: Where BFSI & Manufacturing Apps Must Reside

This is the decision-making framework your organization must adopt. You should not migrate based on the application name; you must migrate based on the application’s requirement for change, scale, and latency.

Application Placement Grid

Industry Use Cases: BFSI (Banking, Financial Services, Insurance)

In BFSI, data integrity and stability are non-negotiable. You cannot afford to have your core lending ledger eventually consistent.

Where BFSI Applications Should Reside:

1. Application : Core Banking Ledger

Platform : O11 (On-Prem / VM)

Why? : Data Gravity and Transactional Integrity. You cannot have your main financial ledger running on-cloud microservices that use “eventual consistency.” It must have monolithic ACID (Atomicity, Consistency, Isolation, Durability) guarantees.

2. Application : Loan Origination System (Sales App- Mobile)

Platform : Migrate ODC (Container)

Why? : Targeted Scaling and Agility. This app experiences massive traffic spikes during marketing campaigns. You want to scale the front end horizontally without affecting the stable backend processing systems.

3. Application : Loan Application Processing (Underwriting and Disbursment)

Platform : O11

Why? : Complex Cross-Entity Data Joins. This dashboard requires joining data across customer profiles, transaction history, and risk scoring. These are deeply coupled data models, perfectly suited for O11’s monolithic database catalog.

4. Application : Enterprise Help Desk

Platform : ODC

Why? : This app must have high availability and must be isolated from other applications and impact.

Industry Use Cases: Manufacturing

Manufacturing environments add the critical complexity of “OT” (Operational Technology) and physical edge hardware.

1. Application : Shop Floor OT

Platform : O11 (Local Edge / VM)

*Why? : Critical Low-Latency / Offline Capability.** PLCs, robotics, and ASRS (Automated Storage and Retrieval Systems) cannot tolerate Internet latency to a cloud container. If the cloud connection drops, your factory floor must continue to operate.

*ODC on-prem is not GA at the time of writing this article

2. Application : Supply Chain orchestration and Dashboard

Platform : ODC (Container)

Why? : Cloud Native / High Availability. This dashboard aggregates data from multiple factories globally, Agents co-ordinate shipments, RFQ, Giving you near real-time birds eye view of your supply chain.

3. Application : Customer Portal and Support

Platform : ODC (Container)

Why? : Cloud Native / High Availability. High On Demand scaling. Ability to leverage Agentic AI workflows. Bring your own AI model ensure control over cost and compliance.

Conclusion: The Path Forward (Bi-Modal Operations)

The O11-to-ODC migration is not a project; it is a profound architectural reorganization that will define your technology strategy for the next decade. Do not let the marketing hype rush your organization into a failed “big bang” cloud migration.

Embrace Bi-Modal IT. Map your applications against the placement matrix. Keep your mission-critical, high-data-gravity systems stable on O11. Strategically migrate your high-volatility, high-scaling systems of engagement to ODC, building the necessary integration bridges between them (using Change Data Capture or API Gateways).

The goal is to modernize your ecosystem, not to blindly migrate every application. Start slow, but start now. if you want to know how to start your migration or O11 and ODC interoperability here are some great articles to get started on the same.

**1. Before you plan an O11 to ODC conversion, run this tool first**

**2. Bridge the Gap: Enabling OutSystems 11 Users to Access OutSystems Developer Cloud Applications**