Migration

Your low-code platform is being retired.
The applications still have to run.

When a platform announces end-of-life, the work does not disappear with it. This is what moving those applications onto infrastructure you control actually looks like, including the parts we do not do for you.

Talk through a migration Read the security page

What we do not do

There is no converter. We do not import a low-code application and turn it into running code: nobody can do that well, and a vendor who says otherwise is selling you a rewrite with extra steps.

What we give you is somewhere for the rebuilt application to live from day one: a real environment per project, a repository you own, and a usage-based cost model rather than a metered token bill.

Migrating off SAP Build Apps specifically?

SAP Build Apps retired on 23 March 2026 and is no longer maintained. We wrote a page for exactly that situation: what SAP's own migration tool does, what it leaves undone, and where the applications it produces actually run. Read the SAP Build Apps guide.

You don't have to be losing your platform to want out.

Most teams aren't being forced off. They are just paying for limits they've stopped accepting.

On a low-code platform
Here

Your application exists in a proprietary format only that vendor can run

Ordinary code in a repository you own

The bill grows as you succeed: more users, more apps, more tables, more premium connectors

You pay for people and machines. Nothing increases because your application got popular

Need something the platform can't express? Wait for the vendor's roadmap

Your agent writes it this week

Version control is bolted on. You cannot meaningfully branch, diff or review a visual model

It is git. Branch it, review it, revert it

Debugging means the platform's own tooling, showing you only what it chooses to

Real logs from real running services, and a database you can query

Only certified specialists can maintain it

Any developer can read it

None of this requires a migration project. Build the next thing here, keep the old platform running, and decide later what moves.

How the first one goes

The first application is the one that teaches the team the pattern. The rest go faster.

01

Inventory what is actually used

Most retiring platforms carry applications nobody opens. Decide what gets rebuilt, what gets archived, and what quietly stops.

02

Rebuild one, in code

Start with a single application your team knows well. Build it with the coding agent your team already uses (we support Claude Code, Codex, and Copilot CLI today) or by hand, in a repository you own.

03

Run it side by side

Deploy to a dev environment, then staging, then production when the people who need it are ready. The old platform keeps running until you switch over.

What teams ask first

What happens to the code if we leave you too?

The repository is always yours. Delete the application and the git repo is untouched: clone it, move it, self-host it, or hand it to the client. That is the whole point of the exercise.

Can someone else hold the repository instead of us?

Yes. Ownership is organisation-scoped, so the work can run in the client's or the business's own organisation with your people as members, or in yours, and be handed over later.

What does it cost per application?

A development environment is free. Beyond that you pay for the machine tier each environment runs, plus backups and outbound traffic. We're in early beta and are not publishing per-tier rates yet. Pricing will be usage-based, never metered per credit or per token.

Where does it run?

In the EU: eu-central-1 (Frankfurt), on a dedicated instance per environment. That is the only region we run today: good for data residency if your data must stay in the EU, and worth raising early if it must sit somewhere else.