Application Migration: Palantir Foundry to Azure¶

A technical deep-dive for application developers, UX architects, and platform engineers migrating Foundry's application building stack to Azure-native services.

Executive summary¶

Palantir Foundry provides a vertically integrated application building stack: Workshop for low-code operational apps, Slate for custom HTML/CSS/JS applications, OSDK for external integrations, and Object Views for embedded object detail displays. All of these tools are tightly coupled to the Foundry Ontology — they query object types, traverse link types, and execute Actions defined in the Ontology layer.

Azure provides a broader, more modular application ecosystem: Power Apps for low-code operational apps, Power Pages for external-facing portals, Azure Static Web Apps for custom React/Angular/Vue applications, Power BI Embedded for analytics, PCF (Power Apps Component Framework) for custom components, and a rich set of REST APIs (Microsoft Graph, Fabric REST, Data API Builder) for external integrations. These tools connect to Dataverse, SQL databases, SharePoint, Fabric lakehouses, and hundreds of other data sources through standard connectors.

This guide provides the detailed mapping, migration patterns, and practical guidance for moving every Foundry application capability to its Azure equivalent.

1. Foundry application building stack overview¶

Foundry's application layer consists of six primary tools, all built on top of the Ontology:

Key architectural principle: In Foundry, the Ontology is the single data access layer for all applications. Widgets do not query databases — they query object types. Buttons do not call APIs — they execute Actions. This tight coupling is both Foundry's strength (consistent data access) and its primary lock-in mechanism (nothing works without the Ontology).

2. Azure application building stack¶

Azure's application ecosystem is modular. Applications connect to data through connectors, APIs, and direct database access rather than a single proprietary layer.

graph TB
    subgraph "Application Layer"
        PA[Power Apps<br/>Canvas & Model-driven]
        PP[Power Pages<br/>External portals]
        SWA[Azure Static Web Apps<br/>React / Angular / Vue]
        PBI[Power BI Embedded<br/>Analytics & dashboards]
    end

    subgraph "Logic & Automation"
        PAuto[Power Automate<br/>Flows & approvals]
        LA[Logic Apps<br/>Enterprise integration]
        AF[Azure Functions<br/>Custom compute]
        EG[Event Grid<br/>Event routing]
    end

    subgraph "Component & Extension"
        PCF[PCF Components<br/>Custom controls]
        PBIV[Power BI Custom Visuals<br/>D3.js / ECharts]
        CS[Copilot Studio<br/>AI agents & chatbots]
    end

    subgraph "Data & API Layer"
        DV[Dataverse<br/>Business data]
        DAB[Data API Builder<br/>REST/GraphQL over SQL]
        Graph[Microsoft Graph API<br/>M365 data]
        FabricAPI[Fabric REST APIs<br/>Lakehouse data]
        SQL[(Azure SQL / Fabric SQL)]
    end

    PA --> DV
    PA --> PAuto
    PA --> PCF
    PP --> DV
    PP --> DAB
    SWA --> DAB
    SWA --> FabricAPI
    SWA --> Graph
    PBI --> SQL
    PBI --> PBIV
    PAuto --> DV
    PAuto --> LA
    PAuto --> AF
    CS --> DV
    CS --> Graph
    DAB --> SQL

CSA-in-a-Box evidence paths¶

CSA-in-a-Box provides working implementations for many of these components:

3. Workshop to Power Apps migration¶

Workshop is Foundry's flagship application builder. It provides 60+ widgets, an event/action system, variables for state management, and direct Ontology binding. The Azure migration target depends on the app type:

3.1. Workshop widget mapping table¶

This is the comprehensive mapping of Workshop widgets to their Azure equivalents.

Data display widgets¶

Chart and visualization widgets¶

Map widgets¶

See Section 7 for detailed map migration patterns.

Form and input widgets¶

Layout and container widgets¶

Action and navigation widgets¶

Media and embed widgets¶

3.2. Workshop events and actions to Power Apps + Power Automate¶

Workshop uses an event-action model: user interactions fire events, which trigger actions (navigate, set variable, execute Ontology Action, open panel). Power Apps uses a similar but differently structured model:

3.3. Workshop theming to Power Apps theming¶

Workshop supports application-level theming (colors, fonts, spacing). Power Apps provides equivalent capabilities:

• Theme JSON: Power Apps canvas apps accept a Theme JSON object that controls colors, fonts, and control styling globally
• Component libraries: Create reusable styled components shared across apps
• Fluent UI: Model-driven apps automatically use Microsoft Fluent UI design language
• CSS in Power Pages: Full CSS control for external-facing applications

CSA-in-a-Box evidence: The React portal at portal/react-webapp/src/ demonstrates a consistent component library approach with reusable components (Card.tsx, Button.tsx, StatusBadge.tsx, Modal.tsx) that apply consistent styling.

