14.3 Exporting, Importing, Upgrading & Patches

Exporting, Importing, Upgrading & Patches

Deploying changes smoothly between development, testing, and production environments without causing business interruption or leaving obsolete schema behind is the cornerstone of enterprise Application Lifecycle Management. Microsoft Dataverse provides robust mechanisms for packaging, segmenting, upgrading, and patching solutions. On the PL-200 exam, you must understand how solution export packages are constructed, how to use Solution Segmentation, the exact behavior of Update vs. Stage for Upgrade vs. Upgrade, and how to maintain live systems using Solution Patches and Solution Cloning.

---

1. Solution Export & Packaging Mechanics

When a solution is exported from Dataverse, the platform bundles its metadata into a compressed ZIP file containing standardized XML and resource files:

+-----------------------------------------------------------------------------+
|                        SOLUTION ZIP PACKAGE STRUCTURE                       |
|                                                                             |
|   solution.zip                                                              |
|   |-- solution.xml          (Solution manifest, publisher, version, deps)   |
|   |-- customizations.xml    (Schema, entities, forms, views, site maps)     |
|   |-- [Content_Types].xml   (MIME types for package content)                |
|   |-- CanvasApps/           (Extracted .msapp binaries and Power Fx code)   |
|   |-- Workflows/            (Cloud flow and workflow JSON definitions)      |
|   `-- WebResources/         (JavaScript, PNG, SVG, CSS script files)        |
+-----------------------------------------------------------------------------+

Export Configurations

• Export as Unmanaged: Generates an unmanaged ZIP package. Used when transferring work between sandbox environments or unpacking components with the Power Platform CLI (pac solution unpack) to commit raw XML and code files into a Git source repository.
• Export as Managed: Compiles and generates a managed ZIP package. Used for releasing validated builds to Test, QA, and Production environments.
• Export Settings: Prior to export, makers can configure system settings to be bundled with the solution, including General settings, Sales settings, Email tracking, and Auto-numbering prefixes.

---

2. Solution Segmentation vs. Full Inclusion

In early versions of Dynamics CRM, adding a table to a solution automatically included the entire table definition—every column, form, view, chart, and relationship. When multiple teams deployed solutions, they constantly overwrote each other's form layouts and metadata.

Solution Segmentation allows consultants to include only the specific subcomponents that were created or modified:

+-----------------------------------------------------------------------------------+
|                     SOLUTION SEGMENTATION ARCHITECTURE                            |
|                                                                                   |
|  [UNSEGMENTED APPROACH (Anti-Pattern)]         [SEGMENTED APPROACH (Best Practice)]|
|  +-----------------------------------+         +-----------------------------------+|
|  | Table: 'Account'                  |         | Table: 'Account'                  ||
|  | - Include all components: [YES]   |         | - Include all components: [NO]    ||
|  | - Include entity metadata: [YES]  |         | - Include entity metadata: [NO]   ||
|  |                                   |         |                                   ||
|  | Includes:                         |         | Selected Subcomponents ONLY:      ||
|  | * All 150+ columns                |         | * Column: contoso_accounttier     ||
|  | * All 12 Main Forms               |         | * Form: Account Custom Main Form  ||
|  | * All 25 System Views             |         |                                   ||
|  |                                   |         | (Leaves all other forms, views,   ||
|  | (Overwrites changes made by other |         |  and columns completely untouched)|||
|  |  teams on Account forms!)         |         +-----------------------------------+|
|  +-----------------------------------+                                             |
+-----------------------------------------------------------------------------------+

Rules for Solution Segmentation

1. Uncheck 'Include all components': When adding an existing table (e.g., Account, Contact), never check Include all components unless you intend to own and overwrite the entire table architecture.
2. Uncheck 'Include entity metadata': Prevents overriding global table properties (such as Auditing, Notes, Activities, or Offline sync settings) in downstream environments.
3. Select Specific Assets: Add only the newly created columns, the specific modified form, or the single system view required for the feature.

---

3. Solution Import Modes: Update vs. Stage for Upgrade vs. Upgrade

When deploying a new version of a managed solution into a target environment, the import engine provides three operational modes:

+-----------------------------------------------------------------------------------+
|                         SOLUTION IMPORT MODES COMPARISON                          |
|                                                                                   |
|  [1. UPDATE (In-Place)]                                                           |
|  - Installs changes immediately into the existing solution layer.                 |
|  - Overwrites modified components.                                                |
|  *** DOES NOT DELETE OBSOLETE COMPONENTS REMOVED FROM SOURCE SOLUTION! ***       |
|                                                                                   |
|  [2. STAGE FOR UPGRADE (Holding Layer)]                                           |
|  - Imports new solution as a temporary holding layer: '[SolutionName]_Upgrade'    |
|  - Existing solution remains active and unchanged during import.                 |
|  - Allows automated health checks and verification before committing.            |
|  - Transition completed via: 'Apply Solution Upgrade'                             |
|                                                                                   |
|  [3. UPGRADE (Direct / Applied)]                                                  |
|  - Replaces the existing solution layer with the new version.                     |
|  - Merges all intermediate patches into a single unified layer.                   |
|  *** AUTOMATICALLY DELETES COMPONENTS DELETED FROM THE SOURCE SOLUTION! ***      |
+-----------------------------------------------------------------------------------+

Detailed Breakdown of Import Modes

1. Update (In-Place Update)

• How it Works: Updates existing components and adds newly created components directly into the current solution layer.
• Component Deletion: Non-destructive. If you deleted a column, form, or cloud flow from the solution in Development, importing with Update will NOT delete that obsolete component from the target environment. The deprecated component remains orphaned in the target environment.
• Use Case: Small, additive updates where no components were removed.

2. Stage for Upgrade

• How it Works: Imports the solution as a separate, temporary holding layer named [SolutionName]_Upgrade. The original base solution remains live and uninterrupted.
• Zero-Downtime Validation: Administrators and CI/CD pipelines can validate the health of the deployment while the holding layer is staged.
• Completion: The upgrade is finalized by selecting Apply Solution Upgrade (either manually in the UI or via the Apply-AdminPowerAppSolutionUpgrade pipeline command).

3. Upgrade (Direct Upgrade / Apply Solution Upgrade)

• How it Works: The new solution version fully replaces the old solution. Dataverse performs a comprehensive delta reconciliation.
• Component Deletion: Deletes all components that were removed from the source solution. If a deprecated column or flow was removed from the source development package, Dataverse cleanly purges it from the target environment.
• Patch Consolidation: Consolidates all previously installed patches into the new base solution layer.

[!IMPORTANT] How to Delete Deprecated Components in ALM: If an enterprise requirement states that obsolete columns, deprecated forms, or decommissioned flows must be removed from Production during deployment, you MUST use the Upgrade (or Stage for Upgrade followed by Apply Solution Upgrade) method. An Update will never delete components.

4. Solution Patches & Solution Cloning

In agile enterprise environments, deploying a massive 200MB solution containing hundreds of components for a single two-line bug fix is inefficient and risky. Dataverse provides Solution Patches to deliver lightweight, targeted incremental updates.

+-----------------------------------------------------------------------------------+
|                         SOLUTION PATCHING & CLONING LIFECYCLE                     |
|                                                                                   |
|  [BASE SOLUTION v1.0.0.0]                                                         |
|  - Contains Core Tables, Forms, Flows (Base Layer)                                |
|  - Locked while patches are active                                                |
|                                                                                   |
|          +---> [PATCH 1: v1.0.1.0] (Bug fix on Invoice Form)                      |
|          |     - Exports in seconds (Contains ONLY Invoice Form)                  |
|          |                                                                        |
|          +---> [PATCH 2: v1.0.2.0] (New Hotfix Column on Account)                 |
|                - Exports in seconds (Contains ONLY new Column)                    |
|                                                                                   |
|                                        |                                          |
|                                        v (Execute 'Clone Solution' in Dev)        |
|                                                                                   |
|  [UNIFIED BASE SOLUTION v2.0.0.0 (Cloned & Rolled Up)]                            |
|  - Merges Base Solution + Patch 1 + Patch 2 into a single clean base package      |
|  - Increments Major/Minor version digit                                           |
|  - Ready for fresh Managed 'Upgrade' deployment to Production                     |
+-----------------------------------------------------------------------------------+

Solution Patch Rules & Lifecycle

1. Version Numbering Convention:
   • Dataverse solutions follow standard versioning: Major . Minor . Build . Revision (e.g., 1.0.0.0).
   • When creating a patch, only the Build or Revision digits can increment (e.g., 1.0.1.0 or 1.0.0.1). Major and Minor digits cannot change.
2. Patch Content: A patch contains only the specific components or subcomponents that were added or modified (the delta). It depends strictly on its parent base solution.
3. Parent Solution Locking: While an active patch exists in the development environment, the parent base solution is locked and cannot be edited directly. All new customizations must be added to the patch.
4. Downstream Deployment: Patches are exported as Managed packages and imported into target environments where they layer directly on top of the parent managed solution.

Cloning a Solution (Patch Rollup)

Over time, managing 10 separate patches creates operational overhead. When preparing for a major release:

• In the development environment, select the parent solution and click Clone Solution.
• Dataverse rolls up the base solution and all active patches into a single, unified new solution package.
• The consultant specifies a new Major or Minor version number (e.g., 2.0.0.0 or 1.1.0.0).
• All previous patch containers are automatically deleted in development.
• When this new base solution is deployed to Production as an Upgrade, Dataverse replaces the old base solution, deletes the obsolete patches, and establishes a single consolidated managed layer.