Customization XML to solutions to pipelines: packaging from CRM 3.0 to Dataverse

Answer first

Every era moved customizations as a file, but what an import did to the components already in the target changed a lot:

Era	What you moved	What an import did to existing components
CRM 3.0	One exported XML file of customizations	Overwrote that entity’s earlier customizations
CRM 4.0	A customization file, for all or selected entities	Mostly overwrote by name; a few collisions raised errors, and custom security roles merged
CRM 2011	Solutions, unmanaged or managed	Unmanaged overwrote; managed went into layers. Neither could delete a component
CRM 2013 to 2015	Solutions, optionally targeted at an older version	A solution from a newer version wouldn’t install into an older one
CRM 2016 (8.0)	Solutions and patches	Patches could add or update, never remove; an upgrade removed
Dataverse	Solutions, deployed by hand, by pipelines or by CI/CD	Upgrade deletes components the new version no longer has; update doesn’t

Why removing one field breaks something else. Since CRM 2011 the platform has tracked dependencies between components. It won’t delete a field that a form, view, workflow or another solution still uses. When uninstalling a managed solution does remove a custom field, the data in it goes too. And a field you thought you’d removed may still be there, because an update, a patch or a 2011 solution never deleted anything.

Sources: the CRM 3.0 Help, the CRM 4.0 SDK, the CRM 2011 and 2016 SDKs, archived CRM 2013 documentation, and Microsoft’s current Power Platform ALM documentation. Each section below names its own.

Why a component can’t be deleted

Sources: Microsoft’s “Dependency tracking for solution components” and “Removing dependencies overview”. The same dependency rules appear in the CRM 2011 SDK.

• Dependencies are tracked automatically. Every operation on a component recalculates them, and the platform:
  • blocks deleting a component that another component depends on;
  • warns on export when required components are missing;
  • fails an import when required components are neither in the solution nor in the target.
• A managed solution can only depend on managed components.
• Microsoft’s own example: if a lookup column is on a form, you can’t delete the table on the other side of the relationship until you remove the lookup from the form and publish it.
• Unmanaged dependencies are fixed on the component, not in a solution: remove the column from the form in the form designer, then save and publish.
• Managed dependencies are fixed with a new solution version. Find the topmost solution layer of the dependent component, build a version of that solution without the reference, upgrade it in the target, and retry.
• Dependencies are only calculated between the topmost layers. Removing one can reveal the next layer down, so work from the top of the stack to the bottom.
• Uninstalling a managed solution deletes data. Data in the solution’s custom tables, and in its custom columns on other tables, is lost. The CRM 2011 SDK gave the same warning.

Layers: which definition wins

Sources: Microsoft’s “Solution layers” and “Removing dependencies overview”. The 2011 behaviour is from the CRM 2011 SDK.

• One unmanaged layer, many managed layers. All unmanaged solutions and direct customizations share a single unmanaged layer on top. Managed solutions stack in install order above the system layer, so a later one can customize an earlier one.
• Most components are “top wins”. Only model-driven apps, forms and the site map are merged. For everything else, the top layer decides runtime behaviour.
• Unmanaged changes in test or production override managed ones. The unmanaged layer sits on top. The Remove Active Customization feature removes it.
• Publishers matter when uninstalling. Uninstalling the base solution deletes the component, and it’s blocked while a solution from a different publisher extends it. If another solution from the same publisher also holds a layer, the component stays.
• In CRM 2011, importing a newer copy of a managed solution offered Maintain customizations (recommended) or Overwrite customizations. Keeping unmanaged customizations meant some of the update wouldn’t take effect.
• How forms merged in 2011: a managed solution carried only its differences from the original FormXML. Fields added to an existing section appeared at the end of it, which is why the SDK recommended putting new fields in new tabs or sections.

Update, upgrade or patch

Sources: Microsoft’s “Upgrade or update a solution”, “Create and update solutions”, “Solution concepts” and “Solution layers”.

Import choice	Deletes components the new version dropped?	Notes
Upgrade	Yes	The default. Rolls up earlier patches in the same step
Stage for upgrade	Yes, when you apply the upgrade	Old and new versions installed side by side, for data migration first; shows as a solution ending _Upgrade
Update	No	Fastest, but the target can drift from the source
Patch	No	Adds or updates only. Microsoft doesn’t recommend patches or cloning

• A patch locks its parent. While patches exist, the parent solution can’t be changed or exported.
• Deleting a parent deletes its patches, in one transaction.
• Increment the version when exporting the managed solution that updates an installed one.

Other controls that decide what an import changes

• Segment tables. Add only the table components you changed. Include all objects is for tables the target doesn’t have yet. Unchanged components add a layer, and existing customizations below it in the target might become inactive. Source: “Use table segmentation in solutions”.
• Managed properties lock what others can customize after a managed install. You set them while the solution is unmanaged, and only an update from the original publisher changes them. Microsoft says they aren’t a licensing or DRM mechanism. Sources: “Managed properties” and the CRM 2011 SDK.
• Environment variables and connection references carry the values that differ per environment. Pipelines ask for them before deploying. Sources: “Environment variables for Power Platform overview” and “Overview of pipelines in Power Platform”.
• Solutions don’t carry table data. Neither do pipelines. Source: “Overview of pipelines in Power Platform”.

