The app your team runs on every day is starting to fight back. Delegation warnings creep across your galleries, the monthly Power Platform bill climbs with every user you add, and a capability the business genuinely needs keeps colliding with what the platform allows. If you've hit that wall, your question has already moved past "should we go custom?" to something more concrete: how do you rebuild a Power App as a custom app without throwing away the work — and the Microsoft investment — you already have?
This is a playbook, not a pitch: the real Microsoft limits that push teams over the edge, a six-phase migration path, and honest numbers on cost — all while staying on the Microsoft stack. We at Craftware are a Microsoft Partner with 20+ years building both Power Platform and custom Azure/.NET solutions, so when we say some apps should stay in Power Apps, we mean it.
The Short Answer: Rebuild When the App Is the Work
Rebuild when the app has become the way the work actually gets done and it's hitting hard limits you can't configure around — data past the delegation ceiling, a license bill that scales painfully with each user, or logic and integrations beyond what low-code allows. Keep it in Power Apps when the app is a stable internal form, the data stays under the limits, and a targeted fix would solve the problem.
Why Teams Rebuild: The Power Apps Ceiling and the 2,000-Record Delegation Limit
Power Apps — Microsoft's low-code app builder on the Power Platform — runs on managed infrastructure, and that infrastructure comes with guardrails. Low-code adoption has been enormous: Gartner projected that by 2025, roughly 70% of new applications built inside organizations would use low-code or no-code tools, up from less than 25% in 2020 — so more teams than ever now hit the platform's edges. The guardrails aren't defects; they're the trade-off for speed and low maintenance. Trouble starts when your app crosses one and the symptom is a business problem, not an error.
The most consequential guardrail is the Power Apps delegation limit. When a query can't be "delegated," Power Apps processes it locally and caps how many records it pulls. Per Microsoft's delegation documentation on Microsoft Learn, that cap defaults to 500 records and can be raised to a maximum of 2,000. Past that ceiling the app doesn't error — it quietly works on a partial set: a report filters 20,000 rows and silently stops at 2,000, and a total comes back wrong. That silence is the danger — the app looks healthy while the numbers lie.
Here are the limits that most often justify a rebuild, and the symptom each one produces:
| Power Apps limit | What Microsoft sets it to | The symptom your team feels |
|---|---|---|
| Delegation / data row limit | Non-delegable queries return 500 records by default, raisable to a 2,000 maximum | Reports, filters, and totals silently go wrong on large tables — record 2,001 simply isn't there |
| Daily Power Platform request limits | Roughly 6,000 requests/24h on per-app and Microsoft 365–bundled licenses; 40,000 on the Power Apps Premium (per-user) plan | High-transaction apps hit throttling; you buy up licenses or capacity add-ons to keep running |
| App media storage | 200 MB total per app, 64 MB per individual file | Document- and media-heavy apps outgrow the container and need external storage plumbing |
| Excel connector ceiling | About 2,000 records loadable through the Excel connector | Spreadsheet-backed apps stall and truncate as the data grows |
| ALM / version control | Solution export/import; no native git-style branching or line-by-line diffing | Release cadence slows; multi-developer work and clean rollbacks get risky |
| Licensing model | Per-app or per-user, billed monthly per head | The bill scales linearly with adoption — success makes the app more expensive |
(These figures reflect Microsoft's published limits at the time of writing; Power Platform limits and pricing change, so confirm current numbers on Microsoft Learn before planning around them.)
None of these mean Power Apps is bad — only that it was built for a job your app has outgrown.
Don't Rebuild Yet: When to Keep, Optimize, or Go Hybrid
Knowing when to move off Power Apps also means knowing when not to. Plenty of apps that feel slow or fragile need a tune-up, not a rebuild.
Keep and optimize if the app is a stable form or tracker with a small user base, the data sits under the delegation ceiling, or the slowness traces to non-delegable formulas — often fixable by rewriting queries to be delegable, or migrating from SharePoint or Excel to Dataverse, which supports far more delegation.
Go hybrid if the backend is the problem but the interface is fine. Keep the Power Apps front end your users know and move the heavy lifting — large datasets, complex calculations, high-volume processing — into Azure SQL and Azure Functions behind an API. It's often the highest-ROI move: no full rebuild, no retraining.
Rebuild when the app is the work, several limits bite at once, or the roadmap needs what low-code structurally can't deliver. On the fence? That's what a short assessment resolves — cheaper than six months rebuilding the wrong thing.
What "Custom" Means When You Stay on the Microsoft Stack
Here's the assumption worth dismantling: moving off Power Apps does not mean leaving Microsoft. Most "Power Apps alternative" lists push you toward a different low-code vendor with its own lock-in — the wrong trade for a Microsoft-centric business. You can replace Power Apps with custom software and keep everything around it. A typical target architecture for Power Apps to custom .NET development:
- A .NET web app on Azure App Service for the interface and logic — no delegation cap, no per-user license.
- Azure SQL for the heavy data, while keeping Dataverse where it's still the right system of record — migrate only what has outgrown it.
- Azure Functions and Logic Apps for the workflows your Power Automate flows handled.
- Microsoft Entra ID (formerly Azure AD) for single sign-on — users sign in exactly as today.
- Continued interoperability with Dynamics 365 and Business Central through their APIs.
The trade the rebuild makes:
| Dimension | Power App today | Custom rebuild on Azure / .NET |
|---|---|---|
| Data scale | Delegation ceiling (500–2,000 non-delegable records) | No platform cap — Azure SQL scales with the business |
| Cost model | Per-user / per-app licensing that rises with headcount | One-time build + flat hosting; no per-user tax |
| Customization | Bounded by platform capabilities | Built exactly to your workflow |
| Integration depth | Connector-based; fragile for deep or legacy systems | Full API integrations to Dynamics 365, Business Central, anything |
| Release & ALM | Solution export/import; limited version control | Full source control, CI/CD, clean rollbacks |
| Ownership | Runs on Microsoft's platform terms | You own the code and IP — still on Microsoft infrastructure |
| Maintenance | Low day-to-day; dependent on the platform roadmap | Needs a maintenance plan; you control the roadmap |
You escape the ceiling and keep the Microsoft ecosystem, with the flexibility, scale, and code ownership of a custom app.
The Rebuild Playbook: 6 Phases to Rebuild a Power App as a Custom App
A rebuild done well is a controlled migration, not a big-bang rewrite. This is the Power Apps migration to a custom app we run, phase by phase, so the business keeps operating throughout.
Phase 1: Assess and Inventory
You can't rebuild what you haven't mapped. We inventory every screen, data source, Power Fx formula, Power Automate flow, connector, and user role, plus the delegation warnings already firing — then make the honest call: optimize, hybrid, or rebuild.
Phase 2: Design the Target Architecture
We design the destination: what moves to Azure SQL versus stays in Dataverse, where logic lives (app code versus Azure Functions), how identity and integrations work, and the cutover sequence. Deciding what to keep matters as much as what to rebuild — the goal is the smallest change that removes the ceiling.
Phase 3: Migrate the Data
Data moves carefully. We extract from Dataverse, SharePoint, or Excel into the target — commonly Azure SQL — using tools such as Azure Data Factory or the Configuration Migration tool, mapping the schema, preserving relationships and history, and validating row counts on both sides.
Phase 4: Re-Platform the Logic
Power Fx formulas and business rules become application code (typically C#/.NET); Power Automate flows become Azure Functions or Logic Apps. We re-implement each rule's intent rather than copy it line for line — a filter contorted to dodge the delegation limit becomes a clean database query.
Phase 5: Re-Wire Integrations and Identity
Every connector becomes a proper API integration. If the Power App synced with Dynamics 365 or Business Central, we re-point those to the systems' APIs with production-grade reliability. Single sign-on stays on Entra ID, so access doesn't change for users.
Phase 6: Parallel-Run and Cut Over
The new app runs in parallel with the Power App, data kept in sync, and users move over in a controlled rollout with a rollback plan ready. Once it's proven against real usage, you retire the Power App — and stop paying for it.
What a Rebuild Costs — and What You Stop Paying
Two numbers decide this: what the rebuild costs once, and what Power Apps licensing costs forever. Power Apps is billed per user or per app, per month; published pricing has ranged from roughly $5 per user/app to about $20 per user for the premium plan, but terms move often, so confirm current numbers on Microsoft's pricing page.
The key property isn't the rate; it's that the cost scales with headcount — every new user is another monthly charge. Here's an illustrative model for a 150-person app; treat every figure as a planning placeholder, not a quote:
| Stay on Power Apps (150 users) | Rebuild as a custom app on Azure | |
|---|---|---|
| Upfront investment | $0 | ~$90,000 (a moderate-complexity app, illustrative) |
| Year 1 cost | ~$36,000 in licensing | ~$90,000 build + ~$12,000 to run |
| Annual cost thereafter | ~$36,000 and rising with headcount | ~$12,000, flat (Azure hosting + maintenance) |
| Cost to add 50 more users | +~$12,000 every year | ~$0 |
| 5-year total (flat headcount) | ~$180,000+ | ~$150,000 |
Rebuild projects fall into three bands: a simple single-workflow app at $30,000–$60,000, a moderate multi-workflow app with integrations at $60,000–$150,000, and a complex, business-critical system at $150,000+. Hosting is modest, and maintenance tends to run 15–20% of the build per year.
Break-even lands around year three to four — then the lines diverge, because the Power Apps bill rises with every user while the custom app stays roughly flat. The more people use the app, the faster the rebuild pays off — the opposite of the low-code curve, where success is what makes it expensive. In an assessment we build this model with your real headcount.
A Representative Rebuild: Before and After
The following is a representative scenario — a composite of rebuilds we see regularly, with directional outcomes rather than specific figures, and not a single named client.
A regional distributor built a Power App to manage inbound orders and inventory on SharePoint and Dataverse — a genuine win at a few hundred SKUs. Two years later the catalog passed 20,000 records and the cracks showed: stock reports silently truncated at the delegation ceiling, so on-hand totals were quietly wrong; month-end close relied on manual Excel exports; the warehouse team's growth meant a license bill climbing every quarter; and the app now had to write back to Business Central for invoicing, which the flows handled fragilely.
The rebuild kept Dataverse as the system of record where it fit, moved the high-volume tables to Azure SQL, and replaced the canvas app with a .NET web app on Azure App Service; the flows became Azure Functions, the Business Central link a proper API integration, and sign-on stayed on Entra ID. After a few weeks running in parallel, the team cut over. The outcomes: complete, correct reports at any table size; no more manual month-end exports; changes shipping in days through real source control; and license creep replaced by predictable Azure hosting.
How AI Shrinks the Rebuild in 2026
The old knock on custom development — too expensive, too slow — has narrowed, and our Human + AI model is a big reason why. Senior developers stay accountable for architecture and correctness while AI accelerates the mechanical parts: discovery (inventorying existing formulas, flows, and data sources), code translation (converting Power Fx logic to C#, scaffolding the .NET app, standing up integrations), and test generation (the coverage that proves the rebuilt app matches the original's behavior).
To be clear: AI accelerates the work but doesn't ship unreviewed — every output is checked by an experienced developer, because a rebuild's whole point is reliability. A rebuild is also the moment to add what the Power App never could: now that you're on Azure, Azure OpenAI comes into reach — natural-language search, document extraction, summarization. You escape the old ceiling and gain headroom you never had.
Frequently Asked Questions
Can you migrate the data out of Power Apps into a custom app? Yes. Data in Dataverse, SharePoint, or Excel can be extracted into a custom database such as Azure SQL, with schema mapping, preserved relationships, and validation on both sides. Where Dataverse still fits, you keep it and migrate only what has outgrown the platform.
Do we have to leave Microsoft to move off Power Apps? No — and for a Microsoft-centric business you usually shouldn't. You can replace Power Apps with a custom .NET app on Azure while keeping Dataverse, Entra ID single sign-on, Dynamics 365, and Business Central. You escape the platform's limits, not its ecosystem.
How long does it take to rebuild a Power App as custom software? It depends on complexity — a simple single-workflow app can take a few weeks, a moderate app with integrations a couple of months, a complex system longer. Because the rebuild runs in phases with a parallel-run before cutover, the business keeps operating throughout.
What happens to our Power Automate flows and Power Fx logic? They're re-platformed, not lost: Power Fx formulas become application code, and Power Automate flows become Azure Functions or Logic Apps — often more cleanly, since the old constraints no longer apply.
Is it cheaper to keep paying Power Apps licenses or to rebuild? Short-term, staying is cheaper; over a multi-year horizon at scale, a rebuild usually wins, because per-user licensing rises with headcount while a custom app's cost stays roughly flat. Break-even often lands around three to four years, sooner the more users you have.
Can we rebuild in phases and run both apps in parallel to avoid downtime? Yes — that's how we recommend it. The custom app runs alongside the Power App with data kept in sync, users move over gradually, and a rollback plan stays ready until the new app is proven — a deliberate cutover, not an overnight switch.
Ready to Scope Your Power Apps Rebuild?
If your app has hit the delegation ceiling, the license bill won't stop climbing, or the roadmap needs more than low-code can give, the path forward isn't guesswork — and it isn't leaving Microsoft. It's a phased rebuild onto Azure and .NET that keeps your data, identity, and ERP where they are, and stops the per-user meter running.
We at Craftware start with a free Power Apps rebuild assessment: we inventory your current app (data, Power Fx logic, flows, connectors, users), map the real limits it's hitting, and hand back a phased rebuild plan with a rough timeline and a TCO break-even estimate. If the right answer is to optimize or go hybrid instead, we'll tell you that. Book your free Power Apps rebuild assessment and get a clear plan before you commit budget.
