Most migrations start with a document, not a decision. A renewal quote arrives with a number nobody expected. A vendor announces that the architecture you standardized on five years ago is now the legacy path, and the new one requires manual rebuilding. Or a governance review turns up 60 applications where the inventory said 25.

None of those are unusual. Gartner projects that 35% of enterprises with major low-code investments will migrate platforms between 2026 and 2028. That is a wave, not an edge case, and it means the migration playbook is about to become a common piece of enterprise architecture knowledge rather than a specialist one.

The fear worth naming up front: most teams assume migration means rebuilding, because that is what their vendor's own migration path required. When the only migration you have witnessed was a screen-by-screen reconstruction mandated by the platform you already owned, it is reasonable to conclude that leaving would be worse. Common rebuild estimates land in the $50,000 to $250,000 range for a significant application, which is enough to end most conversations before they start.

The evidence points somewhere else. Kyndryl's 2025 research on mainframe application modernization found that organizations using incremental approaches saw an average return of 288%, not because incremental work is cheaper per unit, but because it delivers value continuously instead of holding everything hostage to a single cutover date.

This article follows that logic through four stages: assess, sequence, migrate incrementally, decommission. The last one is where most programs quietly fail.

Why enterprises are moving away from traditional Low-code platforms

Four forces drive most low-code migrations, and only one of them is dissatisfaction with the product itself.

1. Licensing models that penalize success

Many enterprise low-code platforms meter licensing by application object: every screen, database entity, API method, and custom event counts toward the bill. Read that structure carefully and the incentive problem becomes obvious. The more useful an application becomes, the more it costs to keep running.

OutSystems Developer Cloud illustrates the gap between list price and reality. Its published entry subscription is roughly $36,300 per year. Independent buyer data from Vendr puts average annual contract value between $215,000 and $220,000, with some agreements reaching $340,000.

The architectural consequence matters more than the invoice. Teams start designing to minimize object counts rather than to build good software, consolidating screens that should be separate, avoiding entities that would clarify the data model. Licensing becomes a design constraint, which is a strange thing for a development platform to impose.

2. Vendor-forced platform migrations

When a vendor deprecates the architecture you built on, the migration decision has already been made for you. The only remaining choice is destination.

The current example is the OutSystems 11 to Developer Cloud transition. The two architectures are incompatible; traditional web applications must be manually rebuilt as reactive web apps, screen by screen, with no automated conversion tool. Enterprises typically run both environments during the rebuild, paying full operating cost for each, sometimes for years on large portfolios.

Here is the calculation worth making in that position: if you are already funding a rebuild, the switching cost you were worried about is now sunk. The comparison is no longer migrate versus stay. It is rebuild here versus rebuild somewhere better.

3. Code ownership that doesn't survive the exit

Ask any low-code vendor about lock-in and the answer follows a pattern: the platform compiles to standard code, and that code can run without the vendor's runtime. It is technically accurate and practically incomplete.

Compiled output is a snapshot. OutSystems calls the process "detaching," and it produces standard .NET and React applications. Competing vendors report that detached code tends to be large and difficult to maintain, with most teams choosing to rebuild rather than port it. Detachment is generally a one-way step taken at contract end, sometimes behind additional fees.

You keep the artifact. You lose the process. From the moment of export, a low-code workflow becomes a hand-maintained codebase, written by a compiler for a compiler, inherited by developers who did not design it.

4. The specialist talent bottleneck

Complex work on enterprise low-code platforms requires platform-certified developers. That constraint has two costs: a narrower hiring pool, and a queue.

The queue is the more damaging of the two. When every non-trivial change request has to pass through three certified developers, delivery capacity becomes fixed regardless of budget. Business teams learn the lead time and start routing around it, which produces the next problem.

AI capability gaps in platforms designed pre-2023

Platforms architected around a visual canvas can accommodate an AI assistant. They cannot easily become AI-native, because the two designs place the source of truth in different places.

In a visual-first platform, the canvas is authoritative and AI suggests edits to it. In an AI-native platform, a specification is authoritative and the visual model, the code, and the prompt are all views onto it. Betty Blocks implements this as Prompt-to-Meta-to-Code: a prompt produces an App Blueprint held in a metadata layer, and both the visual model and the production code are rendered from that blueprint rather than maintained as separate artifacts. That is the core architectural difference between the two designs, and it determines whether generation is a convenience feature or the primary build path, and it is not something a product roadmap resolves in a release cycle.

Common migration challenges and risks

