Changing SQL Server edition is two completely different jobs depending on which way you are going. Upgrading is a setup.exe operation measured in minutes. Downgrading is a migration, because there is no supported in-place path, and it starts with an audit of everything the lower edition will refuse to run.
Edition Upgrade, Lower to Higher
Before anything else, and in writing.
The change itself.
Confirm the instance now reports the edition you paid for.
Enterprise unlocks capability that was previously refused. It does not turn any of it on for you, so nothing improves until someone configures it.
Edition Downgrade, Higher to Lower
There is no in-place downgrade. It is a side-by-side migration, and before you start any of it there is a mandatory feature audit, because a database using an Enterprise feature will simply not come online on Standard.
What Blocks a Downgrade
- TDE, a hard blocker. The database has to be decrypted first.
- Readable secondaries on an Availability Group, a hard blocker.
- Multiple databases in one AG, a hard blocker against a Standard Edition Basic Availability Group, which supports one database per group.
- Database snapshots, which have to be dropped.
- Resource Governor, which must be disabled and reconfigured.
- Online index operations, which means maintenance plans using
REBUILD WITH (ONLINE = ON)need changing before they start failing nightly.
The feature audit is not a formality at the end. It decides whether the downgrade is possible at all, and on what timescale. Finding a TDE-encrypted database after the window is booked is a conversation nobody enjoys.
Network Pre-Flight
An edition upgrade happens in place and keeps its network. The downgrade path is a side-by-side migration, so it inherits the migration network pre-flight in full. Run these days before the window, from the machines that will actually make the connections.
- Port 1433 to the target from the source server, from every application server, and from your own workstation:
Test-NetConnection new-server -Port 1433. A named instance needs its fixed port instead, plus UDP 1434 if clients rely on the Browser service. Walkthrough: testing remote port connectivity with PowerShell. - Port 445 to the backup share, from both sides. The source writes the backups and the target restores them, so test the share from each server, not just the one you happen to be logged into.
- Firewall rules in both directions on the new host. Inbound 1433 is the rule everyone remembers; outbound to the backup share, monitoring, and any linked servers is the one that turns up mid-window. Reference: SQL Server default ports.
- Line of sight from the applications, before cutover. Every app server and VM that will connect must reach the target before the window opens, tested from those machines rather than from the DBA workstation. A connection that fails at pre-flight is a task; the same failure after cutover is an incident.
- After cutover: DNS and SPNs. Repoint the CNAME and respect the TTL, because clients keep the old record for exactly as long as you told them to. Then re-register the SPNs for the new host so Kerberos keeps working; miss that and connections either fall back to NTLM quietly or fail with the pre-login handshake error.
The full version, with every command, is in the repo. Includes the edition hierarchy, the resolution steps for each blocker, and the Web Edition constraints.
Frequently Asked Questions
Can I downgrade in place?
No. There is no supported in-place downgrade path, which is why the runbook routes you into a side-by-side migration instead.
What most often blocks a Standard downgrade?
Readable secondaries, then online index rebuilds hiding inside maintenance plans. TDE belongs on that list only if you are on SQL Server 2017 or earlier, because it moved to Standard in 2019. The last one is quiet: nothing fails until the next maintenance run.
Does an edition upgrade need an outage?
It needs a restart, so plan for one. The setup itself is usually quick; the outage is the restart and the recovery of large databases afterwards.
Will Enterprise features turn on automatically after upgrading?
No. The upgrade removes the restriction, it does not configure anything. Compression, online rebuilds and the availability features all still need someone to enable them.
An edition change uses the same setup tooling as an upgrade, and the same paperwork as any other change.
- SQL Server Version Upgrade Runbook, the closest neighbour, run with the same installer and validation.
- SQL Server Migration Runbook: Standalone, when the edition change is done by moving to a new instance instead.
- SQL Server Change Management, the licence-affecting change is exactly the kind that needs a record.
Leave a Reply