How packaging got here

CRM 3.0: one XML file

Sources: the CRM 3.0 application Help and server readme. Details on CRM 3.0.

• Customizations were exported and imported as XML, including the Site Map, which new entities needed in order to appear.
• Importing an entity overwrote its earlier customizations in the target.
• Files over about 7.5 MB hit the ASP.NET request limit unless maxRequestLength was raised.

CRM 4.0: the customization file and collision rules

Sources: the CRM 4.0 SDK and application Help. Details on CRM 4.0.

• Export All Customizations or selected entities, from Settings, Customization. The same file came from the export messages in the web services.

• The file carried more than entities: entity maps and relationships, isv.config, the Site Map, templates, organization settings, security roles and workflows. The System Administrator role wasn’t exported.

• Collisions followed fixed rules:

  On import	Result
  Forms, views, templates or isv.config with the same name	Overwritten
  Properties changeable in the web application	Overwritten
  Properties not changeable in the web application	Error
  Custom security role with the same ID	Merged
  The System Administrator role	Skipped

• Relationships travelled only with both entities, exported and imported together.

• Changes made outside the SDK and the customization tools weren’t supported and weren’t preserved through updates or upgrades.

CRM 2011: solutions

Source: the CRM 2011 SDK. Details on CRM 2011.

• Solutions arrived, unmanaged and managed. The SDK called an unmanaged solution roughly what 4.0 customizations were, except that a component could now belong to any number of groups.
• Solutions could add or overwrite components, but not delete them.
• Importing an unmanaged solution overwrote existing definitions with no undo, “the same behavior used in” CRM 4.0.
• The default solution, everything in Customize the System, could be exported unmanaged but never managed.
• Publishers brought the customization prefix (two to eight characters, not starting with mscrm) and an option value prefix between 10,000 and 99,999. Managed solutions from the same publisher could update each other.
• Maintaining a managed solution: release a new version from the original unmanaged source, or a smaller update solution under the same publisher. The SDK warned that uninstalling and reinstalling was “practically never an option”, because data is lost.
• A minimum version could be set by editing minimumversion in solution.xml, which defaulted to 5.0.0.0.
• SolutionPackager appeared in the SDK for Update Rollup 10, to split solution files for source control.

CRM 2013 to 2015: version targeting

Sources: archived CRM 2013 documentation and the CRM 2016 SDK. Details on CRM 2013 and CRM 2015.

• Solutions stopped installing into older versions, including older minor versions.
• Export could target an older version: 6.0 from 2013 Service Pack 1, and 7.0 from CRM Online 2015 Update 1. Components are removed, modified or replaced based on each component’s IntroducedVersion. The exported zip names the target, for example _target_CRM_7.0, and includes a filteredcomponents.xml report.
• Solutions could be imported asynchronously with ExecuteAsyncRequest, and the Package Deployer deployed several solutions and data files as one package.

CRM 2016 (8.0): patches, and removal by upgrade

Source: the CRM 2016 SDK. Details on CRM 2016.

• Patches let you ship parts of a table instead of the table with all its assets. They’re solution records with a ParentSolutionId, created with CloneAsPatchRequest.
• A patch keeps its parent’s major and minor version and must match its parent’s package type: a managed patch goes on a managed parent.
• To remove components, perform an upgrade, in the SDK’s words; patches can’t remove.

Dataverse: source control and pipelines

Sources: Microsoft’s current Power Platform ALM documentation.

• Unmanaged solutions are the source; managed solutions are build artifacts. Microsoft says to check exported unmanaged solutions into source control. A managed solution can’t be imported into the environment that holds its unmanaged original.

• SolutionPackager is no longer the recommended tool. Its capabilities are in the Power Platform CLI: pac solution with verbs such as unpack, pack, clone and sync.

• Pipelines deploy from inside the product:

  • they check dependencies before deploying;
  • they ask for connections and environment variables up front;
  • they support approvals through delegated deployments.

  They can’t deploy to another tenant; Microsoft points to Azure DevOps or GitHub for that.

• Managed environments for pipeline targets: Microsoft said it would start enabling them for pipeline targets from February 2026.

• A solution can be up to 95 MB.

If you find this

Sources: as for each section above. The “Likely means” column is this site’s reading of those sources, not a diagnosis.

You find	Likely means
A customization export with no solution.xml beside it	A CRM 3.0 or 4.0 export, from before solutions
Fields you removed in development still in production	An update or patch was imported, not an upgrade
A solution whose name ends _Upgrade	A staged upgrade that hasn’t been applied
A solution record with ParentSolutionId set	A patch
filteredcomponents.xml in a solution zip	The zip was exported for an older version, and components were changed or left out
Behaviour in production that doesn’t match the managed solution	An unmanaged layer on top; check the solution layers