Migration projects fail for predictable reasons, and almost none of them are technical surprises in the new platform.

Undocumented business logic buried in the legacy platform

The discovery phase is where timeline overruns originate. Enterprises that skip detailed dependency mapping consistently see six-month projects expand into multi-year engagements once testing surfaces functions nobody knew existed.

The pattern repeats because undocumented logic is invisible to estimation. A visual model shows what someone drew; it does not show the custom code block added during a 2019 incident, the stored procedure that handles a tax edge case, or the validation rule that exists because a single large customer asked for it. These surface during testing, at the worst possible point in the schedule.

Data synchronization between parallel systems

While both platforms run, both hold state. Deciding which system is authoritative for which entity, and how changes propagate, is the hardest engineering problem in an incremental migration, and it is genuinely one of the two largest risks in this class of project.

Get specific early. Authoritative source per entity, propagation direction, conflict resolution rule, and reconciliation frequency. Vagueness here produces data incidents that undermine confidence in the whole program.

Stalling after the high-value components

The second major risk is organizational rather than technical. Teams migrate the visible, high-value 60% of the portfolio, the executive attention moves elsewhere, and the remainder never moves.

The result is the worst available outcome: both platforms running permanently, double the maintenance burden, and none of the payoff from decommissioning. It is worse than not starting, because you now pay two vendors instead of one.

Integration surface area

Every connector, webhook, scheduled job, and API consumer is a migration dependency. Most inventories capture applications and miss integrations entirely, which is how a 20-application migration turns out to involve 140 integration points.

Inventory these separately and treat each as a first-class work item with its own owner.

Dual licensing during coexistence

Budget for paying both vendors simultaneously across the full coexistence window. On a large portfolio migrated incrementally, that window can run 18 to 36 months.

This line item is routinely omitted from business cases, which is why migration programs so often report cost overruns while executing broadly to plan. The plan was wrong, not the execution.

Institutional knowledge walking out the door

The people who built the original applications are frequently gone. What remains is a visual model that shows structure without intent. You can see what the application does, not why it does it that way.

Where original developers are still available, involve them in discovery even if they have moved to other teams. It is the cheapest risk reduction available in the entire program.

Risk assessment: likelihood against business impact

Full rebuild vs. Incremental migration

A full rebuild is faster on paper and slower in practice. Incremental migration takes longer on the plan and finishes sooner in reality, because it never stops delivering value while it runs.

What a full rebuild actually costs

Big-bang rewrites share a consistent failure profile. They take years, which means requirements go stale before delivery. They require substantial upfront investment against unclear return. They disrupt operations at cutover. And they run into hidden dependencies that make the timeline fundamentally unpredictable rather than merely optimistic.

The subtler cost is opportunity. For the duration of a rebuild, your development capacity is committed to reproducing functionality you already have. Nothing new ships. On a two-year program, that is two years of competitors shipping while you catch up to yourself.

What incremental migration looks like

The established pattern is the Strangler Fig, named by Martin Fowler after the plant that grows around a host tree until it can stand alone. Both AWS and Microsoft publish canonical implementations in their prescriptive architecture guidance, which is useful when you need to justify the approach to a skeptical steering committee.

The mechanism is a facade, typically an API gateway, placed in front of both systems. It starts in pass-through mode, routing every request to the legacy platform. As each capability is rebuilt on the new platform, routing rules shift that traffic across. Consumers see one stable interface and remain unaware that a migration is running. When the last route moves, the legacy system can be switched off.

Two properties make this work at enterprise scale. Every increment ends with a working system, and every increment is reversible.

Branch by abstraction for in-place changes

Some migrations cannot be cleanly separated by a network boundary. Framework swaps, UI rewrites, and tightly coupled in-process logic need Fowler's companion pattern instead.

Branch by Abstraction inserts an abstraction layer in code, moves all callers behind it, builds the new implementation against the same abstraction, then switches callers over incrementally. Old and new coexist behind one interface, so the system stays releasable throughout, which is the property that matters when you cannot afford a freeze.

When a full rebuild is genuinely the right call

Three situations justify it, and pretending otherwise damages credibility with anyone who has run one.

Small portfolios, where the coordination overhead of incremental migration exceeds the risk it removes. Under roughly ten straightforward applications, the facade is more machinery than the problem warrants. Applications already scheduled for retirement, where migration is wasted motion. And cases where the legacy logic is itself the problem: if the application encodes a process the business has since abandoned, reproducing it faithfully is the wrong goal.

