Guides / Moving off a platform

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 to us about a migration

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

✓No licence per end user, table or connector. You pay for the apps you run and the machine size and traffic you choose, and a bundle stops when it runs out rather than running up an invoice

✕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.

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.

How the first one goes

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

Inventory what is actually used

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

Rebuild one, in code

Start with a single application your team knows well. Build it in a chat with Claude, with the coding agent your team already uses, or by hand, in a repository you own.

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. Clone it, move it, self-host it, or hand it to the client, at any time while the application exists. If you delete the application, you can restore it for 30 days, and we email your admins before the repository is permanently purged. 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.