Migrate Power Apps to a Custom App: 2026 How-To

You have already made the call. Your Power App started as a quick win — a form or tracker that replaced a spreadsheet — and for a while it did the job. Then the business leaned on it. The data grew, delegation warnings appeared, licensing crept up, and one internal tool quietly became a system you can't run without. Now you want to migrate Power Apps to a custom app — and if you've searched "migrate Power Apps to custom app," you've hit mostly environment-migration docs and forum threads, not a real methodology. You need the part almost nobody publishes: not whether to move, but how. This is that methodology: a practical, phased blueprint to move without breaking the business.

We at Craftware are a Microsoft Partner whose team has 20+ years of combined experience building on the Microsoft stack — Dynamics 365, Business Central, Azure, and the Power Platform itself. The key thing to understand about this move is what it's not: migrating off Power Apps is not leaving Microsoft. You're trading a low-code layer for custom .NET and Azure services that still speak to Dataverse, Dynamics 365, Business Central, and your Microsoft 365 tenant. Below, we walk the whole path — the readiness check, the migrate/keep/hybrid decision, and the phases that move your data, logic, integrations, and users.

First, Confirm You've Actually Outgrown It

Migration is real work, so make sure the pain is structural and not a setting you can change. In our experience, the honest signals that it's time to migrate off Power Apps are hard and specific:

• Delegation walls. When a query can't be delegated to the data source, Power Apps processes only the first 500 records locally by default — raisable to a maximum of 2,000 in app settings. Past that, filters, sorts, and aggregates can silently return incomplete results. (Confirm current thresholds in Microsoft's delegation documentation; Dataverse aggregate functions, for example, cap around 50,000 rows.)
• Request-limit throttling. Power Platform enforces daily API request limits per user — commonly 6,000 per 24 hours on a Power Apps per-app plan and 40,000 on a per-user plan. Verify your plan's current figure, but a data-heavy app bumping these ceilings is a scale signal.
• Licensing creep. Per-user or per-app licensing that was trivial at 10 users becomes a real line item at 200 — and it recurs forever.
• ALM and governance friction. No clean source control, painful environment promotion, and citizen-developer sprawl nobody fully owns.
• UX and integration ceilings. You need pixel-level UI control, offline behavior, or integration the connectors can't reach. If the wall is offline field work, the better target is usually a custom mobile app rather than a web rebuild.

If you're still weighing whether to move at all, that's a different question — this guide assumes you've decided. If even one of these walls is blocking a business-critical process, read on.

Migrate, Keep, or Go Hybrid?

Full migration isn't always the right call, and a partner who pretends otherwise is selling, not advising. There are three legitimate paths, and the cheapest one that solves your problem wins.

The hybrid option deserves more attention than it usually gets. A Power Apps to web app migration doesn't have to be all-or-nothing: you can leave the canvas app in place as a thin front end while the real work — validation, calculations, high-volume queries — runs in Azure services it calls through custom connectors or APIs. That buys scale and performance without retraining users, and it's often the right first step before a full rebuild. When the app truly is the business, full migration is the endgame — and the sections below are the how.

The Blueprint to Migrate Power Apps to a Custom App, Phase by Phase

The safe way to migrate Power Apps to a custom app is not a big-bang rewrite followed by a nervous weekend cutover. It's an incremental approach professionals call the strangler-fig pattern: you stand the new app up alongside the old one and move it across slice by slice, so the business keeps running and you can stop or roll back at any point.

Here is the phased blueprint we follow; the sections after it drill into the phases that carry the most risk.

Power Apps Data Migration: Dataverse, SharePoint, and Excel to Azure SQL

Data is where a migration succeeds or quietly fails, so this is the phase to slow down on. Power Apps data migration — moving records out of Dataverse, SharePoint, or Excel into Azure SQL — has four steps.

1. Inventory the sources. One Power App often reads from several places: Dataverse tables, a few SharePoint lists, and an Excel file someone still updates by hand. Map every source, its row count, and its relationships before you touch anything.

2. Map the schema. Design the target Azure SQL schema deliberately. This is your chance to fix accumulated compromises — enforce real foreign keys, add the indexes Dataverse handled invisibly, and normalize tables that grew organically.

3. Choose the ETL path by data size. Microsoft scales the tooling to the data, and the same logic applies when you migrate out:

