Upgrading SQL Server 2022 Express to Standard for Ignition

What is the screen telling you before Express runs out of room?

An Ignition historian on SQL Server Express gives little warning. Trends look normal until inserts start failing. Then the Gateway store-and-forward engine begins buffering, quarantined records pile up, and history develops gaps. SQL Server logs a message that the primary filegroup is full. Express caps each database at 10 GB of data file space. The transaction log does not count toward that limit. The cap applies per database, not per instance. Each check below names a reading, what each outcome means, and where to go next.

The installation behind this procedure is typical of a data-forwarding gateway:

• Windows Server 2022 running SQL Server 2022 Express and Ignition on the same box.
• KEPServerEX on a separate Windows server.
• Perspective screens used only for configuration and status, accessed over RDP.
• Ignition logs history locally and POSTs it to an Azure database, which holds the primary record.

The local historian is a backup, but a required one.

Check 1: How much headroom does the historian database actually have?

Read the real data-file size before deciding anything. Run this in SSMS against the Express instance:

The size column is in 8 KB pages, so * 8 / 1024 converts it to MB. Record data_MB monthly, or read it from successive backups, to get a growth rate. Then estimate:

months_remaining = (10240 MB - current data_MB) / monthly_growth_MB

Result	Meaning	Next check
Years of headroom, and growth is steady	No immediate problem. Plan the edition change on your own schedule.	Check 2 (reduce growth anyway)
Headroom shrinks faster than expected	Tag logging configuration is likely driving growth.	Check 2 first
Less than a year, or a site several times larger	Pruning alone will not hold. The edition change is on the critical path.	Check 2, then Check 3

Scaling matters when you deploy the same design across sites. This system projects about five years to the cap. Sister systems are 4 to 5 times its size. Assuming growth scales linearly with tag count, those sites reach 10 GB in roughly 12 to 15 months. That puts them in the last row from day one.

Check 2: Can you slow the growth instead of buying an edition?

A 1-second scan class on a setpoint or discrete value writes rows that carry no information. Before paying for Standard, find the tags that dominate row count. The Historical Tag Analysis tool on the Ignition Exchange ranks tags by logged volume. On an Express-based system, it quickly surfaces tags logging every second that only needed on-change logging. Setpoints and discretes are the usual offenders.

Option	Where it's set	Effect on the 10 GB limit	Trade-off
Switch slow-changing tags to on-change with deadband	Tag History properties on each tag or UDT	Often cuts row count sharply at the source	Tune the deadband so real changes are not lost
Historian pruning	Gateway database connection / history provider settings	Caps database size by age	Pruned data is gone from the database
Prune to CSV	Scheduled export before pruning	Keeps the database small	Data survives but cannot be queried directly; file management gets messy
Archive table in the same database	Scheduled SQL move from live tables to archive tables	None. Archive rows still count toward the cap	Keeps data queryable; suits editions without the cap
Upgrade to Standard	SQL Server setup, Maintenance tab	Removes the Express size cap	License cost (Check 3)

Regulatory retention changes the answer. Some operations must keep processing data for five years. When the data must also stay queryable, CSV export fails the requirement, and an archive table needs an edition without the 10 GB cap. When retention is contractual or tied to billing, as here, keep the full history queryable. Treat pruning as a supplement, not the fix.

Next step depends on the result. If tuning brings projected growth well inside the cap for the retention period, stop here. Otherwise, go to Check 3.

Check 3: Does the SQL Server Standard licensing model fit this gateway?

Running everything on one server does not remove the CAL requirement. Under the Server + CAL model, every user or device that accesses SQL Server needs a CAL, directly or through Ignition. Inductive Automation's sales engineering interpretation is:

• One CAL for each device or machine that runs a Vision Client or Perspective Session.
• At least one CAL for the Gateway itself.

Model	What you count	Fits when
Server + user CALs	Named people accessing the data	Few users, many devices each
Server + device CALs	Machines running Clients or Sessions, plus the Gateway	Few fixed devices, many or shifting users
Per-core	Cores on the SQL Server host	Unlimited or uncountable users and devices; priced accordingly

For this gateway, the counted devices are the Gateway itself and any machine that opens the Perspective configuration screens. Opening those screens from a second workstation adds a device. KEPServerEX on the other server talks to Ignition, not to SQL Server, so it does not access the database. Confirm the final count with your Microsoft licensing reseller, not by inference.

