The business case usually arrives as a single number. Someone has pulled the annual platform cost, put it next to an estimate for a rebuild, and the rebuild looks cheaper. Sometimes it is. More often the two numbers are not comparable, because one of them is an invoice and the other one is a guess, and only one side of the ledger has anything on it at all.
We should say plainly where we stand. Hezico makes money taking OutSystems estates that already work and making them faster and cheaper to change, so we have an obvious interest in the answer. Read the rest with that in mind. We would rather make the argument and let you discount it than pretend we are neutral.
The estates we are describing are a particular size. Roughly a dozen developer seats. Ten thousand-plus users. Forty-odd modules, of which maybe a third are doing real work and the rest are screens over tables. Ten or more years of accumulated decisions. Integrations into finance, into identity, into two or three systems that predate the estate and will outlive it. Nothing about what follows applies to a six-module estate built two years ago by a team that is still in the building. That one you can move, and you probably should if you want to.
What AI changed, and what it didn’t
The reason this conversation is live again is that code generation got good. That is not hype, it is just true. The marginal cost of producing a screen, a service, a set of CRUD endpoints has fallen a long way in eighteen months, and anyone telling you otherwise hasn’t tried recently.
But the thing that made a migration expensive was never the typing.
A mature estate is not a pile of code. It is a data model that encodes fifteen years of decisions about what a customer is in your business, several of which are wrong and load-bearing. It is a deployment topology with environments, promotion paths, and a release process that half the organisation has built habits around. It is an integration layer where the quiet connections nobody has touched in four years are the ones that will bite you. And it is a set of conventions, some deliberate and some accidental, that the current team navigates without thinking about.
Code generation can rewrite the code. It cannot carry the framework. It can’t tell you which of the forty modules is genuinely complex and which is a form over a table, because from the outside they look similar. It can’t tell you why the entity sits where it sits. It has no access to the constraint that was never written down, and in an estate this age, most of the strange decisions are reasonable answers to constraints that were never written down.
So what you get from AI is a faster rebuild of the part that was already the cheap part, and no help at all with the part that was always the expensive part. That changes the arithmetic less than the business case assumes.
What leaving actually costs
Set aside the licence for a moment and look at what a migration off an estate of this size actually involves.
It is a one-to-two-year project. Not because anyone is slow, but because you cannot turn off a system serving ten thousand users on a date, which means you dual-run. Dual-running is not a transition month at the end. It is a sustained period where both platforms are live, both need support, both need changes applied to them, and both are in the budget. The overlap is not a quarter.
During that period, the estate does not stop needing work. Regulatory changes still land. The business still wants things. So the team is running the old platform, building the new one, and keeping the two in sync, which is a third task, and the one that quietly eats the schedule.
Your in-house team is learning a new stack while doing this. Not learning it in the abstract: learning it under delivery pressure, on the system the business depends on, and making the mistakes that everyone makes in the first year on a new framework. Those mistakes become the next estate’s undocumented decisions. This is how the thing you are migrating away from got that way in the first place.
And the whole project delivers no new business capability. At the end of a two-year programme, the best possible outcome is that the business has exactly what it had, on a different platform, with a team less experienced in the platform than they were in the last one. That is a genuine outcome and sometimes worth buying. But it should be bought with open eyes, and it should be compared against what the same two years and the same people could have produced pointed at something else.
None of that appears on the ledger, because none of it arrives as an invoice. The licence does. That asymmetry, one side priced and the other side real but uninvoiced, is what drives most of the decisions we see, and it is the actual problem. Not migration. The missing column.
The third side: ODC
If you are on O11, there is a version of this conversation that isn’t “stay or leave,” and it deserves to be on the table because it is often the one that actually happens.
Moving from O11 to ODC is a migration. Not as large as leaving the platform, but a real one, and it carries its own version of everything above. Extensions and anything with C# in them are the part that doesn’t travel, and in practice that is what sets the timeline. The architecture is different enough that a straight lift isn’t available on a mature estate. We have written the decision framework for O11 versus ODC separately, and the read we do before quoting an estate covers how to size the extension problem before anyone commits to a date.
We raise it for two reasons. First, because people conflate the two decisions, and a business case for “getting off OutSystems” is sometimes really a business case for “getting off O11” wearing a disguise, which is a much smaller and better understood problem. Second, because if you are going to spend the effort of a migration anyway, it is worth being honest that ODC keeps your domain knowledge and your people, and a rebuild on a new stack doesn’t. That is not an argument that ODC is free. It is an argument that the choice isn’t binary and shouldn’t be priced as if it were.
The variable nobody prices
Here is what we think actually gets missed, and it is the reason we would push back hardest on a migration in 2026 specifically.
Everyone has an AI roadmap now. Some of it is theatre and some of it is real, but the real parts share a shape: they need a clean-ish data model, working integrations, and people who understand the domain well enough to know what a good answer looks like. Not a model. Not a vendor. Those three things.
A mature OutSystems estate has all three, and this is the part the platform doesn’t get credit for. The data model is already there and already reconciled against the business. The integrations already exist and already work. There is a service layer you can expose. The estate is a perfectly reasonable substrate for the AI work you want to do. You are far closer to being able to build something useful on top of an estate that already knows what a customer is than you are with a greenfield stack and a clean repository.
Now put a migration through the middle of that. The roadmap doesn’t slow down; it stops. Not because of the platform, but because your AI roadmap runs through the same estate, the same data model, and the same three people who know why it was built that way. Those three people are the only ones who can specify the replacement, which means they are on the migration. For one to two years. They are the constraint on both projects, and only one of the two can have them.
That is the trade being made, and we have never once seen it written down. The business case compares platform cost against rebuild cost. It doesn’t compare the rebuild against what those same people would have built instead.
The cost of staying, which is also real
We don’t want to write the version of this that is just a defence of inertia, because standing still has a price too and we have watched people pay it.
An estate that nobody can change cheaply is a tax on every decision that comes after it. It shows up as change requests that get quoted in weeks and delivered in months. It shows up as a release process people plan holidays around. It shows up as a business that stops asking, because it has learned the answer is slow, and that one is the most expensive, because it never appears anywhere. Nobody logs the feature they didn’t request.
It shows up as key-person concentration, which in an estate this size is usually two or three people, and it is a genuine risk with a genuine probability attached. And it shows up in hiring, because experienced people on any platform are scarce and the scarcity itself pushes some organisations toward a rebuild for reasons that have nothing to do with architecture.
So “stay” is not the safe answer. It is just a different bill, paid in smaller instalments, which is exactly why it doesn’t get compared properly against the large one-off. Both sides of this ledger have costs that don’t arrive as invoices. That is the honest version.
Making it cheaper to change
The case for staying is only worth making if staying comes with work attached. “Leave it alone” isn’t a strategy. What we would actually do, roughly in the order we would do it:
Delete things. In a forty-module estate there is usually a meaningful number of modules that are dead, near-dead, or serving a handful of users who could be served another way. Every one of them is carrying maintenance, regression surface, and dependency weight. This is the cheapest work available and it is almost never done, because deleting things has no sponsor.
Break the dependency knots. The thing that makes change expensive is usually not the change, it is the blast radius. When a small edit forces a wide regression test, you are not paying for the edit. Finding the two or three places where the dependency graph is knotted and untangling them does more for change cost than any other single intervention we know.
Get logic out of the UI layer. Logic that lives behind a screen instead of behind a service is logic you can’t reuse, can’t test cleanly, and can’t expose to anything else, including whatever AI thing you want to build next year. This one pays twice.
Write down why, not what. The code already says what was decided. It has never once said why, and the why is what walks out of the building. Most of what looks wrong in a mature estate is a sensible answer to a constraint nobody recorded, and half the cost of change is rediscovering constraints. This is unglamorous and it is the single highest-leverage documentation anyone can do.
Right-size the seats. Worth a look on its own terms, and it addresses the line that started the conversation.
A few things we have seen sound good and not deliver. Blanket “tech debt” programmes with no specific target tend to produce activity and no measurable change in delivery speed. Standards documents that nobody enforces are worse than no standards, because they create the belief that the problem is handled. And adding developers to a slow estate reliably makes it slower. Small teams outperform large ones here, and adding juniors to an estate this mature usually costs more supervision than it returns.
The test for all of it is one number: how long does a representative change take, from asked to live, this quarter versus last. If that isn’t moving, the work isn’t working.
When leaving is the right call
Sometimes it is, and the reasons are less about the estate than people expect.
The clearest architectural cases: a real strategic shift has happened underneath the estate and it is now solving a problem the business no longer has; a regulatory or data-residency constraint you can’t engineer around; or the estate is genuinely smaller and simpler than the module count suggests, which does happen and is worth checking before you assume otherwise.
But the honest answer is that the right call depends more on who is in the seat than on the architecture.
If the people who knew why it was built that way have gone, and in estates of this age that is common, because the sponsors who commissioned the build move on and the knowledge goes with them, then a lot of what we have argued above weakens considerably. Our whole case for staying rests on institutional knowledge being an asset worth preserving. If it is already gone, you are not preserving it, you are archaeologising it, and rebuilding from a clean specification may genuinely be cheaper than reverse-engineering intent from someone else’s ten-year-old logic. This is the condition a real platform handover is supposed to prevent, and the cost of skipping it lands here.
If the leadership carrying this doesn’t believe in the platform, that matters too, and not as a soft factor. A migration a team believes in will outperform a stay they have been told to accept. We have watched motivated teams deliver hard migrations well and we have watched resentful teams fail to improve estates that were entirely improvable. Conviction is a real input and pretending otherwise is how consultants produce recommendations that are correct and useless.
And if you can’t hire or retain for the platform in your market at a price you can pay, that is a structural constraint, not a preference. No architectural argument survives not being able to staff the thing.
So: for some organisations it is the right call and for some it isn’t, and the deciding variable is usually sitting in the room rather than in the codebase. What we would argue against isn’t the decision. It is making it on the licence line alone.
If you’re going anyway
Assume you have read all that and you are still going. Some of these are things we would want on the plan.
Price the whole ledger before you commit. Not to talk yourself out of it, but so the number you commit to is the real one. Dual-run cost for the full overlap. Team productivity through the learning curve. The roadmap that isn’t happening. If the case still holds with those on it, it is a strong case and you should back it hard.
Sequence by data model, not by screen. Screens are visible and tempting and they are the part AI can now do quickly. The model is the part that determines whether the migration succeeds, and getting it wrong early is the failure mode that shows up eighteen months in.
Don’t migrate what you should delete. Run the deletion pass first. Every dead module you port is paid for twice.
Do the archaeology while the people are still there. If two or three people know why, get it out of their heads onto paper before the project starts, not during. This is the single highest-value week in the whole programme and it is always the one that gets cut.
Keep those people out of the day-to-day build. They are the specification and they are irreplaceable; use them as the source of truth rather than the delivery capacity. It is tempting to put your best people on the new stack. They are more valuable explaining the old one.
Budget the dual-run properly and expose it as a line. It is the item that gets underestimated most and it is the item that turns a well-run migration into an overrun.
Be clear-eyed about what AI is doing for you. It will accelerate the build. It won’t carry the framework across, and a plan that assumes otherwise will discover this at roughly the halfway point.
The argument we are actually making isn’t “don’t migrate.” It is that the decision usually gets made on the one number that happens to arrive as an invoice, against a rebuild estimate that assumes the expensive part was the code. Put the cost of leaving on the other side of the ledger, put the cost of standing still next to it, and add the thing nobody prices: that your AI roadmap and your migration want the same data model and the same three people, and only one of them can have them.
Then make the call. Plenty of organisations will still go, and some of them will be right.
If you are building that business case now and the other side of the ledger is empty, send us the shape of your estate and what the number currently says. You will get a written answer, not a sales call. Check your fit or email us at hello@hezico.com.