The ROI evidence

Kyndryl's 2025 research found that organizations modernizing applications incrementally saw an average return of 288%. The figure is drawn from mainframe modernization rather than low-code specifically, so treat it as directional rather than a benchmark for your program.

The mechanism generalises well, though. Incremental approaches return value from the first increment rather than the final cutover, which changes the shape of the investment curve regardless of what you are migrating from.

Why teams still choose big bang

Because it looks faster and cleaner on a project plan. A single cutover date is easier to present to a board than eighteen months of progressive routing changes. A Gantt chart with one milestone reads as decisiveness; one with thirty reads as uncertainty.

Recognizing this as a presentation bias rather than an engineering judgement is worth doing explicitly, ideally in the room where the decision gets made.

Step-by-step low-code migration process

Seven phases, executed in sequence, with a working system at the end of each one.

Phase 1: Discovery and dependency mapping

Allocate more time than feels reasonable. This is the phase where overruns originate, and the only reliable mitigation is doing it properly before anything else starts.

Deliverables: a complete application inventory with tiering, three separate dependency maps, a business logic catalogue by location, and a written list of known unknowns. That last artifact is the most useful one you will produce, because it converts hidden risk into tracked risk.

Phase 2: Select the pilot slice

Choose a capability that is coherent, isolatable, and carries real but contained business value. Candidates with clean functional boundaries (a supplier onboarding flow, an expense approval chain, a customer inquiry intake) work better than anything sitting in the middle of your dependency graph.

Resist two temptations: the most visible application, which puts executive attention on your least experienced increment, and the easiest application, which proves nothing transferable.

Phase 3: Stand up the facade

Deploy the routing layer before migrating anything. Run it in pass-through mode, sending 100% of traffic to the legacy platform, and leave it there until it is boring.

This sequencing matters more than it appears. Proving the boundary before moving behavior across it means that when something breaks later, you know it is the new application rather than the routing. Skipping this step conflates two failure sources at exactly the moment you can least afford ambiguity.

Phase 4: Generate and validate the first application

Build the replacement on the target platform from the extracted specification rather than by tracing the legacy implementation. The distinction is important. You are reproducing the requirement, not the workaround.

Validate with behavioral comparison rather than feature checklists. Feature flags in test environments allow both implementations to process the same inputs so outputs can be compared directly. Behavioral parity is the real acceptance criterion; a feature list confirms only that someone remembered to build things.

Phase 5: Cut over with a rollback plan

Every migrated service needs a documented rollback path and the ability to route traffic back quickly. AWS's guidance is explicit on this point, and it is worth treating as non-negotiable rather than as a nice-to-have.

Practice the rollback before you need it. An untested rollback plan is a hypothesis.

Phase 6: Iterate through the portfolio by tier

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

Where the two orderings conflict, and they will, the argument to make is that dependency-ordered sequencing produces a shorter total program. That is generally true, and it is a stronger case than architectural preference.

Phase 7: Decommission and prove it

The phase most programs never reach. Set the decommissioning date for each legacy component at project start, track it as a first-class milestone, and treat slippage as a governance escalation rather than a scheduling adjustment.

Proving decommissioning means confirming the legacy component is off, its license is terminated, and its data is either migrated or disposed of under policy. A component that is merely unused still costs money and still carries audit obligations.

Choosing the right migration strategy

The right strategy is determined by three inputs: portfolio size, application coupling, and how much runway you have before the contract or the vendor's deprecation forces the decision.

Strangler Fig

Best suited to business-critical systems that must remain operational throughout, have clearly identifiable functional domains, and require continuous enhancement during the migration window.

This is the default for most enterprise low-code portfolios, because those portfolios are typically composed of discrete business applications rather than one monolith. The domains are already separable; the facade simply formalises the separation.

Branch by Abstraction

Choose this where a network-level facade cannot cleanly separate old from new: shared in-process libraries, deeply coupled UI layers, or logic that spans what looked like separate applications until you mapped it.

In practice, larger migrations use both. The facade handles application-level separation; Branch by Abstraction handles the coupled internals that the facade cannot reach.

Parallel run for high-risk regulated workloads

Both systems process the same inputs, outputs are compared, and the legacy system remains authoritative until the new implementation has demonstrated equivalence over a defined period.

It is the most expensive option per unit of migration, and the only defensible one for workloads where an undetected calculation difference creates regulatory exposure. Financial calculation engines, benefits determination, clinical decision support, and regulatory reporting belong here.

