Let us be honest up front: there is no “convert” button between low-code platforms. You cannot export an OutSystems module or a Power Apps canvas app and import it into Mendix. The visual models, the data layers, the expression languages, and the runtime behaviours are all different. Moving to Mendix from either platform is a deliberate rebuild, not a code translation – and any tool or vendor that promises a one-click migration is selling you a disappointment.
That is not a reason to avoid the move. It is a reason to do it with a plan. This playbook is a phase-by-phase approach to re-platforming onto Mendix without losing control of scope, cost, or your production systems. Work through it in order; each phase ends with a checkpoint you should be able to tick before moving on. If you own one app, this is your project plan. If you own a portfolio, run it once as a pilot, capture what you learn, then template it for the rest.
Phase 1 – Decide whether to switch at all
The first phase is the one teams skip, and it is the most important. Before you move anything, be clear about why – because a rebuild has a real cost, and “we are frustrated” is not a strategy. Both OutSystems and Power Platform are capable, well-established platforms; the question is not whether they are good, but whether Mendix is the better long-term fit for your situation. Common, legitimate reasons teams move to Mendix:
- Lock-in and portability. Power Platform is deeply tied to the Microsoft cloud, Microsoft 365, and Dataverse. If you need to run on private cloud, government cloud, or on-premises – or simply want to avoid a single-vendor dependency – Mendix deploys across all of those.
- Cost trajectory. Per-app or per-user licensing that made sense for one departmental tool can scale awkwardly as your portfolio and user base grow. If your cost curve is heading the wrong way, model it honestly against Mendix before deciding.
- Governance and sprawl. “Anyone can build an app” is a strength until it is a mess. Teams that have accumulated ungoverned citizen-developed apps often move to Mendix for stronger versioning, lifecycle management, and central oversight.
- Scale and complexity. If an app has outgrown what it was originally built for – more users, deeper integrations, mission-critical status – a platform built for complex enterprise systems and native mobile from one model may fit better than one built for lightweight tools.
- The Siemens ecosystem. If you work with industrial systems, manufacturing, or Teamcenter PLM, Mendix’s Siemens pedigree is a genuine, specific advantage.
Be balanced. If your apps are simple, live happily inside Microsoft 365, and cost you little, switching may not be worth it – and we will tell you so. The goal is a decision you can defend, not a migration for its own sake.
Checkpoint: you have a written, honest rationale for switching – specific to your apps, costs, and constraints – and a sponsor who agrees the rebuild is worth it.
Phase 2 – Inventory and prioritize the portfolio
You cannot re-platform what you have not counted. Before touching Mendix, build a clear inventory of every app on the source platform and decide, for each one, what happens to it. Not everything should move:
- Rebuild – apps that are actively used, valuable, and a good fit for Mendix. These are your migration candidates.
- Retire – apps that are barely used, duplicated, or solved a problem that no longer exists. A migration is the perfect moment to switch these off rather than carry dead weight forward.
- Leave – apps that genuinely belong where they are. A lightweight Power Automate flow tied to SharePoint may be exactly right on Power Platform; there is no prize for moving it.
For each rebuild candidate, capture what actually matters: who uses it, what business process it supports, its integrations and data sources, its true complexity, and how much it would hurt if it broke. Then prioritize. Sequence the portfolio so the first app you rebuild is one that teaches you the platform without betting the business on it – meaningful enough to prove value, contained enough to survive mistakes.
Checkpoint: every app is tagged rebuild / retire / leave, and the rebuild list is prioritized with a clear first candidate and a rationale for the order.
Phase 3 – Re-architect, do not transliterate
This is where most re-platforming projects go wrong. The temptation is to open the old app on one screen and copy it into Mendix screen-for-screen, field-for-field, expression-for-expression. Resist it. Transliterating an OutSystems or Power Platform design into Mendix carries forward every workaround and every quirk of the old platform, and produces an app that fights the way Mendix wants to work.
Instead, treat the rebuild as a chance to design the app properly for Mendix:
- Rethink the data model. Map what the app truly needs, not how the old platform happened to store it. A Dataverse-shaped or OutSystems-entity-shaped model rarely translates cleanly into a well-formed Mendix domain model – design it fresh from the business requirements.
- Rethink the logic. OutSystems logic lives in its own visual flows and expressions; Power Platform logic is spread across Power Fx, flows, and connectors. In Mendix it belongs in microflows, nanoflows, and rules. Re-express the intent of the logic in Mendix’s model rather than porting its mechanics.
- Rethink integrations. Connectors and integration patterns do not carry over. Re-evaluate each integration – REST, OData, message queues, the Mendix Marketplace connectors – and choose the right Mendix approach for each, rather than recreating the old plumbing.
- Preserve behaviour, not implementation. The contract with your users is what the app does. Document the required behaviour of each screen and process, and rebuild to that specification – so you are matching outcomes, not old screens.
Checkpoint: you have a target Mendix design – domain model, key microflows, and an integration approach – derived from business requirements, not copied from the source platform.
Phase 4 – Rebuild incrementally, starting with a pilot
Do not attempt the whole portfolio at once, and do not attempt even one large app in a single push. Rebuild incrementally, and make the first rebuild a genuine pilot whose job is to teach as much as to deliver:
- Rebuild the pilot app end to end – the app you prioritized in Phase 2 – so the team learns Mendix on something real: Studio Pro, the domain model, microflows, the review-and-deploy workflow, and your target architecture from Phase 3.
- Capture the patterns. As you build, write down the reusable decisions – naming, module structure, security setup, integration templates – so app two is faster than app one and app three faster still. This is the difference between one migration and a repeatable programme.
- Build in vertical slices. Deliver a complete, working feature – screen, logic, data, integration – before moving to the next, so you always have something testable rather than a half-built shell.
- Bring users in early. Show the pilot to real users while it is still cheap to change. Rebuilding is your one chance to fix the things they always disliked – take it.
Checkpoint: the pilot app is built, tested, and validated by real users on Mendix, and you have a written set of patterns to reuse on the next app.
Phase 5 – Run in parallel and cut over safely
A working rebuild is not a live rebuild. The riskiest moment is switching users off the old system and onto the new one, so plan it as carefully as the build itself:
- Migrate the data deliberately. Data does not move itself. Plan the extract, transform, and load from the old platform’s store into the Mendix domain model, reconcile record counts and key fields, and test the migration on a copy before you trust it with the real thing.
- Run in parallel where you can. For a period, keep the old app available while the Mendix app runs alongside it. Parallel running surfaces gaps in behaviour and data before they become incidents.
- Move users with a plan. Decide whether to cut over all at once or in waves, communicate the change, and prepare training and support for the new app – the UI and workflow will differ from what people are used to.
- Keep a rollback path. Do not decommission the old app on cutover day. Keep it deployable and its data recoverable until the Mendix app has proven stable in production, so falling back is a known step rather than a scramble.
- Monitor, then decommission. Watch errors, performance, and the areas you were least sure about for the first hours and days. Only switch off the old platform – and stop paying for it – once the new app is proven.
Checkpoint: data is migrated and reconciled, users are live on Mendix, the old system is still recoverable, and you have validated the rollback path before relying on it.
What trips teams up
- Expecting a converter. Teams that budget for a code translation and discover a rebuild lose trust and time. Plan for a rebuild from day one.
- Transliterating the old app. Copying screens and logic one-for-one drags every old workaround into Mendix and produces an app that never feels native. Re-architect instead.
- Migrating everything. Moving apps that should have been retired or left in place inflates cost and risk for no benefit. Be ruthless in Phase 2.
- Skipping the pilot. Starting with the biggest, most critical app means learning Mendix under maximum pressure. Learn on something contained first.
- Underestimating data migration. The build gets the attention; the data migration gets discovered late. It is often the hardest part – plan and test it early.
- Cutting over without a way back. Decommissioning the old system too soon turns a small problem into an outage. Keep the rollback path until the new app is proven.
The pre-flight checklist
- A written, honest rationale for switching – specific to your apps and costs.
- Every app tagged rebuild / retire / leave, with a prioritized rebuild list.
- A clear, contained first pilot app chosen.
- A target Mendix design derived from requirements, not copied from the source platform.
- Integrations and data sources re-evaluated for the Mendix approach.
- A data migration plan – extract, transform, load, and reconcile – tested on a copy.
- A parallel-running and user-cutover plan, with training and support ready.
- A validated rollback path; the old system stays recoverable until the new one is proven.
How Golden Earth helps
Re-platforming is a discipline, and it is one we run deliberately – senior engineers only, documentation-first, embedded in your team. We start with the honest question of whether you should switch at all, because a good consultancy talks you out of a migration that is not worth it. When the move does make sense, we help you inventory and prioritize the portfolio, design the target architecture properly for Mendix rather than transliterating the old app, and rebuild from a pilot outward so your team learns the platform and owns the result. Because we document as we go, you finish with reusable patterns and real knowledge in-house, not a black box. If you are weighing a move from OutSystems or Power Platform – or you have decided and want experienced hands to run it – talk to an expert.