• Small (under ~50,000 records): scripted exports, Power Query, or the Configuration Migration Tool, which builds an XML schema of your entities and relationships, exports to a portable package, and preserves dependencies.
• Medium (~50,000–500,000 records): Azure Data Factory, a low-code ETL service with 90-plus connectors, run in batches against a staging database.
• Large or complex (500,000+ records, intricate relationships): Azure Data Factory or SSIS pipelines, sometimes with Azure Synapse Link for Dataverse feeding Azure SQL, plus custom scripts for the tricky transforms.

4. Validate, then plan the data cutover. Migration isn't done when the rows land — it's done when you've proven they're right: row-count reconciliation, referential-integrity checks, and spot-checks of high-value records against the source. For the final switch, freeze writes to the old app or run a delta sync so records created during the migration window aren't lost.

Rebuilding Your Logic: Power Fx and Power Automate to .NET and Azure

Your business rules don't live in one place. They're spread across Power Fx formulas on controls, Power Automate cloud flows, and — if you use Dataverse — plug-ins and business rules. Moving Power Fx and Power Automate to .NET means translating each into its natural home in a custom architecture.

• Power Fx formulas become C#/.NET code. Power Fx is a functional, Excel-like language; most of what it expresses — validation, calculated fields, conditional logic — maps cleanly to methods and services in .NET. Where Dataverse already centralizes logic in a plug-in, you're ahead: plug-ins are compiled .NET assemblies, so that C# is a head start rather than a rewrite.
• Power Automate flows become Azure Functions or Logic Apps. Asynchronous, long-running, or multi-step flows map to Azure Functions (code-first) or Azure Logic Apps (a visual, connector-driven workflow familiar to anyone who has built flows). Scheduled and event-driven automations translate almost one-for-one.
• Scattered rules become API services. Logic spread across screens gets consolidated into a service layer with one source of truth — the maintainability win that made migration worth doing.

Treat the rebuild as a chance to fix, not just to copy. Years of Power Fx workarounds — the nested ForAll loops added to dodge a limit, the flow bolted on to patch a gap — don't need to survive the trip. This is where our Human + AI model earns its keep: senior Microsoft developers use AI to accelerate the mechanical parts — reading existing formulas and flows, drafting the equivalent C#, and generating unit tests that assert the new code matches the old behavior. The engineers own the architecture and judgment; AI compresses translation and testing, a concrete reason migration is usually faster and cheaper than teams fear.

Preserving Integrations, Identity, and Users

A migration that scales beautifully but forces everyone to log in differently fails on adoption. Three things have to survive the move.

Integrations. Every connector your app used — to Dynamics 365, Business Central, a payment provider, a shipping API — gets re-pointed to a real integration in the custom app. This often improves the connection, replacing a rate-limited connector with a direct, purpose-built API you control.

Identity. This is the one that reassures users most: they keep the same Microsoft login. A custom .NET web app registers as an application in Microsoft Entra ID (formerly Azure AD) and authenticates with OpenID Connect — Microsoft's recommended protocol for new web apps. Users sign in with the same work account and single sign-on they already use for Microsoft 365. No new passwords, no separate directory, no help-desk surge.

Users. Because you migrated slice by slice, you can move users the same way — by team or module — with a short overlap where both apps are available. Retraining is minimal when the workflow and the login are familiar; the app is faster and the ceilings are gone, but the muscle memory carries over.

This is Microsoft continuity made concrete: you left the Power Platform, not the Microsoft ecosystem — Entra ID, Azure, SQL, and your Dynamics 365 and Business Central data are all still where they were.

De-Risking the Cutover: Parallel Run, Rollback, and Integrity

The cutover is the moment everyone worries about, and it's the phase most migration guides skip entirely. Done right, it's anticlimactic — because you removed the risk in advance.

• Phased rollout. Switch one user group or module at a time, not the whole company at once. Problems surface small and contained.
• Parallel run. For a defined window, run the old Power App and the new custom app side by side against the same data, and reconcile outputs. When the numbers match for long enough, confidence is earned, not assumed.
• Data-integrity checks. Automated reconciliation — record counts, totals, and key relationships compared old-versus-new — catches drift before users do.
• A real rollback plan. Every phase has a documented way back to the previous state. You almost never need it; having it is what lets you move confidently.
• Go/no -go criteria. Define in advance what "safe to proceed" means — error thresholds, performance targets, sign-off owners — so advancing is an objective decision, not a gut call at 9 p.m.

None of this is glamorous, and all of it is why a migration can happen with effectively no downtime for the business.

Power Apps Migration Timeline and Cost

