Server performance issues after upgrade to 2025 SQL

Posted by PriNiceIT@reddit | sysadmin | View on Reddit | 18 comments

We had two on-prem Windows Server 2019 VMs running on Hyper-V. One was hosting SQL Server 2016 Standard, and the other hosted a business application for the equipment rental industry that functions as a Remote Desktop application.

I come from the sysadmin side, so please be patient with my DBA terminology. 🙂

We recently deployed two new Windows Server 2025 VMs in Azure—one running SQL Server 2025 and the other serving as the RDP/application server. The application vendor was paid to migrate the database and application data to the new Azure environment.

After the migration, everything initially appeared to be working correctly. However, once users started using the system, they began reporting severe slowness with transactions, specifically anything related to contracts. Contracts containing larger numbers of items take significantly longer to process. Other parts of the application seem to perform normally, and in some cases even faster than before. There are no issues with the data itself or missing records.

The application vendor initially blamed insufficient resources, so we increased CPU and memory allocations. However, the issue occurs even with only a single user logged into the application. We have since increased the SQL VM to 128 GB RAM and 8 vCPUs, with Premium SSD storage and high-bandwidth networking. Network latency between the application server and SQL Server is very low, averaging approximately 1 ms round-trip.

At one point, the vendor blamed a tax software integration called Vertex. They claimed they could see API calls taking much longer than expected and stated they would address the issue. After many hours of investigation and roughly a week of combined troubleshooting effort, they suddenly changed course and stated that their software is not compatible with Windows Server 2025 and/or SQL Server 2025. They are now recommending that we move back to Windows Server 2016 or 2019, which would require another export/import process since there is apparently no supported restore path available.

We have asked for evidence or technical details explaining why the platform is incompatible, but no specific reasons have been provided. Their position is that they connected the application back to the old server, performance was normal, and therefore the problem must be SQL Server 2025.

This issue is significantly impacting our business, and we don’t have much leverage to challenge the vendor’s conclusions. Besides your general input, I have a couple of questions: 1. Does this sound like an application compatibility issue with SQL Server 2025? 2. If I wanted to engage an expert to help troubleshoot this as quickly as possible, who would you recommend? We have considered opening a case with Microsoft, but I would also appreciate recommendations for MVPs or consultants who specialize in Microsoft SQL Server performance troubleshooting.

Any insight would be greatly appreciated.

[-]

flyguydip@reddit

I had this exact situation back around 2020 but all on-prem. Migrating from an old physical server running server 2008/sql 2008 with 2 cpus and 8gb of ram to a new vm running windows/sql server 2019. Users came in monday morning and couldn't even log in without getting timeout issues. The vendor swore the server was low on resources completely ignoring the resource graphs I was giving them. My boss agreed with the vendor despite all evidence to the contrary, so I keep accommodating them. After upgrading them from 2 cpu's to 8, then to 16, and 16gb of ram, then 32gb of ram to 64gb (explaining that sql wasn't going to use those resources properly anyway because the entire db was only like 400mb) they still weren't working. Then I migrated all the other vm's off the host (about 20vms), then dedicated an entire old san we had just decommissioned (used to host 100+ vm's) to only run their vm. Even though they were the only server running on our newest, most powerful blade server and had dedicated EqualLogic, it still didn't work. After showing them that the vm was using less than 1% of any resource (including networking) and giving them copies of standard practice configs we used for hosting database heavy vm's, they finally capitulated and agreed to look at their code.

