The Finish Line: Windows Server 2025 and SQL Server 2025 Express

Where we left off

In Part 2, the application moved from Windows Server 2003 to Windows Server 2008 R2 and SQL Server 2008 R2. Along the way we dealt with a corrupt backup, a .NET 4 surprise and the password hashes. Testing went fine, so the old lady was ready for the final step.

Windows Server 2008 R2 and SQL Server 2008 R2 were never the destination. That stage had one job: get the databases into the SQL 2008 format, which newer SQL Server versions can restore directly. With that done, the road to 2025 was open.

The plan: same trick, newer platform

We used the same approach as in Stage 1, because it had already proved itself:

• A new Windows Server 2025 VM with exactly the same machine name.
• SQL Server 2025 Express with the same named instance and the same Hungarian collation.
• The same database names, so the configuration files, the XML login map and the subsystem registry table all stay valid without changes.
• The 2008 R2 server stays switched off but untouched as the rollback.

SQL Server 2025 Express also raises the database size limit to 50 GB, so the 1.2 GB database has room to spare for a long time.

The migration

Databases

This time the lessons from Part 2 paid off:

• Full backups from SQL 2008 R2 with CHECKSUM, checked with RESTORE VERIFYONLY before copying.
• Restored on SQL Server 2025 with the latest SQL Server Management Studio. SSMS 2008 R2 wasn't going to manage that.
• SQL logins moved with sp_help_revlogin, keeping the original password hashes and SIDs. No password resets this time, I learned that lesson.

Web tier

The IIS side followed the same recipe as Stage 1, just on IIS 10:

• .NET Framework 3.5 as a Windows feature for the .NET 2.0 applications, and .NET 4.8 for the .NET 4 application.
• Separate application pools per runtime version, with 32-bit applications enabled.
• The web root and configuration files copied over unchanged.

And the result: no issues at all. After Part 2, I almost didn't believe it.

Compatibility level: from 90 to 170

Throughout the migration, the databases kept their old compatibility level, so their behaviour stayed exactly the same. That was the plan: change one thing at a time.

Once the application was running and tested on SQL Server 2025, we raised the compatibility level to 170, the native level for SQL Server 2025:

ALTER DATABASE [AppDb] SET COMPATIBILITY_LEVEL = 170;

With around 1,300 stored procedures, this was the step I respected most, because a newer query optimiser can change query plans. The application kept working after the switch, so the databases now run on the current engine behaviour.

Performance: a bit of honesty

The new server feels slightly slower than the old Windows Server 2003. Not because of the application or SQL Server 2025, but because the VMware host only has spinning disks (HDDs). Windows Server 2025 is a much heavier OS than its 20-year-old predecessor, and it notices the difference. For an application used once or twice a month, that's an acceptable trade for a secure, supported platform.

Keeping it secure from now on

The whole point of the project was a platform that receives security updates. So it's not enough to install it, it has to stay patched:

• Automatic patching is configured on the server, and it includes the SQL Server updates as well, not just Windows.
• Azure Arc will connect the on-prem server to Azure, so we can use it to discover vulnerabilities and improve the security posture, without moving the workload to the cloud.

The full journey

And all of this without changing a single line of the application's code or connection settings, for an application with no source code and no documentation.

What's next?

The modernisation is complete. When a new host is purchased, the server will be migrated from VMware to Hyper-V. Hopefully the new host will have SSDs too, which should take care of the performance as well.

Maybe one day the application will actually be retired. But until then, at least it runs on a platform that gets security updates.

Key takeaways from the whole series

• Understand the application before you move it, even without source code. The config files, the DLL strings and the database backup told us almost everything.
• If renaming is risky, keep the names: same server, same instance, same databases.
• Upgrade in hops, and make sure the application works after each one.
• Change one thing at a time: platform first, compatibility level later.
• The cloud isn't always the answer. For a rarely used legacy app, a supported on-prem server plus Azure Arc can be the right call.