The following information is based upon SQL Server 2025 CTP 2.1 and is subject to change upon release.

Recently, I've been updating the Ansible playbooks and the mssql Ansible role to support SQL Server 2025.  This role and playbook are used throughout the Ansible for SQL Server DBAs course, and I wanted to ensure they're ready before SQL Server 2025 goes GA. 

One of the automations we tackle is the deployment of the Integration Services catalog on new builds.  This is when I discovered there's a major change in the Microsoft.SqlServer.Management.IntegrationServices assembly.  The error I encountered, while deploying the catalog using this assembly, was "New-Object : Cannot find an overload for "IntegrationServices" and the argument count: "1"."  

Not very descriptive, I know.  This led to many hours researching what went wrong.  The script used had worked since 2016 without issue. 

Until now.  

If you manage SSIS packages, have automated deployment scripts, or maintain custom database management tools, this breaking change is something to pay attention to.

What's Changing and Why You Should Care

Microsoft is making a strategic pivot away from the legacy System.Data.SqlClient data provider that's been the backbone of .NET database connectivity for nearly two decades.  The Microsoft.SqlServer.Management.Integration Services assembly used this provider when creating the Integration Services object and connecting to the target SQL Server instance. 

Up until 2025, that is. 

The new version of this assembly (17.0.0.0) included with the SQL Server 2025 install depends on the newer Microsoft.Data.SqlClient provider.

This isn't just a nice-to-have update.  The old provider is being deprecated in .NET 9 (source) and will be completely unsupported in .NET 10.

Here's what this means for your daily operations:

• SSIS automation scripts will break without updates.
• Deployment automation relying on .NET libraries will need rebuilding.
• Legacy connection strings may cause authentication failures due to new security defaults.

It's Not Just a Namespace Change

