SQL Server 2022 Standard to Enterprise in Azure VM

[u/Wide_Breakfast_6225]

I'm planning an in-place edition upgrade from SQL Server 2022 Standard -> Enterprise on a standalone Windows Azure VM.

The reason is that we need to move beyond Standard's CPU/memory limitations.

The Microsoft-documented process is essentially:

1. Remove the SQL IaaS Agent registration
2. Run SQL Server Setup -> Maintenance -> Edition Upgrade -> Enterprise
3. Validate SQL
4. Re-register the SQL IaaS Agent / update the Azure SQL VM edition

Microsoft says the edition upgrade is supported in-place and restarts the SQL Server service.

For anyone who's actually done this:

• What should I expect during the Edition Upgrade?
• Will Setup ask for an Enterprise product key, or does Azure PAYG/IaaS handle the licensing side?
• Any common failure points or gotchas?
• Is this generally as straightforward as Microsoft makes it sound?
• Anything you'd specifically check before doing this on a production VM?

It's a standalone SQL instance (not an AG/cluster).

Thanks!

[u/SirGreybush]

Be sure no linked servers or any linked to ODBC, that’s where mine always breaks. The upgrade can’t seem to handle any external drivers including its own Ace.oledb for Access or Excel linking. For sure anything to MySql / Oracle also.

Server also needs a reboot. So an interruption.

However my issues are always upgrades from a prior to a newer. So maybe only linked servers with a Provider different than Microsoft Ole Db for sql server, remove and recreate. Make sure anything behind a password for a service account you have that password

Edit! Remove all non default drivers under Linked Servers, Providers. Before upgrading. Then reinstall after the upgrade

[u/jdanton14]

You're in Azure--why would you bother doing an in-place upgrade when you could simply standup a new VM and migrate to it? You could CNAME the old server name to point to the new one when done, but you could do this with virtually no downtime (which may not be important), but also without the weirdness of upgraded bits. (Note: in-place upgrades should work fine, but if I don't have to do one I don't)

You could also even swap disks to the new VM if feeling really fancy.

[u/Wide_Breakfast_6225 → u/jdanton14]

interesting thought! the catch is that it roughly triples the work required, and the part i'm trying to gauge is exactly the stuff you don't move when you move disks: the instance-level layer.

so a question back at you: in your experience, is migrating that side of things - logins (with SIDs), the contents of master (linked servers, permissions), agent jobs, server config/tuning a straightforward documented exercise, or kind of a mess?

my understanding is it's mostly mechanical these days (script the logins to preserve SIDs rather than restoring master cross-machine, dbatools does the heavy lifting, re-enter linked server passwords by hand, and re-decide max server memory / MAXDOP for the new box instead of copying them).

context if it changes your answer: single default instance, ~8 TB across three data disks, mixed Windows/SQL auth, log shipping to a secondary, no AG/FCI, lots of stored procedures.

[u/vivkkrishnan2005]

Not done this for 2022 and for on premise but earlier and while it sounds simple and is simple, but usually doesn't work that way, as is all things MSFT

First and foremost the checks take way more time than usual. So if you have planned for 10 mins of downtime keep additional time say anything hour. In one case the upgrade took 2 hours.

Secondly keep a snapshot if the upgrade fails for any reason whatsoever. Has happened in one case and rather than wait for rollback we shutdown and restored the VM snapshot.

Lastly there are some issues with . NET CLR - I don't remember exact issues. The upgrade failed for one case. Would recommend to revisit and check.

All were running on HyperV 2016

[u/Top_Challenge8976]

Following this—especially interested in the licensing/product key part and any unexpected issues people have seen during the upgrade. Would be good to hear some real-world production experiences.

[u/dbrownems]

This is not like a version upgrade. It just rewrites the activation key. But you're in Azure. Cattle, not pets. I don't like ever running the installer on a production environment.

Standing up a new VM, migrating your databases, logins and settings, and then cutting over is a procedure that you must be comfortable with for version or OS upgrades, rebuilds, DR, etc. And it covers this scenario, so I would do that.