Power Platform ALM
SharePoint List Mapping — DEV to PROD Deployment Guide
Using Environment Variables & Power Platform Solutions
1. Context & Problem Statement
When deploying a Power App backed by SharePoint lists from a DEV environment to PROD, two major issues arise systematically.
1.1 The Mapping Problem
Every time the Power App is deployed from DEV to PROD, all connector references inside the app and associated Power Automate flows remain pointed at the DEV SharePoint site and DEV lists. With 100+ SharePoint lists per deployment, manually remapping each connection is not feasible — it introduces human error, costs significant time, and is not reproducible.
1.2 The Data Preservation Problem
The PROD environment contains live data in its SharePoint lists that must never be overwritten. A full ShareGate migration would overwrite existing data. Only the schema changes (new columns, new lists) from DEV need to be propagated to PROD — not the data.
| Key Principle The solution is not to migrate lists — it is to make the Power App aware of its target environment at deployment time, using Environment Variables as a mapping layer between the app and its data sources. |
2. Why ShareGate Does Not Solve This Problem
ShareGate is an excellent tool for one-shot site migrations. However it is not designed for repeated DEV-to-PROD deployments with the following constraints:
| Issue | ShareGate Behavior | Impact |
| List IDs (GUIDs) | New GUID generated on every migration | App connections break |
| Existing PROD data | Overwritten or duplicated | Data loss risk |
| Repeated deployments | Not designed for delta deployments | Cannot be automated |
| App connector mapping | Not handled by ShareGate | Manual remapping required |
Important: SharePoint list IDs (GUIDs) are unique per site collection and cannot be forced to a specific value. Microsoft does not provide a mechanism to preserve list GUIDs during migration. This is by design.
3. Recommended Solution: Power Platform Solutions + Environment Variables
3.1 Architecture Overview
The recommended approach is the Microsoft-standard ALM (Application Lifecycle Management) pattern for Power Platform. It uses two key components:
- Power Platform Solutions — packages the app, flows, and configuration as a deployable unit
- Environment Variables (Data Source type) — stores the SharePoint site URL and list references separately from the app logic
The app never references SharePoint lists directly. It references Environment Variables which point to the correct lists for each environment.
| DEV Environment | PROD Environment |
| env_SP_SiteURL = https://tenant.sharepoint.com/sites/DEV | env_SP_SiteURL = https://tenant.sharepoint.com/sites/PROD |
| env_SP_List_Customers = Customers_DEV | env_SP_List_Customers = Customers |
| env_SP_List_Orders = Orders_DEV | env_SP_List_Orders = Orders |
| … (100 lists) | … (same 100 lists, PROD names) |
| Microsoft Reference Data source environment variables store parameters that are required by one or more actions in the connector. For example, a SharePoint Online connection does not store any information about sites, lists, or document libraries. Therefore calling the connector requires both a valid connection and additional parameters. — Microsoft Learn |
3.2 How Environment Variables Work with SharePoint
When you connect a Canvas App to a SharePoint list, Power Platform automatically creates two environment variables:
- One for the SharePoint Site URL
- One for the List ID / table name
These variables are stored in the Solution and can be given different values in each target environment at import time — without modifying the app itself.
| Key Behavior When you save the data source, your app is connected to SharePoint via two related environment variables: one to hold the site URL and one to hold the list ID. At import time in a new environment, you simply provide new values for these variables. No need to modify or republish the app. |
4. Step-by-Step Implementation
Step 1 — Package the Power App in a Solution
- Go to Power Apps (make.powerapps.com)
- Navigate to Solutions → New Solution
- Name the solution (e.g., MyApp_Solution) and set a publisher prefix
- Add the existing Power App to the solution: Add existing → App → Canvas app
- Add all associated Power Automate flows
- Verify that SharePoint connections appear as Connection References in the solution
Step 2 — Verify Environment Variables Are Created
When a Canvas App connects to SharePoint inside a solution, environment variables are created automatically. Verify:
- In the solution, click on Environment Variables
- You should see one variable per SharePoint site (Site URL type) and one per list
- If variables are missing: open the app, remove and re-add each SharePoint data source — variables are created on save
| Best Practice Let the app create the environment variables automatically by connecting to data sources inside the solution. Do not create them manually — the auto-created variables are correctly typed (Data Source) and linked to the connector. |
Step 3 — Remove Current Values Before Export
Environment variable values must NOT be exported with the solution. They should be set fresh in each target environment.
- In the solution, select each SharePoint environment variable
- Click the ellipsis (…) → Remove from this solution (for the Current Value only)
- The Default Value and variable definition remain — only the current value is removed
Step 4 — Export the Solution
- Solution → Export → select Managed (for PROD) or Unmanaged (for DEV/TEST)
- Download the .zip file
Step 5 — Import into PROD with New Environment Variable Values
- In the PROD Power Apps environment: Solutions → Import solution
- Upload the .zip file
- At the Environment Variables step: provide PROD values for each variable
- Site URL: https://tenant.sharepoint.com/sites/PROD
- List names: exact PROD list names
- At the Connection References step: select or create PROD connections
- Complete the import — the app is now connected to PROD lists
| Result Once environment variable values are set in PROD, subsequent deployments (upgrades) will not ask for values again unless new variables are introduced. You only configure once per new list or site. |
5. Propagating Schema Changes (New Columns / New Lists) to PROD
For schema changes (adding columns, new lists) without overwriting PROD data, use PnP PowerShell templates. This exports only the structure from DEV and applies it to PROD — data is preserved.
5.1 Export Schema from DEV
| # Export list schema from DEV (structure only, no data) Get-PnPSiteTemplate -Out template.xml \ -ListsToExtract ‘List1′,’List2′,’List3’ \ -Handlers Lists # Apply schema to PROD (data is preserved) Connect-PnPOnline -Url ‘https://tenant.sharepoint.com/sites/PROD’ -Interactive Invoke-PnPSiteTemplate -Path template.xml |
The -Handlers Lists flag extracts only list schemas (columns, views, content types) — no list items are exported or overwritten.
6. Complete Deployment Workflow DEV → PROD
| # | Action | Tool | Who |
| 1 | Export list schema changes from DEV | PnP PowerShell | Developer |
| 2 | Apply schema to PROD (structure only, data preserved) | PnP PowerShell | Developer |
| 3 | Export Power Platform Solution (Managed) | Power Apps Portal | Developer |
| 4 | Import Solution into PROD environment | Power Apps Portal | Admin |
| 5 | Set Environment Variable values for PROD at import | Power Apps Portal | Admin |
| 6 | Set Connection References to PROD connections | Power Apps Portal | Admin |
| 7 | Verify app functionality in PROD | Browser / Teams | Tester |
From the second deployment onwards: steps 5 and 6 are skipped if no new lists or sites have been added. The environment variable values already set in PROD are reused automatically.
7. Recommended Naming Convention for Environment Variables
With 100+ lists, a consistent naming convention is critical for maintainability.
| Variable Type | Naming Pattern | Example |
| SharePoint Site URL | env_SP_SiteURL_[AppName] | env_SP_SiteURL_MyApp |
| SharePoint List | env_SP_List_[ListName] | env_SP_List_Customers |
| SharePoint Library | env_SP_Lib_[LibraryName] | env_SP_Lib_Documents |
8. Microsoft Official References
| Topic | Microsoft Learn URL |
| Environment Variables — Overview | learn.microsoft.com — Use environment variables in Power Platform solutions |
| Environment Variables — FAQ | learn.microsoft.com — Environment variables FAQ |
| ALM — Pre-populate Connection References | learn.microsoft.com — Pre-populate connection references and environment variables |
| Data Source Environment Variables — Blog | Microsoft Power Platform Blog — Announcing data source environment variables |
| ALM Deployment Configuration Guide | learn.microsoft.com — Deployment configuration guide |
9. Summary
| The Right Approach in 3 Points 1. Package the Power App in a Power Platform Solution with Connection References and Environment Variables. 2. Use PnP PowerShell to propagate schema changes (new lists/columns) to PROD — data is never overwritten. 3. At each deployment, only provide new values for new environment variables. Existing PROD variables are reused automatically. |
This approach eliminates manual remapping, is repeatable and automatable, preserves PROD data at all times, and follows the Microsoft recommended ALM standard for Power Platform solutions backed by SharePoint.