Comparing Two Solution Versions Before Deployment

Before every deployment the same question comes up: what is actually different from last time? Often nobody knows the full answer. The change note (if it is kept at all) lists the features that were built. It does not list the column that dropped out of the solution as a side effect of some cleanup. Yet the answer is fully available, in the two solution exports: the old and the new solution.

This article goes through the changes that can do real damage during the import, and shows where to find them in the export. At the end there is a checklist you can do yourself.

Removed columns: the point with data loss

When a managed solution is installed as an upgrade, Dataverse reconciles. All components of the previous version that are missing in the new one are deleted (Microsoft Learn: Update or upgrade a solution). For a column this means: it disappears, and all the data in it with it. For a table, the records go. Why this so often happens unintentionally is described in detail in Risks in solution upgrades.

For the comparison this means: the list of removed tables and columns is the most important list of all. Whoever has not seen it before the import may delete production data that is still needed. If the solution is installed unmanaged instead, the columns stay. No data is lost then, but nobody maintains the columns anymore, and they turn into Dataverse data junk.

There is also a case inside the package itself. A column is missing in the new version but still appears on a form or in a view of the same version. According to Microsoft, an upgrade removes a component only when nothing in the target environment depends on it anymore (Microsoft Learn: Update or upgrade a solution). So whether the column stays, or the upgrade gets stuck on the dependency, depends on where the reference sits. You would rather know both before the maintenance window than during it.

Changed columns: other type, shorter or stricter

Not only what is missing is dangerous. Four changes to existing columns deserve a closer look.

Data type. After saving, the data type of a column can no longer be changed, except for text columns that become autonumber columns (Microsoft Learn: Create and edit columns). If the comparison still shows a new type, the column was usually deleted in development and recreated under the same name. In the target environment that does not work without data loss. The clean detour: create a new column, transfer the data, and remove the old column only in a later release.

Maximum length. Microsoft is cautious here: the maximum of a text column can be increased, but should not be lowered. Longer values may already exist in the system. The import itself stays inconspicuous. The consequences come later, when records with values that are too long are saved or an interface writes long values. So only the direction matters: longer is harmless, and shorter needs checking.

New required fields. "Business required" is a rule of the user interface. Model-driven apps enforce it. The Dataverse API, however, returns no error when the value is missing (Microsoft Learn: Column definitions). So interfaces mostly keep running. The users are hit: whoever opens an old record without this value and changes something has to fill the new required field before they can save.

Removed option values. A choice column translates the text into a preconfigured number. That number is stored, and not the label, as you might think (Microsoft Learn: Create a choice). If a value drops out of the list, records still carry it, but it is no longer available for selection. Views, charts and reports that filter on exactly this value should therefore be checked. The safe way: before the import, switch the affected records to a remaining value.

Permissions: replaced, not added

Security roles in a managed solution behave differently than many expect. For your own roles, the import replaces the privileges instead of merging them. Whatever someone changed on the role in the target environment outside the solution is gone afterwards (Microsoft Learn: Understand how managed solutions are merged).

For the comparison this means: every role with changed privileges is a question for the person responsible, in two directions. Extended privileges (for example one level higher from business unit to organization, or a new delete privilege) let users see or change more after the import. Restricted privileges lead to error messages in processes that worked before. Both are in the export, privilege by privilege and table by table. How to go through the role inventory in general is covered in Reviewing security roles in Dynamics 365.

Automation that drops out or is added

A flow or a classic workflow that is missing in the new version is deleted by the upgrade, just like a column. No data disappears with it. But what it used to do quietly no longer happens after the import. Often only the business department notices, weeks later. Conversely, newly activated flows and plug-in steps work with real data from the very first moment.

For plug-in steps it is also worth looking at changed registrations: a different message, a different stage, synchronous instead of asynchronous, or a changed column filter. The code is the same, but it runs at a different time.

Checklist to do yourself

1. Export alike: both versions managed, or both unmanaged. The version number of the new one must be higher, otherwise it cannot be told apart from the old state later.

2. List removed tables and columns. For each, clarify whether data sits in it and who decided that it may go.

3. Search the forms and views of the new version for references to removed columns, including in filters and sort orders.

4. Go through changed columns: data type, maximum length (only shorter is critical), required level and removed option values.

5. Roles: have the person responsible confirm every changed privilege with its level, separated into more and fewer privileges.

6. Compare "MissingDependencies" of the new version with the old one, and hold new entries against the target environment.

7. New connection references and environment variables: clarify the connection and the value for the target environment before the import.

8. Go through automation that drops out and automation that is new (flows, workflows, plug-in steps) with the business department.

Only then comes the decision between upgrade and update. If it is still open whether the data of a removed column is needed, the update is the careful way, and the cleanup moves to the next version. And every upgrade needs a backup of the target environment first, because there is no undo function.

With D365 Audit I built, among other things, a comparison of two solution exports from exactly these points. The checklist works just as well without a tool.