4. Slate to Power Pages / React migration¶

Slate is Foundry's custom application framework for developers who need more control than Workshop provides. Slate apps use HTML, CSS, and JavaScript with drag-and-drop widget placement and direct Ontology API access.

4.1. Migration target selection¶

4.2. Slate JavaScript to Azure equivalents¶

Slate apps embed JavaScript that calls Foundry's Ontology API. The following table maps common Slate API patterns to Azure equivalents:

4.3. Slate drag-and-drop widgets to React components¶

Slate's widget library provides pre-built UI elements. CSA-in-a-Box's React portal demonstrates equivalent implementations:

4.4. Deployment model¶

5. OSDK to Microsoft APIs migration¶

OSDK (Ontology SDK) auto-generates typed SDKs in TypeScript, Python, and Java that mirror the Foundry Ontology. External applications use OSDK to query objects, traverse links, execute actions, and subscribe to real-time updates. Azure does not have a single equivalent — the replacement depends on the data source and use case.

5.1. API mapping¶

5.2. Data API Builder as OSDK replacement¶

Data API Builder (DAB) is the closest Azure equivalent to OSDK for database-backed applications. It auto-generates REST and GraphQL APIs from Azure SQL, PostgreSQL, MySQL, or Cosmos DB schemas.

CSA-in-a-Box evidence: See docs/tutorials/11-data-api-builder/ for a complete tutorial on setting up DAB for a data product catalog.

Key similarities to OSDK:

• Auto-generated typed API from database schema (like OSDK from Ontology)
• REST and GraphQL endpoints (OSDK provides REST and generated SDKs)
• Relationship navigation (OSDK provides link traversal)
• Filtering, sorting, pagination built in
• Azure AD authentication integrated

Key differences from OSDK:

• DAB does not auto-generate client SDKs — use OpenAPI codegen or @azure/data-api-builder-client for typed access
• DAB operates on relational schemas, not ontology object types
• DAB does not provide real-time subscriptions — pair with SignalR for that
• DAB does not have a built-in action framework — pair with Power Automate or Azure Functions

5.3. Migration pattern for OSDK-consuming applications¶

Step 1: Inventory OSDK usage
  - List all external apps consuming OSDK
  - For each app, catalog: object types queried, links traversed,
    actions executed, subscriptions used

Step 2: Map data sources
  - For each object type, identify the Azure data source
    (Dataverse, Azure SQL, Fabric SQL endpoint, SharePoint)
  - Design the API layer (DAB for SQL, Graph for M365, Dataverse API for Power Platform)

Step 3: Set up Data API Builder
  - Define entity mappings in dab-config.json
  - Configure relationships for link traversal
  - Set up Azure AD authentication
  - Deploy to Azure App Service or Container Apps

Step 4: Refactor client code
  - Replace OSDK imports with fetch/axios calls to DAB endpoints
  - Replace OSDK type imports with generated TypeScript types from OpenAPI
  - Replace OSDK action calls with Power Automate HTTP triggers
  - Replace OSDK subscriptions with SignalR connections

Step 5: Test and validate
  - Verify all queries return equivalent data
  - Validate action execution through Power Automate
  - Load test API endpoints

6. Action buttons to Power Automate flows¶

Foundry Actions are the write-side of the Ontology: they modify object properties, create/delete objects, and trigger side effects. Workshop Action Buttons execute these Actions. In Azure, Power Automate flows provide equivalent write-side automation.

6.1. Action type mapping¶

6.2. CSA-in-a-Box flow examples¶

The portal/powerapps/flows/ directory contains five production Power Automate flows that demonstrate the Action Button replacement pattern:

6.3. Connecting Power Apps buttons to Power Automate flows¶

In Power Apps, Action Buttons become Button controls with OnSelect properties that call Power Automate flows:

// Workshop: Action Button executes "EscalateIncident" action
// Power Apps equivalent:
Button.OnSelect =
    Set(varLoading, true);
    EscalateIncidentFlow.Run(
        Gallery1.Selected.IncidentId,
        User().Email,
        TextInput_Reason.Text
    );
    Notify("Incident escalated successfully", NotificationType.Success);
    Refresh(Incidents);
    Set(varLoading, false)

Pattern: Every Foundry Action becomes a Power Automate flow. The flow is added as a data source in Power Apps, and buttons call FlowName.Run(parameters).

7. Map widgets to Azure Maps + Power BI¶

Workshop and Slate both offer map widgets that display geospatial data from the Ontology. Azure provides two primary mapping options: Azure Maps (interactive SDK) and the Azure Maps Power BI visual (embedded analytics).

7.1. Map capability mapping¶

7.2. Migration decision¶