Open-source databases avoid this check entirely. PostgreSQL with the Timescale extension has no size cap and compresses historian data heavily. The trade is patch management. On Windows, a PostgreSQL security fix often means a backup-and-upgrade cycle rather than an OS update. Some plant IT groups track those CVEs more aggressively than SQL Server, which Windows Update and SQL Server cumulative updates cover. If IT policy has already ruled out open source, continue to Check 4.

Check 4: Which setup path is the right one?

Most failed attempts stall here. SQL Server setup offers two paths that sound interchangeable but do different jobs.

Setup path	What it does	Result on 2022 Express to 2022 Standard
Installation > Upgrade from a previous version of SQL Server	Version upgrade, such as an older major release to 2022. Rewrites binaries and upgrades database metadata.	Stalls at Select Features with an error that no features are selected for upgrade. The instance is already on the target version, so there is nothing to upgrade.
Maintenance > Edition Upgrade	SKU change within the same version. Swaps the edition and license; database files are untouched.	Completes. The instance becomes Standard.

The screen explains itself. "No features selected for upgrade" means you chose the version-upgrade wizard for an edition change. Cancel and use the Maintenance tab.

This distinction also addresses the usual worry about in-place upgrades. The problems people report come from version upgrades: deprecated features, compatibility level changes, and driver mismatches. Edition Upgrade within 2022 changes none of that. The instance name, port, logins, and databases stay as they are, so the Ignition JDBC connection keeps working without edits.

How do you run the Edition Upgrade without losing history?

You need the SQL Server 2022 Standard installation media (ISO) and its product key. The key may be pre-populated on volume-licensed media.

1. Take a full backup of every Ignition database on the instance. Take an Ignition Gateway backup as well.
2. Decide how to handle Ignition during the service restart:
   • Stop Ignition (the stop-Ignition batch file or the Windows service). Nothing writes during the change, and no records are quarantined. The cost is a history gap for the outage window.
   • Leave Ignition running. Store-and-forward buffers inserts while SQL Server restarts. This only works if the buffer holds the outage without overflowing.
   On a single-server gateway with a short outage, stopping Ignition is the cleaner choice. That was the path used here, and it completed without issue.
3. Mount the ISO and run setup.exe as administrator.
4. In SQL Server Installation Center, select Maintenance, then Edition Upgrade. Do not use Installation > Upgrade from a previous version.
5. Enter or confirm the product key, accept the license terms, and select the instance (for example, SQLEXPRESS).
6. Let the Edition Upgrade rules pass, then run the upgrade. Setup restarts the SQL Server service.
7. In SQL Server Configuration Manager, check SQL Server Agent. Express does not run Agent, so the service is usually set to Disabled or Manual after the change. Set it to Automatic if you plan to schedule archive jobs, index maintenance, or backups with Agent.
8. Start Ignition, or confirm it reconnected if you left it running.

Can the SQLEXPRESS instance name be changed afterward?

The edition changed, but the instance name did not. SQL Server cannot rename a named instance. The name is fixed at install in the service name, registry paths, and default file locations. Anyone seeing SERVER\SQLEXPRESS will assume Express. Two approaches work:

Approach	Work involved	When to choose it
Keep SQLEXPRESS and document it	None. Add a note in the Ignition database connection description and in site documentation.	A single existing site. Zero risk, zero downtime.
Install a new Standard named instance and migrate	Install the new instance, back up and restore the databases, recreate logins and jobs, repoint the Ignition connection URL, and uninstall the old instance.	New sites, or when naming consistency across a fleet matters.

For the site already upgraded, keep the name. The migration adds a restore, login remapping, and a connection change for a cosmetic gain. For the larger sister systems, install Standard from the start under a neutral instance name. That skips both the Edition Upgrade and the naming problem.

How do you verify the upgrade from SQL Server through to Ignition?

1. Confirm the edition in SSMS:

   SELECT SERVERPROPERTY('Edition')        AS Edition,
          SERVERPROPERTY('ProductVersion') AS Version,
          SERVERPROPERTY('InstanceName')   AS Instance;

   Edition must read Standard, not Express. Version should match the pre-upgrade value, because an edition change does not change the version.
2. Rerun the size query from Check 1. Data file sizes should be unchanged, which confirms the databases were not touched.
3. Check the database connection in the Ignition Gateway web interface. It should show Valid, with the same URL as before.
4. Open the store-and-forward status page. Confirm the buffer is draining to zero and the quarantine holds no new records.
5. Open a trend covering the upgrade window. Confirm fresh data points are arriving and the only gap is the outage window.
6. Confirm the next scheduled POST to Azure succeeds and includes records logged after the restart.

FAQ