What still earns ODC.

1What the deadline was doing

Three things, all of which have to be replaced by an actual argument.

• It supplied the business case. Nobody had to prove an application would be better on ODC, only that it would eventually have to be there. That premise is gone, and every remaining reason to move has to survive being asked out loud.
• It made the estate the unit of decision. A deadline applies to everything at once, so the plan was portfolio-wide by default. Without one, the unit is the application, and the answers stop being uniform.
• It stood in for the AI argument. The most common internal case for migrating was that the newer capabilities only exist on the other side. That is now partly false. An ODC application can be grounded in O11 business data through Data Fabric, which means the AI roadmap and the migration are no longer the same project. If your board paper argues for migration on AI grounds, it is out of date.

2What earns a move

Four things, judged per application rather than per estate.

• Load shape. Unpredictable or spiky demand is what the cloud native runtime is actually for. An application with a flat, well understood load profile is not being held back by where it runs, whatever else is wrong with it.
• Release cadence being held hostage. An application that needs to ship on its own schedule but sits inside a shared solution with six others has a real, recurring cost that ODC's independent lifecycle addresses directly. This is the most common genuine reason we see, and it is an organisational symptom before it is a technical one.
• A named ODC capability the application actually needs. Named, not gestured at. If the answer to "which capability" is "cloud native", there is no case yet. If it is a specific piece of the newer pipeline or workbench that a team is already blocked on, there is.
• New build, not old build. The cheapest ODC application is the one that was never written in O11. Where the portfolio decision is genuinely easy is at the front, on the things not built yet, and that decision is worth making before anyone touches what already exists.

3What is not a reason

• Age. A ten year old application that runs, is understood and changes twice a year is not a problem. It is an asset with a low maintenance cost.
• Consistency. Wanting one platform rather than two is a real preference, but it is a preference, and section 5 is what it costs to satisfy.
• A low score from a readiness scan. Cheap to convert is not the same as worth converting. A tool that says an application will move easily has told you the price, not the value, and the two get confused constantly because only one of them is a number.
• Somebody else's roadmap. Your platform vendor's product direction and your application portfolio's needs overlap, they are not the same thing.

4What still does not travel, and why that reads differently now

The list has not changed. C# extensions become external logic rather than porting. Traditional Web screens need converting. BPT has no direct equivalent, so anything modelled as a long running process gets rethought. The roles model differs. Forge dependencies may have no counterpart on the other side. On premise data needs a private gateway, and the network conversation usually takes longer than the technical one.

What has changed is what those facts mean. Under a deadline they were tasks, so the only question was how long each took. Without one they are prices, and a price can be declined. An application whose entire value sits in three C# extensions and a BPT process is not a hard migration. It is an application that has told you it should stay.

5Hybrid is the destination, not the transition

This is the part that goes unsaid, and it is the one that decides whether the plan survives contact with the second year.

If only some applications move, the estate is permanently two platforms. Not two platforms during a migration window, two platforms as the steady state. That has running costs that nobody puts in the migration business case, because a migration business case assumes an end date.

• Two of everything operational. Two runtimes, two deployment pipelines, two sets of architecture conventions, two places to look when something breaks at three in the morning.
• The seam becomes a dependency. Data Fabric is a real answer and it is not a free one. Whatever stays in O11 becomes the system of record for whatever moved, which means the thing you decided not to invest in is now load bearing for the thing you did.
• People. OutSystems teams work best kept small and senior, and a small senior team now has to hold two architectures well rather than one. That is a real constraint on how far the split can go before quality drops on both sides.
• The rule for new work. Which platform does the next application start on. If that is not written down and owned, it gets answered per project by whoever is closest to the keyboard, and in three years the split will be an accident rather than a decision.

A deliberate, small split is usually worth it. A split that happened because a migration stalled halfway is the expensive version, and it looks identical on an architecture diagram.

6The order we would run it

• Run the conversion assessment first, and treat the output as pricing. It installs onto the O11 infrastructure and classifies incompatible patterns across the whole portfolio, cheaply, which is exactly the input you want and exactly not the decision.
• Score the portfolio on value separately, before you look at that output. Load shape, cadence pressure, named capability need. Do it first, or the easy-to-move applications will quietly become the ones that move.
• Cross the two lists. High value and low cost moves first, obviously. The interesting quadrant is high value and high cost, because that is where the argument actually is, and it is the only one worth a conversation with the business.
• Probe before you commit to a number. One bounded application, low blast radius, taken end to end. Paper estimates for this come in low with enough consistency that we treat a real multiplier as the deliverable of the first phase.
• Write the rule for new applications before you move any old ones. It is the cheapest decision on the list and it stops the split growing on its own.