- 6 minutes to read

Migrating v6 to v7 on New Hardware

Replacing your Windows Server — and optionally your SQL Server — is an excellent opportunity to upgrade to Nodinite v7 at the same time. This guide orchestrates all the moving parts and links to the specialist guides for each phase.

Note

This guide does not replace the standard v6 to v7 migration guide. It describes what must happen before you run that guide when the target is a new Windows Server, and what must be done first if you are also moving to a new SQL Server.

Overview

flowchart TD A["Old Server: Nodinite v6\n+ Old SQL Server"] --> B["Phase 1: Migrate SQL Databases\n(if new SQL Server)"] B --> C["Phase 2: Prepare New Windows Server\n(prerequisites + fresh OS)"] C --> D["Phase 3: Fix Monitoring Agent URLs\n(machine name, not localhost)"] D --> E["Phase 4: Run Standard v6 → v7\nMigration Guide on new server"] E --> F["New Server: Nodinite v7\n+ New SQL Server"] style A fill:#e3f2fd style F fill:#c8e6c9

Phase 1: Migrate SQL Databases (New SQL Server)

If you are staying on the same SQL Server instance, skip to Phase 2.

If you are moving to a new SQL Server, complete this phase first. The new Windows Server cannot be set up correctly until the databases are in place and properly configured.

1. Perform the Database Migration

Follow the SQL Server Database Migration guide to back up all Nodinite databases from the old SQL Server and restore them to the new instance. The guide covers:

  • Pre-migration planning and prerequisites
  • Backup and restore procedures
  • Connection string updates in Nodinite configuration files happens during migration on new server, but you will need to verify and update the LogTables entries manually after restore (see next step)

2. Verify the LogTables Table

After restoring the databases to the new SQL Server, open the restored Configuration Database and review the LogTables table. This table contains references to the Log Databases — their names and SQL Server connection details.

Important

Ensure the Server and Host columns in the LogTables table reflect the new SQL Server hostname. Both columns must be updated — if either still points to the old instance (for example localhost or the old machine name), the Logging Service will fail to connect to the Log Databases after cutover.

You can inspect and update these values directly in SQL Server Management Studio with a query such as:

SELECT [LogTableId], [Server], [Host], [Database]
FROM [dbo].[LogTables]

Update any rows where Server or Host still reference the old SQL Server instance.

3. Review the LogLocations System Parameter

The LogLocations System Parameter controls where new Log Databases are created — specifically the disk volume paths used for SQL Server data files, image data files, index files, and transaction log files.

If the new SQL Server uses different disk paths (for example, D:\SQLData instead of E:\SQLData), you must update the LogLocations value to match the new server's disk layout before the first new Log Database is created.

Tip

Review LogLocations now and confirm the paths exist on the new SQL Server. Incorrect paths will cause Log Database creation to fail when the Logging Service next rotates.

Phase 2: Prepare the New Windows Server

The new Windows Server must meet all prerequisites before the migration guide can run. Install and configure the following on the new server:

Important

Install IIS Windows Features before the .NET Hosting Bundle. If you install the Hosting Bundle first, run the installer again (repair) after enabling IIS features to register the ASP.NET Core Module correctly.

Refer to Prerequisites for v6 to v7 migration for the complete list.

Phase 3: Fix Monitoring Agent Service URLs on the Old Server

Warning

This step must be completed on the old server before you start the migration guide on the new server. If skipped, Steps 7–9 of the migration will fail silently and agent configurations will not be transferred correctly.

Why This Matters

The v6 to v7 migration guide exports Monitoring Agent configurations from the old server (Step 6) and re-imports them to the Portal (Step 7). Later, the PowerShell script on the new server fetches the existing agent configurations from those exported Service URLs (Step 8).

If any agent's Service URL is set to http://localhost:8000/..., the new server cannot reach it — localhost on the new server resolves to the new server itself, not the old one.

What to Do on the Old Server

Before starting Step 1 of the migration guide on the new server:

  1. Open the Nodinite v6 Web Client

  2. Navigate to Administration → Monitor Management → Monitoring Agents

  3. For each Monitoring Agent installed locally on the old server, verify its Service URL uses the machine name rather than localhost

    Tip

    A correct Service URL looks like: http://DAOLDSERVEROS19:8000/Nodinite/Monitor/...

    An incorrect URL that must be fixed: http://localhost:8000/Nodinite/Monitor/...

  4. Update any localhost references to the actual old server machine name

  5. From the new server, verify you can reach the old agent URLs (use a browser or curl)

  6. Ensure the firewall allows inbound connections from the new server to the old server on the relevant agent ports (default: 8000)

Note

Remote agents — agents installed on servers other than the old Nodinite application server — are not affected by this step. Their Service URLs already reference their own machine names. During the export step (Step 6 of the migration guide), exclude remote agents from the JSON payload.

Phase 4: Run the Standard v6 to v7 Migration Guide

With the databases in place on the new SQL Server and the Monitoring Agent URLs corrected on the old server, you are ready to run the standard migration guide. Start the guide on the new Windows Server.

→ Updating from v6 to v7 – Migration Guide

The 15-step guide will:

  • Register the new environment in the Portal
  • Download and run the PowerShell migration script (which fetches agent configurations from the old server using the corrected Service URLs)
  • Install v7 Core Services and agents on the new server
  • Configure TLS, the Pickup Service, and agent endpoints
  • Finalize and clean up

Next Step