Why It’s Time to Migrate from System.Data.SqlClient to Microsoft.Data.SqlClient

Microsoft

Apr 21, 2025

Are you still using System.Data.SqlClient in your .NET applications? If so, it’s time to plan your move to Microsoft.Data.SqlClient — the official, modern SQL Server driver designed for today’s platforms and tomorrow’s innovations.

We get it: you’ve got legacy projects, tight deadlines, and a long list of reasons not to touch something that already “just works.” But let us show you why switching to Microsoft.Data.SqlClient is worth it - and how we’re trying to make that easier.

The Quick TL;DR

Microsoft.Data.SqlClient is the only actively developed SQL driver for .NET from Microsoft.
System.Data.SqlClient (SDS in .NET Framework) is in maintenance mode and will not receive future feature updates.
System.Data.SqlClient (SDS NuGet package from .NET Core) will be deprecated with .NET 9 and will not support .NET 10 moving forward. Announcement: System.Data.SqlClient package is now deprecated | Microsoft Community Hub
Microsoft.Data.SqlClient unlocks new capabilities — including AI features like vector search, enhanced performance, secure by default, and cross-platform support.

We’re asking System.Data.SqlClient users to take a short survey: https://aka.ms/sds-to-mds-survey to help us understand what’s blocking migration and how we can help.

Why Migrate?

1. Security First

Security is a top priority for most organizations — and Microsoft.Data.SqlClient was built with that in mind. Features like TLS encryption enabled by default ensure your connections are more secure from day one, helping meet compliance and internal audit standards with less configuration.

By contrast, System.Data.SqlClient leaves many of these safeguards to the developer — increasing the risk of misconfigurations in production.

2. Performance Improvements

With each release, Microsoft.Data.SqlClient introduces targeted optimizations that benefit real-world workloads. In internal benchmarks, we’ve seen performance improvements for high-throughput, concurrent workloads.

If your systems process high volumes of queries, switching to Microsoft.Data.SqlClient could deliver immediate value — with zero SQL refactoring required.

3. AI-Ready (Vector Support)

With the rise of AI and semantic search, SQL Server is adding support for vector-based queries (.NET/C# Native Vector Search Samples) — and Microsoft.Data.SqlClient is your path to integrating those features into .NET applications.

This is more than a new capability — it's a shift in how modern apps handle intelligent data retrieval. System.Data.SqlClient does not support these features and will not be updated to do so.

4. Cross-Platform & Cloud-Native Ready

Microsoft.Data.SqlClient was designed to work seamlessly across Windows, Linux, macOS, and containers — unlocking true portability for your .NET applications.

Whether you're migrating to .NET 6+, containerizing workloads, or deploying cross-platform services, Microsoft.Data.SqlClient is built to support your modern architecture.

5. Reduced Maintenance & Operational Risk

System.Data.SqlClient is no longer receiving active development. Using it in production today means:

Increasing risk of encountering unresolved bugs and security vulnerabilities
Missing out on new SQL Server feature support
Dealing with outdated NuGet metadata and sparse documentation
Longer support and onboarding time for new engineers unfamiliar with legacy patterns

By contrast, Microsoft.Data.SqlClient has a dedicated roadmap, documentation, and community, with consistent investments from Microsoft engineering.

Are you still using System.Data.SqlClient?

We’ve asked ourselves the same question — and now we want to ask you directly.

We’re asking System.Data.SqlClient users to take a short survey: https://aka.ms/sds-to-mds-survey to help us understand what’s blocking migration and how we can help.

Help us understand what’s holding you back from migrating. Your feedback will directly inform our documentation, tooling, and product roadmap.

The survey takes less than 5 minutes and is intended for developers, architects, and tech leads.

Have you already migrated? - Tell us what helped, what was painful, and what would’ve saved you time. We want to make it easier for the next team.

How to migrate?

Add the NuGet package to your project, then update your references and using statements. Our porting cheat sheet provides a step-by-step set of changes you may need to make.

Update your project references: Replace references to System.Data.SqlClient with Microsoft.Data.SqlClient.
Modify your using statements: Update your using statements in your code files from System.Data.SqlClient to Microsoft.Data.SqlClient.
Test your application: Thoroughly test your application to ensure that it works as expected after the migration.

We also plan to support semi-automatic migration via .NET Upgrade Assistant.