Turns out, it took them like 5 days to figure out it was a coding/sql config problem. After they deployed their changes I let it sit for a few weeks and then I reverted back to the original configuration but this time matched the specs of the old server (2 cpu's and 8gb of ram) to see if anyone would notice. Everyone thought they were on a dedicated blade and nas for a about a month when I typed out a strongly worded email which included how much time I wasted while everyone ignored resource counts and told them they had been on the same config as the old server for 2 weeks and nobody noticed. I also included resource graphs showing they still weren't going over 40% utilization of any resource in windows. I don't know exactly what changes the vendor made unfortunately, but I assume they rolled them out to all their customers after that.

The moral of the story is that sometimes vendors will say whatever they have to to get out of work and make you jump through as many hoops as they can if you'll let them. It costs them nothing if throwing more resources at the problem solves their issue. If your supervisors support you and your resource numbers look good (even for individual cores), just throw stats back at the vendor and tell them to fix their code or tell you exactly what's wrong and how to fix it in one shot so you don't have to do what I did for weeks on end.

Right_Hold_7291@reddit

Honestly, that sounds like a tough situation with the vendor just pointing fingers after you already paid them to move everything. If a single user is still hitting slowdowns on contracts with that much RAM and fast storage, it really does not sound like a pure hardware problem.

I know a guy named Ibrahim Taofeek who does full-spectrum tech work including cloud and database stuff, and he might be able to help you dig into this quickly. He could look at the SQL Server 2025 side and see if it is a query plan or compatibility issue the vendor missed. I would also open a case with Microsoft at the same time, since they can give you official answers on whether SQL 2025 has problems with your setup. That way you have two sets of eyes on it instead of just the vendor's word.

Something like Ibrahim Taofeek: Full might be worth a look.

Stonewalled9999@reddit

This is likely more due to server 2025 being a steaming pile than sql 2025. I’ve personally seen 2019 on bare metal run 2-3 times “faster / snappier” than 2025 on the same hardware

ColbyFromDigg@reddit

Yeah, I could NOT get a new SCCM build working on Server 2025. Decided to scrap it and build on Server 2022 following the exact setup steps I had previously recorded and the process was really smooth.

OkExamination3372@reddit

I would reach out to Ibrahim Taofeek: Full for this. They handle full-spectrum cloud and SQL performance issues like this.

carpetflyer@reddit

You now have to deal with latency of the Internet moving to hosted SQL. So if the queries are not coded well and send lots of data back to the client you have to wait for the client software to download the query data result.

You wouldn't notice this if on prem since you are getting low latency.

How is the WAN connection? Check and see how much bandwidth is being taken up as you are loading the contracts with large amount of items.

Obsidian-One@reddit

Update statistics on each database. This is especially true if compatibility levels changed It's non-destructive and can be a big help. I would start with this.

For specific queries that run slow, it's typically due to changes in the SQL optimization engine. Those queries should be visited individually. For example, some inner subqueries perform terribly at compatibility level 150, but do very well at compatibility level 130.

If you absolutely must downgrade, consider first just altering the compatibility level of each database to an earlier version. Changing to level 130 is equivalent to going back to SQL 2016, for example. Whenever changing the compatibility level, you have to update statistics, so keep that in mind.

Source: me when our SQL was recently upgraded from 2014 to 2022. I had to refactor a few queries, but overall, some compatibility level downgrading and updating statistics was the biggest help.

ShoulderRoutine6964@reddit

You are comparing azure+sql 2025 with on onprem+sql2016 and with different OSes.

You can't say the problem is with sql 2025, you are changing too many important factors at once.

jdanton14@reddit

Self-serving, but engage a DBA consultant. You need to look inside the database engine To figure the problem and adjust accordingly. But it’s probably not the upgrade it’s probably storage in Azure.

mat-ferland@reddit

I wouldn’t let the vendor reduce this to SQL 2025 bad yet. For old client/server apps over RDP, the ugly part is often latency, IO, and query plan changes all showing up as the app is slow. I’d compare SQL compatibility level, MAXDOP/cost threshold, disk latency, Azure VM SKU/storage type, and whether the app server and SQL server are in the same region/VNet path. Also worth testing Server 2022 before you spend days debugging a Server 2025 variable.

Did you format the drive with a bigger block size or the default allocation. Off the top of my head, I think SQL likes 64k blocks.

LetSufficient5139@reddit

Unlikley as Azure SQL VMs from Marketplace come with correctly formatted disks.

IWantToSayThisToo@reddit

Get rid of SQL Server and switch to PostgreSQL.

While you're at it get rid of Windows (lol) as a server and switch to Linux. It's 2026 not 2002.

Bless. One day you'll work for a grown-up company, however I doubt it with your quite frankly chilldlike opinions.

Unnamed-3891@reddit

Imagine posting this and thinking you’re being helpful

blue30@reddit

I'd get on the VM and see what it's doing while the slow transactions are happening. It it maxing out one core, running out of ram, stalled on i/o, etc etc. What process is busy. Just basic troubleshooting.

WDWKamala@reddit

Their position is that they connected the application back to the old server, performance was normal, and therefore the problem must be SQL Server 2025.

This doesn’t quite follow. The issue could be IO contention at Azure.

Hangikjot@reddit

I’ve seen some strange issues with windows server 2025, performance and otherwise. I’d avoid that os for now. SQL i bet is fine, that tends to just come down to setting changes like compatibility level, cardinality and maxdop , core counts and speed to in either direction can change behavior a lot.