SQL Server Blog Post

Migrations & Upgrades

SQL Server 2016 – the Final Countdown: Assessing Your SQL Server 2016 Estate

Written by Jeff Iannucci

July 8, 2026

This post is part of a series we are calling “SQL Server 2016 – The Final Countdown.”

If you are reading this and you still have SQL Server 2016 instances kicking around, let this be yet another post reminding you that extended support for that version ends on July 14, 2026. If this is news to you, Microsoft has laid out the details here: SQL Server end of support options.

Now, trying to figure out what SQL Server 2016 instances you actually have running sounds like it should be the easy part of a migration project, but it may not be. If you start looking you might find at least one instance nobody remembers owning, one database that three different apps depend on, or one linked server pointing at something that was decommissioned…when? Before you can plan a migration from SQL Server 2016, you need an honest inventory, and by that I mean not the inventory in a spreadsheet from the year 2016.

So now, let’s walk through tools you can use to build that inventory.

MAP Toolkit

For years the go-to answer here was the Microsoft Assessment and Planning Toolkit, better known as MAP Toolkit. It’s still around, and you can still download it directly from Microsoft today at the MAP Toolkit download page, and it will still run.

However, Microsoft has stopped maintaining and supporting it. That same download page states plainly that there is no support available, and it explicitly recommends using Azure Migrate instead. There have been no updates to the MAP Toolkit in about two years, so if a scan comes back wrong, you’re pretty much on your own.

To be clear: the MAP Toolkit isn’t discontinued (yet), but it is orphaned. It’s still there and still installable, but there’s nobody answering the phone if you need help, and it’s not getting updated for anything ever again.

Azure Migrate (or whatever it’s called this week)

As for Azure Migrate, or as the web page calls it this week “Azure Copilot migration agent built on the Azure Migrate platform,” handles discovery, dependency mapping, and assessment, and as noted earlier, it is the tool Microsoft actively points people toward now.

Before you can assess anything, you need a complete and current list of every SQL Server instance in the estate. This is where the forgotten instance problem shows up the most. For example: Developer edition installs on someone’s old laptop that somehow became load bearing, or a reporting instance spun up during a project that never got decommissioned, or an Express edition got included inside a business app server.

If your ultimate target is Azure, Azure Migrate’s SQL assessment feature will take a lot of this data and translate it directly into a sizing and readiness recommendation. You can read more about that in the Azure Migrate documentation.

dbatools

While Active Directory and network scans can surface instances that nobody remembers registering anywhere, these can be tedious and you as a “Database [whatever title you have]” may not be able to use them.

For us at Straight Path, dbatools is what we often use, and the good news is it is very much alive and actively developed. This is a free, open source PowerShell module built specifically for SQL Server administration and migrations, and it is updated regularly.

Once you have a list of servers, or even a subnet to scan, dbatools commands like Find-DbaInstance can help identify SQL Server instances that are reachable on the network, and Test-DbaConnection will confirm what you can actually get into. From there, Get-DbaService will show you every SQL related service on a box, engine, agent, browser, and full text, which tells you a lot about what that instance is actually doing.

If you already maintain a Central Management Server or a list of registered servers, Get-DbaRegServer (renamed a while back from Get-DbaRegisteredServer, in case you have old scripts lying around) will pull that list so you have a starting point to expand from rather than starting cold.

All these require a bit of PowerShell knowledge, but the tools make it very easy for you with excellent documentation and examples. You can even dig deep into the source code at the dbatools GitHub repository.

Using dbatools for a database-level inventory

Once you know your instances, the next layer is what is actually living on them. Get-DbaDatabase across your instance list will give you names, sizes, compatibility levels, recovery models, and owner information in one pass instead of clicking through SSMS Object Explorer eleventeen zillion times.

I suggest that you pay close attention to compatibility levels. A database sitting at compatibility level 100 on a SQL Server 2016 instance is a completely different migration conversation than one already bumped up, and it tells you something about how carefully that database has been maintained.