• If the map is primarily for data visualization (colored markers, regional analysis, dashboards): use the Azure Maps Power BI visual embedded in a Power BI report. This provides filtering, cross-highlighting, and drill-through with no custom code.
• If the map requires interactivity (drawing boundaries, route planning, real-time tracking, indoor mapping): build a custom React component using the Azure Maps SDK and host it in Azure Static Web Apps or embed it as a PCF component.
• If the map is in a Power Apps canvas app: use the Power Apps Map control (preview) for simple point displays, or embed a Power BI visual for analytical maps.

7.3. Azure Maps implementation in React¶

// Example: Azure Maps in a React component (CSA-in-a-Box pattern)
import { AzureMap, AzureMapDataSourceProvider,
         AzureMapLayerProvider } from 'react-azure-maps';

const IncidentMap = ({ incidents }) => (
  <AzureMap
    options={{
      authOptions: { authType: 'subscriptionKey', subscriptionKey: process.env.AZURE_MAPS_KEY },
      center: [-77.0369, 38.9072],  // Washington DC
      zoom: 10
    }}
  >
    <AzureMapDataSourceProvider id="incidents">
      {incidents.map(inc => (
        <AzureMapFeature
          key={inc.id}
          type="Point"
          coordinate={[inc.longitude, inc.latitude]}
          properties={{ title: inc.title, severity: inc.severity }}
        />
      ))}
    </AzureMapDataSourceProvider>
    <AzureMapLayerProvider
      type="BubbleLayer"
      options={{
        color: ['match', ['get', 'severity'], 'high', 'red', 'medium', 'orange', 'green'],
        radius: 8
      }}
    />
  </AzureMap>
);

8. Form patterns migration¶

Workshop forms collect user input and execute Actions to write data. Power Apps canvas apps provide equivalent form patterns with richer validation and layout options.

8.1. Form pattern mapping¶

8.2. CSA-in-a-Box registration wizard pattern¶

The React portal at portal/react-webapp/src/components/register/ implements a multi-step registration wizard that demonstrates the equivalent of a Workshop multi-step form:

This pattern maps directly to a Power Apps multi-screen wizard or a Workshop multi-step form.

8.3. Validation patterns¶

9. External and public-facing apps¶

Foundry's Consumer Mode allows external users (citizens, partners, vendors) to access Ontology-backed applications without full Foundry permissions. Azure provides two primary options for external-facing applications.

9.1. Power Pages (recommended for most cases)¶

Power Pages (formerly Power Apps Portals) is purpose-built for external-facing web applications:

9.2. Azure Static Web Apps + Azure AD B2C (for custom apps)¶

For applications requiring full UI customization:

9.3. Migration decision¶

• Standard portal (forms, lists, knowledge base, self-service): Power Pages — faster development, built-in authentication, content management
• Custom interactive app (real-time dashboards, mapping, complex workflows): Azure Static Web Apps with React — full control, custom UI
• Hybrid: Power Pages for the portal shell + embedded Power BI visuals or Azure Maps for specialized components

10. AI-assisted app building¶

Foundry Pilot generates complete applications from natural language prompts. It creates Ontology entities (object types, link types, actions), a React+OSDK frontend, seed data, and deployment configuration. Azure provides multiple AI-assisted development tools.

10.1. AI app building comparison¶

10.2. Key difference¶

Foundry Pilot generates a complete vertical slice (data model + API + frontend) in a single prompt. Azure's approach is modular: Copilot in Power Apps generates the app, Copilot in Dataverse generates the schema, Copilot in Power Automate generates the flows. The Azure approach is less magical for simple demos but more flexible for production applications because each layer can be independently tuned, tested, and governed.

11. Marketplace to managed solutions¶

Foundry Marketplace is a storefront for discovering, installing, and managing packaged products (bundles of pipelines, Ontology entities, applications, models). Azure provides equivalent packaging and distribution through the Power Platform ecosystem and Azure Marketplace.

11.1. Packaging comparison¶

11.2. CSA-in-a-Box data marketplace¶

The csa_platform/data_marketplace/ module demonstrates a data product catalog pattern:

This marketplace pattern can be extended to package and distribute reusable data products, analytics templates, and application components across an organization.

11.3. Distribution models¶

12. UX comparison and managing expectations¶

Migrating from Foundry to Azure involves a shift in user experience philosophy. Setting expectations early prevents stakeholder friction during the transition.

12.1. What gets better¶

12.2. What changes (neutral)¶

12.3. What requires careful handling¶

12.4. Stakeholder communication template¶

When presenting the migration to stakeholders, frame the conversation around outcomes rather than features:

