Chapter 16 · Upgrades

Technical reference · Chapter 16

Upgrades

Purpose

Upgrade Analysis is the capability that supports the Upgrades pillar of ConfigCompare.

The Upgrades pillar covers any change to the application itself, including Microsoft One Version updates, releases of internal development, new releases of ISV solutions, and AX 2012 to D365 migration paths. Upgrade Analysis helps organisations understand the effect of these changes on configuration and application structure.

This chapter describes the pillar in practice, applying the concepts introduced in Chapters 03 to 10. The four pillars are introduced together in Chapter 02.

This chapter describes concepts and behaviour; step-by-step operating guidance sits outside this reference.

Two layers of upgrade analysis

Upgrade Analysis combines two comparisons, run against Snapshots captured before and after the upgrade:

Metadata (structural) analysis: a dedicated Snapshot and comparison mode that examines the structure and schema of all persisted application tables, identifying every structural change introduced by the update. This mode is specific to upgrade scenarios and is distinct from routine Configuration Comparison.
Configuration (data) analysis: a standard Configuration Comparison over the tables in the Configuration Catalogue, showing what happened to configured data through the upgrade.

Data is not compared across all application tables at upgrade time. The data layer applies to configuration tables, where the question “what did the upgrade write?” has governance meaning.

Configuration Upgrade Analysis

Configuration Upgrade Analysis compares configured environments before and after an upgrade.

Typical questions organisations ask include:

Did configuration survive the update?
Did mandatory defaults or features change?
Did settings change between pre-upgrade and post-upgrade baselines?
Are finance, tax, warehouse, production, or integration settings still aligned?
Do environment-specific settings still differ where they should, or has the upgrade left undesired Matches in place?
Are there Differences that require business sign-off?

Data initialisation

For configuration tables that receive new fields in an upgrade, the data layer shows whether the upgrade wrote values into existing records. Each affected table can be classified:

Inert: fields were added but no values written; every record remains at the field’s default (zero) value.
Active: the upgrade wrote non-default values into one or more records. These findings require explicit review.
Effective default: no values were written, but the field’s zero value is not operationally neutral (for example a default of “Warning” rather than “No”). If the associated feature is enabled by default, the behaviour is live from the first day of the upgrade without any administrator action.
Meaning change: the stored value is unchanged, but the label of the field, or the current label of the enumeration value it holds, has changed. A changed label can signal a changed meaning, so these findings deserve review even though no data moved.

Effective defaults are the least visible finding: no value was written and nothing was configured, yet behaviour changed.

Metadata Upgrade Analysis

Metadata Upgrade Analysis reviews structural changes in the D365 application introduced by Microsoft updates.

Unlike Configuration Comparison, which focuses on specific preselected tables and Data Entities, metadata analysis performs a full scan of every persisted table in the application, meaning every table that stores data rather than a temporary table, and identifies structural changes introduced by the update.

What metadata analysis identifies

Metadata analysis inventories and categorises every structural change:

New tables added
Removed tables
New fields (columns) added to existing tables
Removed fields from existing tables
Field property changes (data type, field length, enumerations)
Label changes
Row count changes across tables
Extended Data Type (EDT) changes affecting existing fields
Index modifications

Scope and focus

Configuration Comparison (ConfigCompare) answers the question organisations ask first: “Did our configuration survive the update?” It does so by comparing settings in preselected configuration tables.

Metadata analysis answers a broader question: “What structural changes did Microsoft introduce, and what might be affected?” It examines the entire application database schema to identify every structural change, enabling impact assessment across customisations, integrations, reporting, and business processes.

Risk identification

Metadata analysis identifies several categories of risk:

Breaking changes: removed fields or tables that will cause failures in custom code, Data Entities, or integrations.
Field length reductions: reduced field lengths do not silently truncate data; SQL Server would prevent the operation, or Microsoft handles the change through a pre-upgrade script. The required action is to query the affected table before upgrading production and resolve any values that exceed the new limit.
Functional impact: new defaults or configuration changes introduced by the update (for example, pricing parameters enabled by default) that may affect business processes.
Dependent system impact: changes to tables used by integrations, reporting systems, or ISV solutions.

Report structure and formats

Metadata analysis produces detailed tabular reports, typically HTML-based, that organise changes by:

Table-level categories: removed tables, new tables, tables with new fields, tables with modified fields, tables with removed fields, tables with changed labels, tables with changed data volumes.
Module organisation: Finance, Supply Chain Management, Retail, Projects, Human Resources, and other functional areas.
Field-level detail: for each change, the table name, field name, data type, field length, and human-readable labels.

Reports are suitable for:

Technical review by developers and architects
Functional team assessment of business process impact
Testing planning and regression test scoping
Integration and reporting impact assessment
Stakeholder communication and upgrade risk assessment

Typical metadata analysis questions

Typical questions organisations ask of metadata analysis include:

What new tables were added in this update?
Which tables had fields removed, and could this break existing code or integrations?
What field length reductions occurred, and do we have data exceeding the new limits?
What new defaults or mandatory parameters were introduced?
Which tables used by our integrations were modified?
What changes affect reports that query modified tables?
Do changes require ISV or third-party solution updates?
What areas require regression testing due to structural changes?
Which changes have business process implications requiring user validation?

Findings beyond published documentation

Structural findings can be cross-referenced against Microsoft’s published release documentation. Some changes map cleanly to announced features; others have no corresponding documentation at all.

These undocumented changes (new fields, removed fields, and changed definitions that shipped without being described) are findings only deterministic schema comparison can surface. They are reported factually: what is observable in the schema, noted as having no published documentation, without speculation about intent.

Microsoft One Version support

Microsoft Dynamics 365 Finance & Supply Chain Management follows a continuous update model. Organisations need to understand what changed and whether those changes affect their configuration, customisations, integrations, ISVs, reporting, or testing approach.

ConfigCompare supports this by capturing baselines before and after updates and comparing both configuration and metadata where appropriate.

Upgrade gates

ConfigCompare can support upgrade gates such as:

Pre-upgrade baseline capture.
Impact assessment.
Sandbox upgrade review.
Targeted regression planning.
UAT comparison.
Business sign-off.
Production update validation.
Hypercare monitoring.

Business outcomes

Outcomes typically sought from Upgrade Analysis include:

Reduced upgrade risk: understand structural changes before they cause problems.
Faster upgrade planning: identify impact areas early and accelerate test scoping.
Reduced upgrade costs: avoid post-upgrade surprises, field fixes, and remediation.
Customisation impact assessment: understand whether custom code needs updating.
Integration impact assessment: identify whether integrations are affected by schema changes.
Reporting impact assessment: determine whether reports need modification.
Informed testing strategy: focus regression testing on areas that actually changed.
Stakeholder confidence: demonstrate that the upgrade has been planned and validated.
Compliance assurance: document that changes have been reviewed and understood.

ConfigUpgrade component

The capabilities in this chapter are delivered by ConfigUpgrade, the platform component responsible for pre-upgrade and post-upgrade analysis (see Chapter 22: Licensing).