What to write down before a NAV to Business Central upgrade

Integrations

List every system that reads from the ERP or writes to it. For each one, record:

• The other system and what the data is.
• The direction: in, out, or both.
• The method: a direct database query, a web service, a file drop, or a person with a spreadsheet.
• The schedule and what triggers it.
• Where the code or configuration lives.

Look closely at the method. Integrations that read or write the NAV SQL database directly are the ones at high risk. Business Central online does not allow direct database access, so each of those must be rebuilt on an API or a web service.

Identity and service accounts

List every account that a system, not a person, uses to reach the ERP. For each one, record what uses it, what it is allowed to do, where its password or key is stored, and who can reset it.

The sign-in method often changes with the upgrade. Integrations that sign in with a Windows account or a stored user name and password must move to OAuth through Microsoft Entra ID, tied to your Microsoft 365 tenant. Business Central online stopped accepting web service access keys in 2022.

Scheduled jobs

Scheduled work hides in more than one place. Check each:

• The job queue inside the ERP.
• Windows Task Scheduler on the ERP server and on any server near it.
• SQL Server Agent jobs.
• Scripts on someone’s desktop that run when that person logs in.

For each job, record what it does, when it runs, what depends on it, and how anyone would know it failed. Jobs that live on the old server do not move by themselves. If the old server is switched off after the upgrade, they stop without an error. Job queue entries inside NAV carry over if the code they run is upgraded. Jobs scheduled outside it, in Windows Task Scheduler, SQL Server Agent, or a script, do not.

Bank files

Payment files, positive pay files, and bank statement imports deserve their own section. A mistake here costs money, not time.

For each bank and each file type, record:

• The format and which version of the bank’s specification it follows.
• What produces the file: a standard ERP function, a customization, or an outside tool.
• Where the file is written and how it reaches the bank.
• Who prepares it, who approves it, and who releases it.

Keep a sample of a current, accepted file for each type. After the upgrade, produce the same file from the test system and compare the two line by line.

Files written to a folder on the server need a second look. Business Central online has no server folder to write to, so the delivery step must change. Online, a file is downloaded through the browser or delivered through an API, SharePoint, or cloud storage.

Reports

List the reports people use, not the reports that exist. Ask each department what it opens daily, weekly, and at month end. For each one, record:

• Who uses it and what decision it supports.
• Where it runs: inside the ERP, in Excel with a data connection, or in a reporting tool.
• What it reads from.

Custom reports are converted along with the rest of the code, and their layouts often need fixes. Workbooks that query the database directly stop working online. Include printed documents such as invoices, checks, and labels.

An owner for each item

Every line on the list needs two names. The first is the business owner, who decides whether the item is still needed. The second is the technical owner, who can change it.

Where a name is missing, write "nobody". That is a finding, not a failure. An item with no owner is the one likely to break without notice.

What to do with the list

Give it to the ERP partner before the scope is fixed. Each item becomes one of four things: carried over as it is, rebuilt, replaced by a standard feature, or retired. Each item that stays gets a test and a person who signs off before go-live.

Keep the list after the upgrade. It is the start of a runbook.

Stillmark’s ERP upgrade readiness assessment produces this list, ranked by risk, in two to four weeks for a fixed price.