Here is the number nobody publishes. Almost everyone prices licensing versus building; almost no one prices the migration project itself. We can't quote your project sight unseen, but we can share the illustrative planning ranges we see so you can budget with your eyes open. Treat these as order-of-magnitude ranges, not a quote — the real number comes from an assessment.

What drives the range is app complexity, data volume, and integration count, far more than screen count. Discovery and assessment typically run one to three weeks up front regardless of size.

_{*Illustrative planning ranges based on typical Microsoft-stack custom builds — not a quote. Confirm scope and current pricing with an assessment.}

These ranges sit lower than the "custom is always expensive" reputation suggests, for two reasons: the Human + AI model compresses the most labor-intensive phases, and incremental migration spreads the cost across phases rather than one lump paid before you see value. A migration-readiness assessment inventories your data, logic, flows, and integrations and returns a phased plan with a timeline and a defensible cost range.

A Real Migration: Before and After

The following is a representative, illustrative scenario based on the kinds of migrations we do — not a specific named client — with outcomes shown as ranges rather than precise figures.

A mid-market services firm in the Houston area runs project timesheets, approvals, and billing hand-offs in a Power App. It works well at one department. Two acquisitions later, the app serves three business units, the dataset has crossed the delegation limit, and approval reports quietly miss records. The team papers over the gap with manual CSV exports into Dynamics 365 for billing — several hours of someone's week, every week.

The migration runs in phases over a few months. Data moves from Dataverse and two SharePoint lists into Azure SQL with full validation. Power Fx approval logic and the Power Automate billing flow are rebuilt as .NET services and Azure Functions. Connectors are re-pointed to a direct Business Central integration, and users keep their Microsoft sign-in through Entra ID.

The before-and-after pattern is consistent with what we see: reports that returned partial results now return complete data in under a second; the multi-hour weekly export disappears; and licensing that climbed with every new user flattens into predictable Azure hosting. The app stopped being a liability and went back to being an asset — without leaving the Microsoft stack.

Frequently Asked Questions

How do you get data out of Dataverse or SharePoint into a custom app?

You export it and load it into a target database — usually Azure SQL. Smaller datasets suit scripted exports, Power Query, or the Configuration Migration Tool; larger or more complex data calls for Azure Data Factory (or SSIS, sometimes with Azure Synapse Link). The non-negotiable step is validation afterward — row counts, referential integrity, and spot-checks — so you can prove the data arrived intact.

What happens to our Power Automate flows and Power Fx formulas when we migrate?

They get translated, not lost. Power Fx formulas become C#/.NET code; Power Automate flows become Azure Functions or Logic Apps; scattered rules become API services. Because Dataverse plug-ins are already compiled .NET, some logic transfers with a head start — and the rebuild lets you retire the workarounds that piled up inside the platform's limits.

Can we migrate without downtime?

Yes, in almost every case. We use a phased, parallel-run approach: the new app runs alongside the old Power App, you reconcile the two, and you cut over one group or module at a time with a rollback plan at each step. The business keeps operating throughout, so a full-stop outage is rarely necessary.

How long does a Power Apps migration take, and what drives the timeline?

A simple single-department app is often 6–10 weeks; a complex, business-critical app with many integrations can run several months. The biggest drivers are data volume, integration count, and logic complexity — not the number of screens. A short discovery phase turns these variables into a concrete schedule.

Do users have to log in differently after we migrate?

No. A custom .NET app registers in Microsoft Entra ID and uses OpenID Connect single sign-on, so your team signs in with the same Microsoft 365 work account they already use. Same credentials, same SSO — one of the biggest reasons adoption stays smooth.

Can we do a hybrid — keep the Power Apps front end but move the backend to Azure?

Absolutely, and it's often the smart first move. You keep the canvas app your users know while shifting the heavy data and logic to Azure SQL and .NET services behind APIs. That relieves scale and performance pressure without retraining anyone — and leaves a clean path to a full migration later.

Ready to Plan Your Power Apps Migration?

If your Power App has outgrown the platform, the next step isn't a rebuild — it's a plan. We at Craftware offer a free migration assessment: we inventory your app's data, Power Fx logic, flows, and integrations, then hand back a phased migration plan with a timeline, a rollback strategy, and an illustrative cost range — done with your team, and entirely inside the Microsoft ecosystem you already run on. Whether the answer is keep-and-optimize, hybrid, or a full migration, you'll leave knowing exactly what to do next. Book your free migration assessment and get a clear, honest path off Power Apps and onto an app that scales.