The most visible impact hits the Microsoft.SqlServer.Management.IntegrationServices assembly–the core library for SSIS catalog automation.  The constructor that previously accepted System.Data.SqlClient.SqlConnection objects now require Microsoft.Data.SqlClient.SqlConnection objects (otherwise, you'll see the error I encountered regarding the argument count).

Note:  The Microsoft.SqlServer.Management.IntegrationServices.dll can be found in the following locations (GAC):

• SQL Server 2022 - C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.SqlServer.Management.IntegrationServices\v4.0_16.0.0.0__89845dcd8080cc91
• SQL Server 2025 CTP 2.1 - C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.SqlServer.Management.IntegrationServices\v4.0_17.0.0.0__89845dcd8080cc91

Before (SQL Server 2022 and earlier):

C# Example:

using System.Data.SqlClient;
using Microsoft.SqlServer.Management.IntegrationServices;

string connectionString = "Server=MySQLServer;Database=master;Integrated Security=True;";
SqlConnection connection = new SqlConnection(connectionString);
IntegrationServices ssis = new IntegrationServices(connection);

PowerShell Example:

# Load the legacy System.Data.SqlClient assembly
Add-Type -AssemblyName "System.Data"

# Create connection using legacy provider
$connectionString = "Server=MySQLServer;Database=master;Integrated Security=True;"
$connection = New-Object System.Data.SqlClient.SqlConnection($connectionString)

# Load SSIS management assembly and create IntegrationServices object
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.Management.IntegrationServices") | Out-Null
$integrationServices = New-Object Microsoft.SqlServer.Management.IntegrationServices.IntegrationServices($connection)

After (SQL Server 2025):

C# Example:

using Microsoft.Data.SqlClient;
using Microsoft.SqlServer.Management.IntegrationServices;

// Note: Encrypt=True is now the default
string connectionString = "Server=MySQLServer;Database=master;Integrated Security=True;Encrypt=True;TrustServerCertificate=True;";
SqlConnection connection = new SqlConnection(connectionString);
IntegrationServices ssis = new IntegrationServices(connection);

PowerShell Example:

# Import the modern Microsoft.Data.SqlClient

Add-Type -AssemblyName "Microsoft.Data.SqlClient"

# Create connection using modern provider with enhanced security defaults
$connectionString = "Server=MySQLServer;Database=master;Integrated Security=True;Encrypt=True;TrustServerCertificate=True;"
$connection = New-Object Microsoft.Data.SqlClient.SqlConnection($connectionString)

# Load SSIS management assembly (SQL Server 2025 version) and create IntegrationServices object
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.Management.IntegrationServices") | Out-Null
$integrationServices = New-Object Microsoft.SqlServer.Management.IntegrationServices.IntegrationServices($connection)

This isn't an isolated change.  Microsoft has confirmed breaking changes across the SQL Server management API family, including Microsoft.SqlServer.Dts.Runtime and SMO libraries, as documented in the SQL Server 2025 Integration Services announcement.

Security Implications: The New "Encrypt by Default" Reality

The new Microsoft.Data.SqlClient provider adopts a "secure by default" approach.  The Encrypt connection property now defaults to True, meaning:

• Unencrypted connections will be rejected unless explicitly disabled.
• Self-signed certificates will cause login failures without proper configuration.
• Development environments will need TrustServerCertificate=True in connection strings.

This is actually a positive security enhancement, but it will catch a lot of people off guard during upgrades (get familiar with certificates and how to enable encryption the right way).  Be sure to test, test, test.

Action Plan: What DBAs Need to Do Now

1. Inventory Your Environment:

• SSIS packages with custom Script Tasks using ADO.NET connections.
• PowerShell scripts that instantiate SQL Server management objects.
• Custom monitoring applications built with .NET.
• Deployment automation using APIs.  The Ansible for SQL Server DBAs will have examples of how this can be done while still supporting pre-SQL Server 2025 environments.  Turns out, this is easily solved if you know what you're looking for.  
• Third-party tools that might depend on legacy providers.

2. Test Connection String Compatibility:

Create a test environment and validate that your existing connection strings work with the new security defaults.  Pay special attention to:

• Development environments with self-signed certificates.
• Integrated security configurations.
• Connection pooling settings.
• Timeout configurations

3. Plan Your Migration Timeline:

I wouldn't suggest you rush and plan your production migration to SQL Server 2025 anytime soon.  But your developers and other stakeholders are going to be itching to get their hands on the new AI capabilities in SQL Server 2025, at least in your development environments.  Using the mssql Ansible role as an example, you can quickly build out these lower environments with ease.

Unlike typical SQL Server feature updates, this breaking change affects the tooling layer–the automation and management scripts that keep your environment running (unless you're running everything with click-ops 😳).  This isn't something you can postpone until after the database upgrade.

Recommended approach:

• Complete your infrastructure audit.
• Update and test critical automation scripts (in non-prod environments).
• Before SQL Server 2025 deployment: Full validation of updated tooling.

Managing the Transition: Practical Tips

For SSIS Environments

• Update custom Script Tasks and Script Components to use the new provider.
• Test package deployments with updated connection managers.
• Validate that the existing SSIS Catalog automation still functions (this is what started this whole post).

For Custom Applications

• Replace NuGet package references from System.Data.SqlClient to Microsoft.Data.SqlClient.
• Update all using statements.
• Test thoroughly.

For Monitoring Solutions

• SMO-based monitoring tools will need updates
• Custom performance counters using .NET database connectivity require attention.
• Third-party monitoring tools may need vendor updates.

What Happens if You Don't Act?

You'll be like I was and wonder why your script that has worked forever no longer works.  But other than that, you could experience:

• Compilation failures when rebuilding against new libraries.
• Runtime exceptions in production/development environments.
• Security vulnerabilities from continued use of deprecated providers.
• Inability to leverage new SQL Server 2025 features - Vector search (for example)

Conclusion

While breaking changes always create work, this migration positions your SQL Server environment for the future.  The enhanced security posture, performance improvements, and access to cutting-edge features make this transition worthwhile.

Start your migration planning now (if you don't have a TEST environment and don't want to spend the $$$ on cloud resources, check out the Automated Sandbox Framework to set up your own multi-machine local environment in minutes).  The technical debt of postponing this change will only compound, and the benefits of the modern data access stack are too significant to ignore.

References

Microsoft Official Announcements:

• System.Data.SqlClient Package Deprecation Announcement - Microsoft Community Hub
• Why It's Time to Migrate from System.Data.SqlClient to Microsoft.Data.SqlClient - Microsoft Community Hub
• What's New in Integration Services in SQL Server 2025 - Microsoft Learn
• SQL Server 2025 Integration Services Public Preview - Microsoft Community Hub

Technical Migration Resources:

• Introduction to Microsoft.Data.SqlClient namespace - Microsoft Learn
• Official Migration Cheat Sheet - GitHub dotnet/SqlClient
• Microsoft.Data.SqlClient NuGet Package - NuGet Gallery
• ADO.NET Connection Manager - SQL Server 2025 - Microsoft Learn