Before an ERP upgrade, map the estate

Before approving an ERP upgrade budget, ask what the proposal actually includes. A Business Central release label can identify the product without describing every component that runs the business.

The useful starting point is an estate manifest: a documented map of the installed components, data and dependencies. It turns “upgrade Business Central” into a scope the technical team and the business can both examine.

One name does not describe the whole application

Microsoft distinguishes a platform update from an application update. Changing the platform does not, by itself, update the application. Application updates involve extension versions, schema synchronisation and affected data.

The database must stay in the picture. Business Central stores application metadata and business data; single-tenant and multitenant deployments organise those responsibilities differently. The film shows logical roles, not a requirement for a separate physical server for every box.

The planning map

For this field note, use these five views as a planning checklist. They are not an automatic Microsoft compatibility test:

• Platform: record the exact installed build and deployment model.
• Application: record application and extension versions, including custom behaviour and third-party dependencies.
• Data: identify databases, companies, localisation requirements and the data that must be retained.
• Integrations: identify connected applications, interfaces and their owners.
• Acceptance: name the business operations that must still work and the people who will validate them.

Why the scope matters to the business

For the CTO, the manifest makes dependencies and missing evidence visible. For the CFO, it helps distinguish the work included in a proposal from assumptions still waiting to be resolved. It does not produce a reliable cost or cutover estimate on its own.

Consider an illustrative case: the platform has been updated, while an application extension still needs a separate assessment. Calling the whole estate “upgraded” conceals an unresolved piece of work. Record the component evidence instead.

Three checks before approving the route

• Baseline: document the actual source estate rather than relying on the product name.
• Route: assess the supported source-to-target procedure, customisations and data scope against current documentation.
• Proof: agree a rehearsal, representative business validation and a named acceptance owner before production change.

Use the map to challenge the proposal

Treat an unknown as a visible assessment task, not an empty space that silently becomes a promise. For example, if nobody owns the integration inventory, assign that work before accepting a claim that the interfaces are included. This is a proposed planning practice, not a statement about an actual customer estate.

Keep the map connected to the commercial conversation. Ask the delivery team to explain which components their estimate covers, which dependencies need separate investigation and who accepts each business result. A useful manifest can reveal questions that change the scope; it cannot prove the answers by itself. Preserve those unresolved questions in the decision record.

Keep the boundary clear

This example concerns modern Business Central on-premises. Legacy NAV C/AL and Business Central online have different upgrade paths and operating responsibilities. The version-27 document below illustrates the component distinction; it is not a recommendation to select that release. A completed inventory is preparation for an assessment, not proof of compatibility or an approved upgrade.