• "Our analysts will access data products in Power BI and Teams, not a separate platform" — eliminates context switching
• "Our operational apps will work on mobile devices" — new capability for field operations
• "We reduce per-seat costs by 40-60% and eliminate vendor dependency" — direct financial benefit
• "Our team builds skills that transfer across the industry" — career development and hiring flexibility
• "We gain 400+ connectors to other systems without custom integration" — ecosystem leverage

13. Common pitfalls¶

Pitfall 1: Trying to replicate the Ontology in Power Apps¶

Problem: Teams attempt to rebuild the entire Foundry Ontology as Dataverse tables before building any applications. This delays app delivery by months.

Solution: Migrate data and apps incrementally. Start with the top 3-5 most-used Workshop apps. For each app, migrate only the object types that app uses. Build the Dataverse schema driven by application needs, not by Ontology completeness.

Pitfall 2: Ignoring the Power Platform learning curve¶

Problem: Teams assume that "low-code" means "no training." Workshop power users struggle with Power Apps formula language (Set(), Navigate(), Filter(), Patch()).

Solution: Budget 2-3 weeks for Power Apps training. Start with Microsoft Learn modules. Pair Workshop developers with experienced Power Platform developers for the first 2-3 app migrations. The CSA-in-a-Box Power Apps examples at portal/powerapps/ provide working reference patterns.

Pitfall 3: Building everything as custom React apps¶

Problem: Teams with strong JavaScript developers default to building everything in React, bypassing Power Apps entirely. This creates a maintenance burden and loses the benefits of the Power Platform ecosystem (connectors, AI Builder, approval workflows).

Solution: Use the decision matrix in Section 4.1. Default to Power Apps for internal operational apps. Use React only when the app requires capabilities that Power Apps cannot provide (complex visualizations, real-time interactions, custom map behaviors). The CSA-in-a-Box React portal at portal/react-webapp/src/ is appropriate for the data platform portal — it would not be appropriate for a simple approval workflow.

Pitfall 4: Forgetting Power Automate for write operations¶

Problem: Teams build Power Apps with direct Dataverse writes for everything, missing the opportunity to add validation, notifications, audit logging, and error handling through Power Automate flows.

Solution: For any write operation that Workshop handled through an Ontology Action, create a Power Automate flow. This provides the same separation of concerns: the app handles UI, the flow handles business logic. The CSA-in-a-Box flows at portal/powerapps/flows/ demonstrate this pattern for five common operations.

Pitfall 5: Not planning for map widget complexity¶

Problem: Teams underestimate the effort required to migrate Workshop map widgets. Workshop maps are a single widget with built-in clustering, popups, and Ontology binding. Azure Maps requires more assembly.

Solution: For analytical maps (colored markers on a dashboard), use the Azure Maps Power BI visual — this is a single visual with no custom code. For interactive maps (drawing, routing, real-time tracking), budget 2-4 weeks for a custom React component using the Azure Maps SDK. See Section 7 for detailed guidance.

Pitfall 6: Overlooking PCF for hybrid scenarios¶

Problem: Teams face a binary choice between Power Apps (limited customization) and full React apps (high maintenance). They miss the middle ground.

Solution: Power Apps Component Framework (PCF) allows React-based custom components to run inside Power Apps canvas and model-driven apps. This is the equivalent of Foundry's Custom Workshop Widgets. Build complex UI components (interactive charts, custom maps, specialized editors) as PCF components and embed them in Power Apps for the best of both worlds.

Pitfall 7: Consumer Mode to Power Pages scope creep¶

Problem: Foundry Consumer Mode apps are typically simple (read-only dashboards, filtered views). Teams attempt to migrate these as full Power Pages portals with complex authentication and content management, dramatically increasing scope.

Solution: Evaluate each Consumer Mode app independently. If it is a read-only dashboard, a Power BI Publish to Web link may be sufficient (for non-sensitive data) or a Power BI Embedded report in a minimal Power Pages site. Only build a full Power Pages portal when the external app requires data entry, authentication, or content management.

Migration complexity estimator¶

Use this table to estimate effort for migrating individual Foundry applications:

Next steps¶

1. Inventory your Foundry applications — catalog every Workshop app, Slate app, and OSDK integration with their widget counts, action counts, and user counts
2. Classify each app using the migration complexity estimator above
3. Start with a high-value, low-complexity app — a simple dashboard or approval workflow — to build team confidence
4. Deploy the CSA-in-a-Box portal (portal/powerapps/ and portal/react-webapp/) as a reference implementation
5. Train your team on Power Apps and Power Automate using Microsoft Learn and the CSA-in-a-Box examples
6. Migrate incrementally — one app at a time, validating with end users before decommissioning the Foundry equivalent

For the overall migration plan, see the Migration Playbook. For ontology migration (which must precede app migration), see Ontology Migration. For AI capabilities, see AI & AIP Migration.

Last updated: 2026-04-30 Maintainers: CSA-in-a-Box core team