This is also a good moment to run Get-DbaLastBackup or our own sp_CheckBackup across the estate. It is not directly a migration assessment task, but I presume that discovering a database has not had a successful backup in eight months is the kind of thing you want to know in week one of a project, not the week before cutover.

Finding dependencies

Export-DbaInstance in dbatools is fantastic for this part of the exercise. It scripts out logins, jobs, linked servers, credentials, database mail configuration, and a long list of other server level objects in one shot, which gives you both a dependency map and a disaster recovery artifact at the same time.

For dependencies inside the databases themselves, cross referencing sys.dm_sql_referencing_entities, sys.sql_expression_dependencies, and sys.sql_expression_dependencies will help you find cross database queries, synonyms pointing elsewhere, and views built on top of views built on top of something in a completely different database than you expected. Application dependencies rarely respect the tidy boundaries we drew in the architecture diagram three years ago.

Performing a workload assessment

Inventory tells you what exists. Workload assessment tells you how hard it is working and whether your target platform can actually handle it.

At a minimum you want: CPU, memory, and IO utilization patterns over a real business cycle, not just a Friday afternoon. Get-DbaTopResourceUsage in dbatools is a nice quick way to see which databases are actually driving load on an instance.

Query Store, if it is enabled anywhere in your 2016 estate, is a goldmine for understanding your actual workload shape rather than guessing. If it is not enabled, this is a good excuse to turn it on now, even briefly, before you finalize a migration plan.

Wait statistics over time to understand whether you are CPU bound, IO bound, or something else entirely. This matters enormously for sizing an Azure SQL Managed Instance tier or picking VM specs, and guessing wrong here is an expensive mistake to correct later.

Here’s something you can do this week: clear the counters with Clear-DbaWaitStatistics at the start of a representative business day, let a full cycle run, then capture a clean snapshot with Get-DbaWaitStatistic. That gives you wait stats tied to an actual dated window instead of numbers that have been quietly accumulating since the last unplanned restart, which is what most people are looking at without realizing it. If you haven’t restarted your instance in years (yes, this happens) the current statistics may not be as relevant.

SSMS 22 and its built-in Migration Assessment

I noted that there was a migration assessment built in to Azure Migrate, but the latest version of SQL Server Management Studio 22 includes real assessment capabilities that older SSMS versions never had. Microsoft retired the standalone Data Migration Assistant on July 16, 2025, but SSMS is now positioned as a useful tool for upgrade assessments and even Azure migration assessments.

Here’s how you use this feature. In SSMS 22, right click an instance in Object Explorer, choose Migrate SQL Server, and you get two useful paths.

Upgrade Assessment checks a source instance against a target SQL Server version and flags breaking changes, discontinued features, and deprecated functionality, with remediation guidance included.
Azure Migration Readiness does the same kind of check pointed at Azure, evaluating your databases against Azure SQL Managed Instance, Azure SQL Database, and SQL Server on Azure VMs, then recommending which target works best and why. You can read more here if you want to Migrate SQL Server to Azure SQL.

As of SSMS 22.5 this all lives on a single Migrations page, so assessment, target selection, migration, and monitoring are not four different places that you have to remember to check. It is not a replacement for the workload analysis dbatools gives you, but as a fast, metadata-based readiness check before you commit to a target, it is worth running early rather than after you have already picked a direction.

Choose wisely

By the time you finish this exercise with whichever tools you choose, you should have an honest, current picture of every instance, every database, every service dependency, and a real sense of how hard each workload is actually running. That is the foundation the rest of the migration plan gets built on. Skip it, or half do it, and you will find out about the gaps at the worst possible time, usually during a cutover weekend, and usually around two in the morning.

My guidance for you: consider not using MAP Toolkit anymore, since orphaned tools have a way of missing exactly the thing you needed them to catch. Get comfortable with PowerShell and use dbatools since it is free, actively maintained, and built (and used) by people who migrate SQL Server instances all the time. Run the SSMS 22 migration assessment early for a fast readiness read, and lean on Azure Migrate if Azure is anywhere in your future. And try not to wait too long after July 14^th to finish your assessment.