Lift-and-regenerate

For straightforward applications (forms over data, simple CRUD, basic approval routing), the fastest path is regenerating from a specification rather than porting anything. There is no meaningful logic to preserve, so extraction is quick and reconstruction is faster still.

A meaningful share of most low-code portfolios falls into this category. Identifying it early is what makes an apparently overwhelming migration tractable, because it separates the applications that need careful treatment from the ones that need an afternoon.

Retire-in-place

The strategy with the best economics. Applications that duplicate others, serve dissolved teams, or support ended processes should be switched off rather than migrated.

Retirement requires evidence and a decision-maker, not just a recommendation. Usage data, a named business owner, and a documented sign-off. Otherwise the application will reappear in the portfolio at the next review, and it will have been migrated by then.

Selecting a strategy

Common migration mistakes to avoid

Five failure patterns account for most stalled migrations, and each has an early warning sign.

Sequencing by visibility instead of dependency

Migrating what the executive sponsor can see, rather than what unblocks the rest of the portfolio, extends the total program and puts maximum scrutiny on your least experienced increment.

Warning sign: the migration sequence matches the org chart more closely than the dependency map.

Treating discovery as a formality

The single highest-correlation predictor of overrun. Compressed discovery does not remove work; it relocates it to testing, where it costs more and is visible to more people.

Warning sign: discovery is scheduled in weeks and the phrase "we know our applications" appears in planning conversations.

No named decommissioning date

Without a date per component, coexistence becomes permanent by default. Nobody decides to run two platforms forever. It happens because nobody decided when to stop.

Warning sign: the project plan ends at "final application migrated."

Migrating without a rollback plan per service

A program-level rollback is not a rollback. Each increment needs its own reversal path, tested rather than documented.

Warning sign: rollback appears once in the risk register and nowhere in the runbooks.

Porting the legacy design instead of the legacy requirement

Reproducing 2016 workarounds in a 2026 platform preserves constraints that no longer exist: the extra approval step added because the old platform could not enforce a rule, the split screens that existed to reduce object count.

Warning sign: the specification was written by reading the legacy implementation rather than by talking to the business.

How to choose the right AI Application Generation Platform

Evaluate the destination platform against the specific failure modes that caused this migration. Four criteria, each with a demo-testable question.

That framing is deliberate. Generic platform evaluations produce generic results, and the failure modes that brought you here (licensing that scaled with success, code you could not take with you, governance that had to be configured application by application) are the ones most likely to recur if you do not test for them explicitly.

Does generation produce ownable code?

Ask to see an actual export, in a live environment, during evaluation. Then ask the harder question: could a developer unfamiliar with the platform pick this up and extend it?

The second question is the real measure. Code you can run is portability. Code you can develop is ownership, and the distinction is exactly where "no lock-in" claims tend to fall apart.

Betty Blocks is positioned as a platform for governed AI application generation rather than a low-code platform, and this is one of the places that distinction has a concrete test. Applications export as standard React and WebAssembly, output intended to be the normal deliverable rather than an exit mechanism invoked at contract end. For a team that has just been through a migration, that property has a specific value: it keeps the next platform decision open rather than deferred.

Is governance inherited or configured?

Ask what a business user has to do to get a generated application into a governed state. Count the steps.

Zero steps means governance is architectural. Any number above zero means governance is optional in practice, whatever the documentation says, because the applications that skip the checklist are precisely the ones you most need governed.

On the Betty Blocks platform, generated applications inherit DTAP environments, role-based access control, audit logging, and CI/CD integration by default. In a migration context, the practical benefit is narrow but real: migrated applications do not arrive carrying a governance backlog that has to be worked through after cutover.

Does pricing scale with usage or with success?

Model your projected portfolio at year three under the vendor's pricing structure, not today's portfolio and not the vendor's illustrative example. If cost rises with the number of screens, entities, or events, you have reproduced the dynamic that triggered this migration.

Are deployment options aligned to your compliance requirements?

Verify against your actual obligations rather than a general sense of preference. On-premises, EU cloud, and hybrid deployment options all matter concretely if data residency, sovereignty, or sector-specific hosting requirements are in scope. If they are not, this criterion carries little weight, and it is worth saying so rather than treating every capability as equally important.

What does the vendor's own migration path look like?

The most revealing question in the evaluation, and the one vendors are least prepared for. Ask what happened to customers the last time this vendor changed its own architecture. Was there an automated path, or did customers rebuild? Did the vendor fund it?

