General Upgrade

Upgrading OptimiDoc to a newer version replaces the application software while preserving your database, configuration, licence and device connections. An OptimiDoc server is made up of two Windows components — an IIS web application and a Windows service — so an upgrade means stopping both, swapping in the new build, and starting them again. This guide walks through the whole procedure, from pre-flight backup to post-upgrade verification and rollback.

About Version 26.07

Version 26.07 (released 7 July 2026) is the first published release since 26.01. The most visible change when upgrading from 26.01 is the user interface: the modern React UI is now the default. Browsing the server root redirects to /ui, and the first login after the upgrade lands on the new dashboard. The previous console remains available at /old should you need it during the transition. Always read the Release Notes for the full change list — including any version-specific steps — before you begin.

How an OptimiDoc Upgrade Works

An OptimiDoc server installation consists of two Windows components:

• the OptimiDoc IIS web application — the admin console, the API and the React UI (which is served from the application's ui sub-folder); and

• the OptimiDoc Service Windows service — background print and scan processing, device monitoring and scheduled tasks.

An upgrade replaces the program files of both components with the new build. Everything that makes the installation yours is left in place:

• your database (schema and data);

• your configuration — web.config, NLog.config and the App_Data folder (rules, scan templates, spool and logs);

• your licence file; and

• your installed device agents.

When the upgraded application starts for the first time, OptimiDoc applies any pending database schema migrations automatically, so the database is brought up to date without hand-run scripts. Because the configuration and licence are preserved, the server comes back with all of its settings, connectors and rules intact.

This is why a backup of the database and the configuration/App_Data files is the one non-negotiable pre-flight step: the upgrade itself does not touch them, but a good backup is your safety net if anything goes wrong.

Before You Begin

• Read the release notes for the new version and note any breaking changes or version-specific steps.

• Take a full backup — see Step 1. This is essential.

• Confirm the version path. OptimiDoc uses calendar versioning (for example 26.01, 26.07) and its migrations are cumulative. If you are several releases behind, check the Release Notes for any interim steps.

• Schedule a maintenance window. The console, printing and scanning are unavailable during the upgrade — plan for roughly 15–30 minutes.

• Notify users that pull printing and scan workflows will be briefly unavailable.

• Encryption: an in-place upgrade on the same machine does not require the encryption recovery key. Moving to new hardware does — see Migration to a New Server.

Step 1 — Back Up

Copy the following to a safe location before you change anything:

For a SQL Server database, take a full backup from SQL Server Management Studio (Tasks > Back Up). For LocalDB, stop the site first and copy the .mdf / .ldf files.

Step 2 — Stop OptimiDoc

1. Open IIS Manager (inetmgr), select the OptimiDoc site and click Stop. This also stops the API and the React UI, which are served by the same site.

2. Open the Services console (services.msc), select OptimiDoc Service and click Stop.

3. Wait for any in-flight requests and jobs to finish.

Step 3 — Replace the Application Files

1. Obtain the new OptimiDoc release package from OptimiDoc (or your supplier). A release contains the updated Web application, React UI, Windows service and — if you run them — printing-node files.

2. Replace the program files of the OptimiDoc web application with the new Web and UI build, and the OptimiDoc Service files with the new service build.

3. Leave the preserved items untouched — do not overwrite web.config, NLog.config, the App_Data folder or the licence file. If your process replaces a whole folder, restore these from your Step 1 backup afterwards.

Step 4 — Start OptimiDoc

1. Start the OptimiDoc Service in the Services console.

2. Start the OptimiDoc site in IIS Manager.

3. On first start the application applies any pending database migrations automatically. For a large database this can take a few minutes — do not interrupt it.

4. Browse to the OptimiDoc URL; it should redirect to /ui and show the login page.

Step 5 — Verify the Upgrade

Upgrading a Cluster or Printing Nodes

• Server cluster. Upgrade one server node at a time so the console stays available on the others. Run the same OptimiDoc version on all nodes — mixed versions against one shared database are not supported. Once upgraded, nodes converge their rules, settings and IPP queues automatically (see Failover Architecture).

• Printing nodes. If you deploy printing nodes, update them to the matching version as well, using the printing-node package from the same release.

Rollback

If the upgrade causes problems:

1. Stop the OptimiDoc site and the OptimiDoc Service.

2. Restore the previous application files.

3. Restore the database from the backup created in Step 1.

4. Start the service and then the site, and confirm the previous version is running (System Info widget).

Keep the backup until you are confident the new version is stable.

In Summary

An OptimiDoc upgrade swaps the program files of the IIS web application and the OptimiDoc Service for a new build, then applies database migrations automatically on first start — your database, configuration, licence and device agents carry over untouched. Back up first, stop both components, replace the files, start again, and verify with the System Info widget. In a cluster, upgrade nodes one at a time on a single shared version and upgrade any printing nodes to match. Version 26.07 makes the React UI the default at /ui, with the legacy console still available at /old.

Related articles

• Migration to a New Server

• LocalDB to SQL Server

• Failover Architecture

• Print Nodes Configuration

• Release Notes

• Upgrade and Migration