You are about to inherit that answer as your own future. A vendor whose last architecture transition required customers to manually rebuild has told you what its next one will require.

Migration support and tooling

Establish whether migration support means tooling or a services engagement, and price accordingly. Discovery tooling, specification extraction assistance, and behavioral comparison capability have real value. A professional services quote has a real cost.

Ask specifically what the vendor provides at no additional charge, what carries a fee, and what they expect your team to handle. The answers vary widely, and the gap between "we support migrations" and "here is what we provide" is where budget surprises live.

Conclusion

Three decisions determine whether a migration finishes: how you sequence, whether you set a decommissioning date, and whether the destination platform makes the next migration easier or harder.

Sequencing is the one teams get wrong most often, and it is the cheapest to fix. Dependency order beats visibility order on every metric that matters, including total duration, which is the argument to bring to a steering committee that wants the flagship application moved first.

The decommissioning date is the one that separates completed migrations from permanent coexistence. Set it per component, at project start, and escalate slippage as a governance issue rather than absorbing it as a schedule adjustment. A migration without a decommissioning date is a plan to run two platforms indefinitely, whether or not anyone intended that.

The third decision is the one with the longest tail. Every platform generation has ended with a migration, and this one will too. The technology cycle has not changed just because the tooling improved. What you can control is whether the next transition starts from a codebase you own and a specification you can read, or from another proprietary model and another vendor conversation about detachment fees.

That is the practical case for evaluating a destination platform on exit terms before you arrive. Not because you expect to leave, but because platforms that make leaving straightforward tend to be the ones that earn staying.

Frequently asked questions

Can you migrate from one low-code platform to another?

Yes, though rarely by porting. Most successful migrations extract business logic into a platform-neutral specification, then regenerate applications on the target platform. Vendor export or detach features typically produce code intended for hand maintenance rather than continued development, which is why regeneration is usually faster and cleaner than conversion.

How long does a low-code migration take?

Smaller initiatives complete within a few months. Large enterprise portfolios migrate incrementally over one to three years. Duration is driven more by dependency density and documentation quality than by application count. A tightly coupled portfolio of 20 applications takes longer than 60 loosely coupled ones.

Is rebuilding always necessary?

No. Incremental patterns such as Strangler Fig let you replace capabilities one at a time while both systems run behind a routing facade, keeping every increment reversible. Full rebuilds make sense for small portfolios, applications already slated for retirement, or cases where the legacy logic itself is the problem being solved.

What are the biggest migration risks?

Two dominate. Data synchronization between systems running in parallel is the hardest engineering problem. Stalling after the high-value components are migrated is the most common organizational failure. It leaves both platforms running permanently, doubling maintenance cost with none of the decommissioning benefit.

How can AI speed up application migration?

Mainly in two phases. AI-assisted analysis compresses discovery by surfacing hidden business logic and dependencies. AI generation compresses reconstruction by building replacements from specifications rather than assembling them by hand. It does not compress stakeholder alignment, parallel-run observation periods, or decommissioning discipline.

How do you preserve workflows and integrations during migration?

Place a facade or API gateway in front of both systems so downstream consumers see a stable interface throughout. Extract workflow state machines, including exception paths, escalations, and timers, into a platform-neutral specification before migrating, and treat every integration point as a first-class work item with a named owner.

What is the cost of migrating from a low-code platform?

Commonly cited rebuild figures fall between $50,000 and $250,000 per significant application, but the more useful number is three-year total cost of ownership for migrating versus staying. Include projected license growth, any vendor-mandated rebuild you would fund anyway, and the full dual-licensing period during coexistence.

How do you choose the right AI application generation platform?

Evaluate against the failure modes that caused your migration: whether generated code is genuinely ownable and extensible, whether governance is inherited or configured per application, whether pricing scales with usage or with success, and whether deployment options meet your actual compliance obligations. Then ask what the vendor's own last architecture transition required of its customers.

What happens to our data during a low-code migration?

Data typically migrates ahead of the applications that consume it. Assess schema portability early, and confirm you can extract at the required granularity. Some managed-database platforms restrict the direct SQL access migration tooling needs. Plan reconciliation as a repeatable job covering record counts, checksums, and business-rule validation.

Should we migrate all applications at once?

Almost never. Sequence by dependency order, beginning with a contained pilot that proves the pattern without concentrating executive attention on your least experienced increment. Expect 15 to 30% of an aged portfolio to be retired rather than migrated, which is the cheapest form of migration available.