Traditional reporting systems like SSRS have served enterprises well for years. However, with the rise of interactive dashboards and real-time insights, companies now require more dynamic and visually rich reporting solutions. This is where Power BI Report Server steps in.
This article provides a complete guide to help you understand the migration process, benefits, and a real-world use case where 2000+ reports were successfully migrated.

Real-World Use Case: 2000+ Reports Migration

Large-scale migrations are often viewed as high-risk, time-consuming projects. However, leveraging the right automation tools changes the math entirely.

The Benchmark: In a recent enterprise deployment, we successfully migrated over 2,000 reports in approximately 40 minutes using SSRS Reports Migration Wizard.

Why Organizations are Making the Switch

• Unified UX: Consolidate Power BI reports (.pbix) and paginated reports (.rdl) into a single portal.
• Enhanced Performance: Improved processing engines and scalability.
• Legacy Debt Reduction: Modernizing connection strings and centralizing data sources.
• Interactive Analytics: Moving beyond static tables to drill-through dashboards.

This use case clearly demonstrates that with the right strategy, even large-scale migrations can be executed efficiently.

Strategic Migration Workflow

To efficiently migrate SSRS reports to Power BI Report Server, follow this streamlined process:

Step 1: Select the Source

• Choose the SSRS/Poweer BI Report server or import a .SRMW file
• Ensure the source environment is accessible

Step 2: Select the Target

• Provide connection details for the Power BI Report Server
• Choose destination (same server/different server/folder)
• Validate connectivity

Step 3: Choose Report Items to Migrate

• Select reports, folders, datasets, and data sources
• Use filters for bulk selection

Step 4: Manage Folder Mapping

This step is available when “Rename target folders during migration” is enabled. It is useful for organizing and restructuring reports in the target environment.

• Rename folders during migration
  Example: Finance → Finance_New
• Migrate to a different folder name
  Example: Reports → Prod_Reports
• Consolidate multiple folders into one
  Sales Asia, Sales EU, Sales NA → Sales

Step 5: Update Data Source Connection Strings

• Fetch all data sources used in selected reports
• Review and edit connection strings
• Update credentials manually
• Optionally convert embedded sources to shared sources
• Changes apply only after migration completes

Step 6: Review Changes

• Verify summary of new, updated, and skipped items
• Export summary if needed
• Confirm configurations before execution

Step 7: Finish and Validate

• Execute migration
• Review logs and migration summary
• Validate data accuracy and report performance
• Rerun process if needed

Installation

SSRS Reports Migration Wizard can be installed as an extension to:

1. Visual Studio 2017, Visual Studio 2019, Visual Studio 2022 & Visual Studio 2026.
2. SSMS 18, 19, 20, 21, 22
3. Standalone tool.

Standalone Usage

Don’t use Visual Studio? You can still run the wizard as a standalone tool:

Launch SSRS.Reports.Migration.Wizard.exe.

Download the .vsix from here.

Rename the .vsix to .zip and extract it.

FAQ

Conclusion

To successfully migrate SSRS reports to Power BI Report Server, organizations must adopt a structured, scalable, and automation-driven approach. As demonstrated in the real-world case of migrating 2000+ reports, it is possible to achieve seamless transformation with minimal disruption and post migration efforts.

By upgrading to Power BI Report Server, businesses gain access to modern analytics, interactive dashboards, and a unified reporting platform that drives better decision-making.

Read full customer testimonial on the Visual Studio Marketplace.

Watch a quick demo

The post Migrate SSRS Reports to Power BI Report Server appeared first on AzureOps.

Traditionally, administrators had to download each report manually from the Report Manager portal, or write complex scripts using SSRS SOAP APIs. Both approaches are time-consuming and prone to errors. Fortunately, there is now an easier way to achieve this: using the SSRS Reports Migration Wizard.

What Is the SSRS Reports Migration Wizard?

The SSRS Reports Migration Wizard is a tool from AzureOps designed to help you migrate SSRS content (native mode) between servers or to/from an SRMW export file.
It supports migrating:

• Folders
• Reports
• Shared datasets
• Shared data sources
• Subscriptions
• Roles

The wizard gives you a guided interface to select exactly which objects to migrate, and optionally adjust connection strings along the way.

When to Use Export + Import via SRMW File

Using an export file gives you flexibility:

• You can create a backup snapshot of your reports/datasets/data sources
• You can move content offline — export on one server, then import later on a different server
• It helps in server upgrades, consolidation, or reorganizing your SSRS environments

If you prefer a direct server-to-server migration, that’s also supported by the wizard. But export/import via file is safer and useful, especially when network access or permissions between servers is constrained.

Step-by-Step: Exporting SSRS Items to SRMW File

Here is a step-by-step walkthrough of how to carry out the export. You can follow along with the video, or use these instructions with screenshots in your own environment.

1. Launch the Migration Wizard

• From SQL Server Management Studio (SSMS), open the SSRS Reports Migration Wizard.
• (If installed as an extension, you’ll find it under the Tools menu.)

2. Start the Export Process

• Click Next to begin.
• Enter the source SSRS web service URL (e.g. http://yourservername/reportserver) along with domain credentials.
• Click Connect to load the contents of that SSRS instance.

3. Select the Export File Target

• On the next screen, choose the SRMW file option as your export target.
• Browse to the folder where you want the export file to be saved.
• Specify a file name (for example, MySSRSExport.srmw).
• Click Next to continue.

4. Choose SSRS Items to Export

• You’ll see a tree view of all SSRS objects: folders, reports, datasets, data sources.
• Check the boxes next to the items you want to export.
• After your selection, click Next.

5. (Optional) Update Data Source Connection Strings

• On the next screen, you can update the connection strings and credentials for data sources.
• These settings will be baked into the SRMW file and used when you later import the content.
• If you don’t need to change anything, you can skip this.
• When ready, click Next (or Finish, depending on wizard layout).

6. Review & Confirm

• The wizard will show a summary of what will be exported.
• Confirm your selections and click Finish (or Export) to start the process.

7. Complete Export & Verify

• The wizard runs, exporting all chosen items into your SRMW file.
• When it completes, open File Explorer and navigate to the export folder you chose.
• You’ll see the .srmw file.
• (Optionally) You can unzip or inspect its contents to verify that your reports, datasets, and sources are included in the proper folder structure.

What’s Inside the SRMW File & How It Helps

The SRMW file is essentially a packaged archive that contains:

• Report definition files (RDLs)
• Dataset definitions
• Data source metadata (connection strings, credentials)
• The folder hierarchy (to preserve navigation/organization)
• Standard subscriptions definition, etc.

When you later run the wizard’s Import mode, the tool reads this file and recreates the selected SSRS items into the target server.

Using this intermediate file gives you:

• A portable, versionable package
• A safety buffer (you can inspect or edit before import)
• The ability to stage/migrate content in controlled stages

Pro tips:
1. Test first with a limited set of reports to ensure everything works as expected.
2. Double-check your data sources — mismatches or missing credentials are common issues.
3. Use clear naming conventions for your export file (with timestamp) so you know which export is which.
4. Keep a backup of your export file in a safe location.
5. Make sure the target SSRS server is compatible in terms of version and features.
6. Check permissions: the account you use must have sufficient rights on the source SSRS items.
7. Learn how to migrate SSRS report server items from one report server to another.

The post Download all SSRS Reports from Report Server appeared first on AzureOps.

In this article, we will see how to compare Azure SQL database schema using sqlpackage.exe and generate a delta script that shows the differences in a controlled and repeatable way. The approach and flow are similar to the DACPAC-based comparison strategy discussed earlier on AzureOps.

Why use sqlpackage for database comparison?

sqlpackage.exe is a command-line utility provided by Microsoft that works with DACPAC and BACPAC files. Using sqlpackage, you can:

• Compare two databases using DACPACs
• Generate a deployment (delta) script
• Control destructive changes explicitly
• Automate comparisons in CI/CD pipelines

For Azure SQL Database scenarios, this method is especially useful when direct schema comparison tools are not available or when automation is required.

Creating a DACPAC

To compare database schemas using sqlpackage, you first need a DACPAC file, which represents the database schema.

You can create a DACPAC using sqlpackage.exe, SSMS, or Visual Studio. For a quick, step-by-step guide covering all methods, refer to this article.

Installing sqlpackage Before You Begin

Before you can compare two Azure SQL database schemas using sqlpackage, you need to install the sqlpackage command-line utility on your machine. sqlpackage.exe is the same tool that Powers the DACPAC deployments discussed in this site’s previous article on deploying DACPACs to Azure SQL Database.

Here are the recommended ways to install sqlpackage, depending on your environment:

Option 1 — Install as a .NET Global Tool (Cross-Platform)

The easiest and most modern way to install sqlpackage on Windows, macOS, or Linux is using the .NET SDK tool installer. This gives you the sqlpackage command directly on your PATH. Run below command in command prompt.

dotnet tool install --global Microsoft.SqlPackage

If you already have it installed and want to update to the latest version, run:

dotnet tool update --global Microsoft.SqlPackage

This method works well for local development and automation scripts, including PowerShell and CI/CD pipelines.

Option 2 — Download Standalone Zip (Windows / macOS / Linux)

If you don’t use the .NET SDK or prefer a self-contained download, Microsoft also publishes standalone builds of sqlpackage:

1. Visit the official SqlPackage download page on Microsoft Docs.
2. Download the appropriate zip for your OS.
3. Extract and place the folder somewhere on your system (e.g., C:\tools\sqlpackage).
4. Add the folder containing sqlpackage.exe to your system PATH so you can call it from any terminal.

This method is useful if you want to avoid installing .NET tools or need to bundle sqlpackage with deployment scripts.

High-level approach

The comparison process consists of three simple steps:

1. Export both Azure SQL databases to DACPAC files
2. Use sqlpackage.exe with /Action:Script
3. Review the generated delta script before applying it

In this article, we focus on step 2, assuming you already have DACPAC files for both databases.

Sample scenario

Let us assume the following setup:

• Source (baseline) database: sales-test-db
• Target (to be aligned) database: sales-prod-db

Our goal is to compare Azure SQL Database schema and generate a SQL script that shows what changes are required to make Production match Test.

Sample sqlpackage command

Below is a sample sqlpackage.exe command to compare two DACPAC files and generate a delta script.

sqlpackage.exe ^
  /Action:Script ^
  /SourceFile:"C:\Dacpacs\sales-test-db.dacpac" ^
  /TargetFile:"C:\Dacpacs\sales-prod-db.dacpac" ^
  /TargetDatabaseName:"sales-prod-db" ^
  /OutputPath:"C:\Dacpacs\sales_test_vs_prod_delta.sql" ^
  /p:DropObjectsNotInSource=True

In case you want to use PowerShell ISE, you can use below script.

# Path to sqlpackage.exe
$sqlPackagePath = "C:\Program Files\Microsoft SQL Server\160\DAC\bin\sqlpackage.exe"

# DACPAC paths
$SourceDacpacPath = "C:\Dacpacs\sales-test-db.dacpac"
$TargetDacpacPath = "C:\Dacpacs\sales-prod-db.dacpac"

# Target database name
$TargetDatabaseName = "sales-prod-db"

# Output script path
$OutputScriptPath = "C:\Dacpacs\sales_test_vs_prod_delta.sql"

# Publish options
$DropObjectsNotInSource = "True"

# Execute sqlpackage
& $sqlPackagePath `
    /Action:Script `
    /SourceFile:$SourceDacpacPath `
    /TargetFile:$TargetDacpacPath `
    /TargetDatabaseName:$TargetDatabaseName `
    /OutputPath:$OutputScriptPath `
    /p:DropObjectsNotInSource=$DropObjectsNotInSource

This command does not apply any changes. It only generates a SQL script that you can review and execute manually if needed.

Understanding each parameter

Let us break down all the parameters used in the command.

/Action:Script

Specifies that sqlpackage should generate a deployment script instead of publishing changes directly to a database. This is the safest option when comparing environments like Test and Production.

/SourceFile

Path to the source DACPAC file. This represents the desired state of the database.

/SourceFile:"C:\Dacpacs\sales-test-db.dacpac"

In our example, the Test database schema is treated as the source of truth.

/TargetFile

Path to the target DACPAC file. This represents the database you want to compare against.

/TargetFile:"C:\Dacpacs\sales-prod-db.dacpac"

The generated script will contain changes required to make the target match the source.

/TargetDatabaseName

Logical name of the target database.

/TargetDatabaseName:"sales-prod-db"

This parameter is mandatory for the Script action, even when you are comparing DACPAC-to-DACPAC.

/OutputPath

Specifies where the generated delta script should be written.

/OutputPath:"C:\Dacpacs\sales_test_vs_prod_delta.sql"

Always review this script carefully before executing it in Production.

/p:DropObjectsNotInSource

Controls whether objects that exist in the target but not in the source should be dropped.

/p:DropObjectsNotInSource=True

• True – Generates DROP statements for extra objects in the target
• False – Preserves objects that exist only in the target

⚠️ Use this option with caution, especially for Production databases.

Common additional publish parameters

Depending on your requirements, you may also consider these commonly used parameters:

• /p:BlockOnPossibleDataLoss=False
• /p:IgnorePermissions=True
• /p:IgnoreRoleMembership=True
• /p:ExcludeObjectTypes=Users;Logins
• /p:ExcludeSchemaValidation=True

These options help fine-tune the comparison and avoid unwanted differences.

Best practices

• Always generate a script first (/Action:Script)
• Review the delta script line by line
• Never auto-apply changes to Production without validation
• Store DACPACs and scripts in source control
• Use the same approach in CI/CD pipelines for consistency

Conclusion

Comparing two Azure SQL databases using sqlpackage.exe is a reliable and automation-friendly approach. By working with DACPAC files and generating delta scripts, you gain full visibility and control over schema changes before they reach Production.

This method fits well into modern DevOps workflows and provides a safe alternative to manual or GUI-based comparisons.

If you regularly manage schema changes across multiple environments, sqlpackage should be a core part of your database deployment tool.

Pro tips
1. If you want to generate BACPAC file of an Azure SQL database, you can refer to this post

See more

The post Compare Azure SQL Database Schema Using sqlpackage appeared first on AzureOps.

In this case study, we examine how Leidos, USA , completed an AWS SSRS migration involving more than 80+ SSRS reports, despite having no connectivity between the source SSRS server and the AWS environment.

Background: AWS SSRS Migration with Network Isolation

Leidos was modernizing its infrastructure by moving workloads from an on-premises data center to AWS. Their legacy SSRS server (Windows Server 2016) was scheduled for decommissioning.

Over the years, the server had accumulated:

• 80+ SSRS reports
• Deep folder hierarchies
• Shared data sources

Due to security policies, the on-prem SSRS environment and AWS were completely disconnected, making a traditional SSRS migration approach impossible.

This made the project a textbook example of a disconnected SSRS migration.

Key Challenges in Disconnected SSRS Migration

• No direct network access between on-prem SSRS and AWS
• Inability to use live source-to-target SSRS migration
• Risk of missing reports, folders, or shared data sources
• Manual redeployment not feasible for large SSRS estates
• Need for a safe backup before decommissioning

Solution: File-Based SSRS Migration to AWS

To address these challenges, Leidos used SSRS Reports Migration Wizard in Standalone Mode, leveraging its offline / file-based SSRS migration capability.

This approach is ideal for:

• AWS SSRS migration
• Air-gapped or disconnected SSRS environments
• Secure enterprise networks

AWS SSRS Migration Process (Step-by-Step)

Step 1: Export SSRS Reports from On-Prem Server

On the source SSRS server, the tool:

• Automatically discovered reports, folders, and shared data sources, subscriptions, roles etc.
• Displayed the full SSRS hierarchy for validation
• Exported all selected items into a single migration file

During export:

• Individual .rdl files were generated for each SSRS report
• Folder structure and metadata were preserved

This created a complete offline SSRS backup, a key requirement in regulated environments.

Step 2: Transfer Migration File to AWS (Disconnected Network)

Since the environments were disconnected:

• The migration file was securely transferred using approved methods
• No firewall changes or temporary network access were required

This step highlights the core benefit of disconnected SSRS migration to AWS.

Step 3: Import SSRS Reports into AWS Environment

On the AWS-hosted SSRS server:

• The migration file was imported
• Folder hierarchy and shared resources were recreated
• Data source connections were updated for AWS databases

After import, all SSRS reports were available for validation.

AWS SSRS Migration Results

• 80+ SSRS reports successfully migrated to AWS
• No network connectivity required between environments
• Folder hierarchy and report dependencies preserved
• Minimal downtime
• No manual report recreation

The migration was completed smoothly despite being a fully disconnected SSRS migration.

Additional Benefit: SSRS Backup and Disaster Recovery

An unexpected advantage of the file-based approach was backup:

“The tool creates .rdl files for each report… making it an easy way to back up SSRS reports, data sources, and folders.”

This makes the solution useful not only for AWS SSRS migration, but also for:

• SSRS backup
• Disaster recovery
• Compliance and audit scenarios

Why This Approach Works for AWS SSRS Migration

• Designed for disconnected and air-gapped networks
• Supports offline SSRS migration to AWS
• Preserves full SSRS hierarchy
• Generates reusable .rdl files
• Suitable for enterprise security requirements

Read full customer testimonial on the Visual Studio Marketplace.

Watch a quick demo

The post SSRS Migration Case Study: Migrating SSRS Reports in a Disconnected Environment appeared first on AzureOps.

Use Case – Imagine this scenario:

• You have a main transactional database named app-db hosted on Azure SQL Server app-db.database.windows.net.
• You also have a reference or lookup database named source-db, hosted on a separate Azure SQL Server: source-server.database.windows.net.

You want your app-db to query the table dbo.external_table from the source-db — without importing or copying the data. The goal is to enable live, read-only access to shared reference data across databases in a secure and manageable way.

Prerequisites
Before diving into the setup, ensure the following:
1. Azure SQL Databases: Both the source and target databases should be Azure SQL Databases.
2. Same Region: Ensure both databases are in the same Azure region to minimize latency.
3. User Credentials: A SQL user say (ext_table_user) must exist in the source database with the necessary permissions to access the target table.

Why Create Separate user in the Source Database?

The ext_table_user is a SQL user in the source database that the target database uses to authenticate and access data. This user must have the necessary permissions (e.g., SELECT) on the target table.

Creating a dedicated user for external access enhances security by allowing you to:

• Limit Permissions: Grant only the necessary permissions to this user.
• Monitor Access: Track and audit activities performed by this user.
• Revoke Access Easily: If needed, you can revoke this user’s access without affecting other users.

Fow these steps to how to grant access to Azure SQL database.

How to Setup Cross Database Access in Azure SQL

Follow the below quick steps to setup cross database access in Azure SQL database.

Step 1: Create a Master Key in the Target Database

The master key is essential for encrypting credentials used in external data sources.

-- Execute in the target database

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'YourStrongPasswordHere';

Skip this if SELECT * FROM sys.symmetric_keys WHERE name = '##MS_DatabaseMasterKey##' already returns a row.

Step 2: Create a Database Scoped Credential

This credential will be used to authenticate against the source database.

-- Execute in the target database

CREATE DATABASE SCOPED CREDENTIAL ext_table_user
WITH IDENTITY = 'ext_table_user',
     SECRET = 'ActualPasswordOfExtTableUser';

Step 3: Define the External Data Source

This step establishes a connection to the source database.

-- Execute in the target database

CREATE EXTERNAL DATA SOURCE LinkedAzureSQLDB
WITH (
    TYPE = RDBMS,
    LOCATION = 'source-server.database.windows.net',
    DATABASE_NAME = 'source-db',
    CREDENTIAL = ext_table_user
);

Ensure: Replace 'source-server.database.windows.net' and 'source-db' with your actual server and database names.

Step 4: Create the External Table

Now, define the external table in the target database to reference the table in the source database.

-- Execute in the target database

CREATE EXTERNAL TABLE dbo.external_table (
    [ID] NUMERIC(18, 0) NOT NULL,
    [list_id] INT NOT NULL,
    [type_id] INT NOT NULL,
    [description] VARCHAR(50) NULL
)
WITH (
    DATA_SOURCE = LinkedAzureSQLDB,
    SCHEMA_NAME = 'dbo',
    OBJECT_NAME = 'external_table'
);

Note: The schema and object names should match those in the source database.

Step 5: Query the External Table

With the setup complete, you can now query the external table as if it were local:

-- Execute in the target database

SELECT TOP 10 * FROM dbo.external_table;

Performance Tip: Monitor query performance, as cross-database queries may have higher latency.

Pro tips:
1. Use Managed Identities: For enhanced security, consider using Azure Managed Identities instead of SQL authentication.
2. Monitor Performance: Regularly monitor the performance of cross-database queries to ensure they meet your application’s requirements.
3. Secure Credentials: Store sensitive information, like passwords, securely using Azure Key Vault.
4. Elastic query feature in Azure SQL is still in preview.

By following this guide, you can efficiently set up cross databse query in Azure SQL, enabling seamless cross-database querying while maintaining security and performance.

See more

The post Cross Database Query in Azure SQL Database appeared first on AzureOps.

You write the query, run it, catch a missing condition, tweak the join, test again—repeat until it’s right. SSMS 21 brings Copilot into that loop.

TL;DR:

• SSMS 21 now includes built-in Copilot—no extensions. Just require connection to your Azure OpenAI deployment (like GPT-4o).
• Works only with SQL Server connections (not SSIS, SSAS, or SSRS).
• Runs in read-only mode—won’t execute any DML or modify data.
• Can generate queries, fix broken SQL, and suggest optimizations.
• Supports prompts like: “fix this query,” “optimize for performance,” or “generate insert script.”
• Ideal for SQL developers who want help writing, debugging, or learning better query patterns—without giving up control.

Installation: Copilot Comes Built-in

The installer for SSMS 21 clearly shows that Copilot is not an afterthought—it’s front and center. Once you launch the installer, you’ll notice the “Copilot Integration” checkbox enabled by default. This means no manual setup is required post-install. It’s part of the core experience now.

First Run: Setting Up Your Azure OpenAI Keys

Once SSMS launches, you’ll be prompted to connect Copilot to your Azure OpenAI setup.

In the first prompt, you’ll be asked to provide:

• Azure OpenAI service endpoint
• Azure OpenAI deployment
• Azure OpenAI API key

If you haven’t already created this in Azure, it’s a quick process: deploy a model, generate a key, and you’re good to go. we see how this information is pasted into SSMS.

It’s a one-time step, and once entered, Copilot starts responding instantly within SSMS.

To get an Azure OpenAI deployment name for SSMS Copilit, we need Gen AI model. That’s the engine powering your Copilot. GPT-4o is optimized for speed and real-time interaction, making it well-suited for something as dynamic as SQL writing and analysis.

If you already use GPT-based models in Azure, you can reuse the same deployment. If not, create a new one and pick GPT-4o or other depending on availability.

Which Connections Are Supported?

As of now, Copilot in SSMS works only with SQL Server connections—whether it’s a local database or Azure SQL.

It does not support:

• SQL Server Integration Services (SSIS)
• SQL Server Analysis Services (SSAS)
• SQL Server Reporting Services (SSRS)

So if you’re connected to an SSIS or SSAS instance, you won’t see Copilot suggestions. It’s focused purely on Transact-SQL (T-SQL) scenarios for now.

Read-Only Mode – No Live Data Changes

Copilot works in a read-only mode inside SSMS for GOOD.

It will not execute updates, deletes, or any data-modifying queries on its own. It doesn’t have permissions to alter databases or run DML commands. You remain in full control.

That said, it can generate update, insert, and delete queries for you, which you can review, tweak, and run manually. This helps reduce the risk of accidental changes while still speeding up development.

Quick Demo: Fixing a Broken Query

I pasted a malformed SELECT query into SSMS. Copilot immediately offered a fix and even explained what was wrong.

Few Prompt Examples: Result Accuracy

In below example, we asked Copilot to generate a complex query involving filters, aggregates, and joins. The result was accurate and ready to run with minimal edits.

the same query was further optimized by Copilot after being prompted with: “Make it efficient.” It introduced indexing suggestions and added a WITH (NOLOCK) hint—something even experienced developers can forget.

In another example, we asked Copilot another question on a different query context (another database connection), and it just worked fine.

These examples show that Copilot isn’t just copying boilerplate SQL—it understands context and best practices.

Should You Use This?

If your daily work involves writing or reading SQL, then yes—this is probably the most useful update to SSMS in years.

Here’s what it helps with:

• Writing long queries faster
• Understanding joins and filters
• Fixing syntax issues
• Learning better SQL patterns
• Generating stored procedure templates
• Drafting DML scripts (but not running them automatically)

What It Won’t Do (Yet)

Let’s be clear:

• It won’t connect to SSIS/SSAS/SSRS
• It won’t execute anything that modifies data
• It won’t automatically run DDL/ DML code it suggests

This is intentional, for safety and audit reasons. Think of it as a smart assistant—not a trigger-happy automation engine.

A Note on Privacy and Control

Copilot integrates directly with your Azure environment, so you control what it accesses and shares. It processes your prompts and data securely within your subscription. According to Microsoft, it doesn’t store any query logs outside your environment, which helps meet compliance requirements for enterprise users.

SSMS 21 doesn’t just add Copilot—it integrates it naturally into the flow of writing, editing, and reviewing SQL. It’s fast, context-aware, and doesn’t get in the way.

Pro tips:
1. While it’s good to have Copilot like features in SSMS 21, it seems to have lost some very important features like Import Export Wizard for databases like Azure SQL.
2. Learn how to build data agent in Microsoft Fabric.

See more

The post SSMS 21 Copilot: Here’s How It Works appeared first on AzureOps.

Why Use Managed Identity with Azure SQL?

Storing passwords in configuration files is risky. Managed Identity solves this problem by:

• Eliminating Secrets → No passwords, no connection strings with credentials.
• Centralized Identity Management → Uses Azure AD authentication for consistency.
• Least Privilege Principle → Assigns only the required SQL permissions.
• Automatic Rotation → No need to update or rotate credentials manually.

This makes it the recommended authentication method when connecting Azure Functions to SQL Database.

Prerequisites:
Before implementing, ensure you have:
1. An Azure subscription.
2. An Azure SQL Database already created.
3. An Azure Function App (Python runtime).
4. Azure CLI or Portal access.

This guide assumes you already have a basic understanding of creating an Azure Function. If you need a refresher, please refer to our previous article on How to Create a Python Azure Function.

Let’s now see how to connect Python Azure Function to Azure SQL database using managed identity authentication. In this example we will fetch data from a public API and securely write it to an Azure SQL Database table..

Step 1: Set Up Your Azure SQL Database

Creating WeatherData Table

In this guide, we’ll simulate fetching weather data from an API and storing it in Azure SQL.

Run the following SQL script inside your Azure SQL database:

CREATE TABLE WeatherData (
    Id INT PRIMARY KEY IDENTITY(1,1),
    City VARCHAR(100),
    Temperature DECIMAL(5,2),
    Humidity INT,
    ForecastDate DATETIME
);

Step 2: Enabling Managed Identity for Azure Function

INavigate to your Function App in Azure Portal.

Under Settings → Identity, enable System Assigned Managed Identity.

Azure will create an identity in Microsoft Entra representing your Function.

Step 3: Grant the Managed Identity Access to Azure SQL

Configuring Azure Entra Admin

To allow Managed Identity to authenticate, assign an Azure Entra admin for your SQL server.

1. Go to Azure Portal → SQL Server → Active Entra Admin.
2. Assign an Azure Entra user/group as the admin.
3. Save changes.

Grant the permissions

Now, connect to to your Azure SQL Database using the Entra ID authentication. You need to grant the Managed Identity permission to write to the database. Use the following T-SQL commands, replacing <your-azure-function-name> with the name of your function:

CREATE USER [your-azure-function-name] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datawriter ADD MEMBER [your-azure-function-name];

• CREATE USER creates the identity inside SQL.
• ALTER ROLE gives write permissions to insert/update/delete.

Learn how to grant access to Azure SQL databases in this post.

Step 4: Configure Application Settings

In the Function App Environment variables, define following variables.

• SqlConnectionInfo → Server=<your-sql-server>.database.windows.net;Database=<your-db>;
• WEATHER_API_URL → https://api.open-meteo.com/v1/forecast?latitude=60.17&longitude=24.94&hourly=temperature_2m,relative_humidity_2m
• TIMER_SCHEDULE → 0 * * * * * (Runs every hour).

Step 5: Writing Python Azure Function Code

Now, it’s time to write the code that will perform the data fetching and insertion. For this example, we’ll use a Python HTTP-triggered function and the requests and pyodbc libraries. You will also need the azure-identity package to handle the Managed Identity authentication.

1. Installing Required Packages

Add to requirements.txt:

azure-functions
requests
pypyodbc

2. Write the function code (__init__.py):

import azure.functions as func
import logging, os, requests, pypyodbc

app = func.FunctionApp()

@app.timer_trigger(schedule="%TIMER_SCHEDULE%", arg_name="myTimer")
def load_weather_data_to_sql(myTimer: func.TimerRequest):
    if myTimer.past_due:
        logging.info("The timer is past due!")

    try:
        url = os.getenv("WEATHER_API_URL")
        response = requests.get(url)
        data = response.json().get("current", {})
        
        temperature = data.get("temperature_2m")
        humidity = data.get("relative_humidity_2m")
        city = "Berlin"

        conn = get_sql_connection()
        cursor = conn.cursor()
        cursor.execute(
            "INSERT INTO WeatherData (City, Temperature, Humidity, ForecastDate) VALUES (?, ?, ?, GETDATE())",
            (city, temperature, humidity)
        )
        conn.commit()
        cursor.close()
        conn.close()
        logging.info("Weather data inserted successfully")

    except Exception as e:
        logging.error(f"Error: {e}")

def get_sql_connection():
    conn_info = os.getenv("SqlConnectionInfo")
    parts = dict(item.split("=",1) for item in conn_info.split(";") if "=" in item)
    server, db = parts.get("Server"), parts.get("Database")
# Depending on the python version, select appropriate ODBC Driver. For latest version 3.12, use ODBC Driver 18. For previous versions, try ODBC Driver 17.
    conn_str = f"DRIVER={{ODBC Driver 18 for SQL Server}};Server={server};Database={db};Authentication=ActiveDirectoryMsi;"
    return pypyodbc.connect(conn_str)

Step 6: Testing the Integration

Running Function Locally

• Use Azure Functions Core Tools.
• Set local.settings.json with required env variables.
• Test the API call and SQL insertion.

Deploying to Azure

• Push code to Azure Function App.
• Check logs in Application Insights or Log Stream.
• Common Issues and Troubleshooting.

Best Practices for Secure and Scalable Integration

• Use least privilege for SQL roles.
• Store configs in Azure Key Vault.
• Monitor using Azure Monitor + Application Insights.
• Implement retry logic for transient failures.

FAQs

Conclusion

By following these steps, you’ve securely connected a Python Azure Function to an Azure SQL Database using Managed Identity. This approach avoids hardcoding credentials, ensures automatic rotation, and aligns with cloud security best practices.

With this foundation, you can extend the Function to handle more APIs, perform ETL pipelines, or automate reporting tasks, all while staying secure and compliant.

Pro tips:
1. Always prefer pypyodbc in Functions to avoid dependency issues.
2. Use retry policies when inserting data into SQL.
3. Keep Functions lightweight, offload heavy processing to Azure Data Factory or Microsoft Fabric.
4. If scaling out, validate SQL performance with connection pooling.
5. Learn how to connect to Azure SQL from Azure Data Factory using managed identity.

See more

The post Connect Python Azure Function to Azure SQL Using Managed Identity appeared first on AzureOps.

In this post, I’ll walk you through how I built a Fabric Data Agent on top of the standard AdventureWorksDW dataset, and how you can too, even if you’re a complete beginner.

TL;DR

Microsoft Fabric’s Data Agent lets you ask questions about your data in natural language; no SQL, DAX, or visuals required. Think of it like a chat-based analyst that already knows your data model and never sleeps. This article walks you through building a Data Agent on top of AdventureWorksDW, writing agent instructions, adding data sources, and exploring advanced use cases like AI Foundry and multi-agent systems. By the end, you’ll be able to create your own interactive AI analyst in under 30 minutes.

Prerequisites:
1. You must have access to Microsoft Fabric Capacity specifically F2 or higher.
2. Only workspaces with Fabric-enabled capacity will show the “AI Agent” option in the “+ New” menu.
3.Your Fabric admin must enable the Data Agent preview in the Tenant Settings within the Microsoft Fabric Admin Portal. if you don’t have admin rights, contact your admin.

How to Create a Data Agent in Microsoft Fabric

If you’ve never done this before, don’t worry. Here’s a simple step-by-step guide.

Step 1: Open the Microsoft Fabric Workspace

1. Go to https://app.fabric.microsoft.com.
2. Select or create a new Workspace where your Lakehouse is located.

Step 2: Create a Lakehouse (if not already done)

1. Click New > Lakehouse and give it a name (e.g., demolakehouse).
2. Add your data using Shortcuts:
   • Go to the Tables pane inside the Lakehouse.
   • Click Add Shortcut > OneLake data.
   • Browse and select the relevant tables (e.g., from AdventureWorksDW).

I used the classic AdventureWorksDW dataset, the same one you’ve probably seen in BI demos. Instead of importing tables manually, I used OneLake Shortcuts, which connect existing data without duplicating it.

Step 3: Create the Data Agent

1. In your workspace, click New > Data agent (preview).
2. Choose the Lakehouse where your data is stored. You can also choose semantic model in case you have created semantic model on top of your lakehouse.
3. Give your agent a name (e.g., Sales Insights Agent).
4. Click Create — this opens the agent configuration screen.

Step 4: Add a Data Source to the Data Agent

Once the agent is created, you’ll need to give it instructions and connect it to your data.

1. Inside the agent editor, go to the Data Sources tab.
2. Click + Add data source and choose the Lakehouse as shown in the image below.

Step 5: Add the Agent Instructions

1. Go to the Agent Instructions tab.
2. Provide instuctions for the data agent about it’s goal and responsibilities.

Goal:
Assist users in analyzing sales, customers, geography, and product performance.

Key Relationships:
- FactInternetSales ➡ ProductKey ➡ DimProduct ➡ Subcategory ➡ Category
- FactInternetSales ➡ CustomerKey ➡ DimCustomer ➡ Geography
- FactInternetSales ➡ OrderDateKey ➡ DimDate

Ask me things like:
- Top-selling categories last year?
- Sales trend in Q1 2024?
- Which cities had highest average order size?

Answer in charts, tables, or summaries where helpful.

Step 6: Add the Data Source Instructions

1. Add the data source instruction to let data agent understand your data model.

yamlCopyEditname: AdventureWorksDW_Shortcut
type: Lakehouse
tables:
  - name: DimCustomer_shortcut
    description: Customer demographics and keys
  - name: DimDate_shortcut
    description: Calendar date dimension
  - name: DimProduct_shortcut
    description: Product attributes
  - name: DimProductCategory_shortcut
    description: Categories of products
  - name: DimProductSubcategory_shortcut
    description: Subcategories of products
  - name: DimGeography_shortcut
    description: Country, state, and city details
  - name: FactInternetSales_shortcut
    description: Sales facts including sales amount, quantity, and dates

Step 7: Test the Agent and fine tunning

Start asking questions to the agent like;

1. List top 10 cities by internet sales in last available 12 months.

2. List top 5 customers who made the highest purchases in the latest available year:

Notice that it also provides the SQL query it has executed on the lakehouse to get the required output.

If the data source and instructions are set correctly, the agent should respond with meaningful tables or summaries. In case you observe issues in the responses, you may need to fine tune the AI instructions and test again.

When Should You Use Data Agents?

If you’re already using:

• A well-modeled star schema
• Lakehouse tables or Delta format
• Power BI reports or semantic models
• Microsoft Fabric workspaces with clean relationships

Then a Data Agent will act like a bridge between your data and your business users. No technical barrier — just questions and answers.

Integrations and Advanced Use Cases

What makes Fabric Data Agents truly powerful is not just that they can answer questions — but that they can plug into larger AI and data ecosystems. Here are a few ways to take your agent to the next level.

1. Integration with Azure AI Foundry

Microsoft Azure’s AI Foundry allows you to orchestrate LLM-driven pipelines, combine ML models with data operations, and deploy custom copilots. Your Data Agent can be used here in multiple ways:

• As a ready knowledge base within Foundry apps
• To summarize and explain insights from streaming or batch pipelines
• As a modular AI skill within a larger orchestrated flow

For example, you could use the agent to automatically generate weekly sales summaries and send them via email to business users — no dashboards needed.

2. Use in Multi-Agent Systems with Copilot Studio

Microsoft recently announced integration of Fabric data agent with Copilot Studio. This means data agent also supports multi-agent patterns where different agents work together, each specializing in their role.

Your Data Agent can act as:

• A domain expert (e.g., Sales Agent, Inventory Agent)
• A knowledge base that other agents query
• A collaborative AI alongside others like a document reader, chatbot, or metric generator

Example: Multi-Agent Use Case

Imagine a scenario where you’ve built:

• A “Sales Insights Agent” (based on the Sales model)
• A “Customer Sentiment Agent” (that reads survey data or feedback documents)
• A “Decision Support Agent” (that aggregates insights from both)

Now, a user asks the Decision Support Agent:
“Should we invest more in red-colored bikes for Q3 promotions?”

Here’s what happens behind the scenes:

1. The Sales Agent looks up sales trends for red bikes from your Data Agent.
2. The Sentiment Agent checks recent customer feedback about product quality or color preferences.
3. The Decision Agent combines both and generates a recommendation — backed by data and context.

This makes your Data Agent a building block in a broader AI ecosystem, not just a standalone tool.

Final Thoughts

Data Agents in Fabric aren’t just experimental toys; they’re fully capable assistants for real business scenarios. Whether you’re a data engineer, analyst, or decision maker, you’ll find value in being able to converse with your data.

For me, this agent worked perfectly with the AdventureWorksDW model and started answering meaningful business questions within minutes, no DAX, no Power BI visuals, no joins to write.

This service is currently in preview. It does not currently render charts. Hopefully, future updates will enable it to generate Power BI level visuals on the fly.

See more

Pro tips:
1. Learn how to integrate Microsoft Copilot in SQL Server Management Studio 21.

The post Data Agent in Microsoft Fabric – Here’s How it Works appeared first on AzureOps.

Traditionally, migrating SSIS Catalog, especially when dealing with encrypted sensitive data, could be a complex affair. One of the major hurdles was the perceived need to know the SSISDB encryption key from the source server. This key is crucial for decrypting sensitive data stored within the catalog. If this key was lost, unknown, or not easily accessible, the SSIS Catalog migration process could become a nightmare, often leading to manual reconfiguration or even data loss.

This is where tools like the SSIS Catalog Migration Wizard truly shine, revolutionizing how we approach SSIS Catalog migrations, particularly concerning sensitive data and environment-specific configurations.

SSIS Catalog Migration Wizard: A Secure and Streamlined Solution for SSIS Data

The SSIS Catalog Migration Wizard is a powerful and user-friendly tool designed to simplify the process of moving your SSIS Catalog between SQL Server instances. Its most significant advantage when it comes to sensitive data is its ability to handle encrypted information without requiring the user to possess the SSISDB encryption key from the source server. Beyond sensitive data, it offers critical features for managing environment and parameter values during the transfer.

How it addresses sensitive data and configuration concerns during SSIS migration:

• No SSISDB Encryption Key Required: This is the paramount feature. The Wizard intelligently extracts the necessary components, including encrypted sensitive data, from the source SSISDB and correctly re-encrypts them on the destination SSISDB using the destination’s encryption key. This means you don’t need to go through the arduous process of retrieving, backing up, or restoring the source SSISDB encryption key. This drastically reduces the risk of exposing sensitive data and simplifies the SSIS Catalog migration significantly.
• Seamless Re-encryption: The Wizard handles the decryption and re-encryption process behind the scenes. When an SSIS package with sensitive data is migrated, the Wizard ensures that this data is correctly encrypted with the destination server’s SSISDB encryption key, maintaining the integrity and security of your sensitive information.
• Replace Environment Variable and Parameter Values: A significant pain point in manual migrations is updating countless environment variables and parameter values to match the new environment. The SSIS Catalog Migration Wizard offers the crucial capability to define and replace these values during the migration process itself. This means you can proactively map old server names, database names, file paths, or other environment-specific settings to their new counterparts.
• Reduced Manual Intervention: By automating the handling of sensitive data and providing the ability to replace environment-specific values, the Wizard minimizes the need for manual intervention post-migration. This reduces the chances of human error that could lead to data exposure, corruption, or broken package execution. You won’t have to manually update connection strings, package parameters, or environment variables one by one, saving significant time and effort in SSIS data migration and configuration.
• Comprehensive Migration: Beyond sensitive data and configurable parameters, the Wizard migrates your entire SSIS Catalog structure, including projects, environments, references, etc. This ensures a consistent and complete transfer of your SSIS deployment.

Proactive Strategies for Seamless Variable and Parameter Value Replacement

To leverage the Wizard’s capability for variable and parameter value replacement effectively, consider SCMW’s proactive suggestions:

• Simplified Updating: The wizard streamlines the process of updating environment variables and parameter values to match the target environment during migration.
• Configurable Key-Value Pairs: Users can set up specific key-value pairs to replace existing values in both environment variables and SSIS project/package parameters.
• Intelligent Suggestions: The wizard features a “Suggest” button that provides recommendations for replacements based on the chosen “Replace Scope,” aiding users in configuring the correct values.
• Detailed Review: Users can review the specific environment variables and parameters that will be affected by clicking on the “Ref” column, which displays detailed mappings, ensuring accuracy and control over the migration process.

This functionality ensures that SSIS packages and projects are correctly configured for the new environment without manual intervention, saving time and reducing potential errors.

Best Practices for a Secure SSIS Catalog Migration

While the SSIS Catalog Migration Wizard significantly simplifies the process, it’s still crucial to adhere to best practices for a truly secure migration:

1. Plan Thoroughly: Before initiating any migration, have a clear plan. Identify all projects, environments, sensitive data, and environment-specific configurations involved.
2. Backup Everything: Always perform full backups of both the source and destination SSISDB databases before starting the migration. This provides a rollback point in case of any unforeseen issues. You can consider backing us SSISDB to .scmv file using SSIS Catalog Migration Wizard.
3. Test in a Non-Production Environment: If possible, perform a test migration to a non-production environment first. This allows you to identify and resolve any potential issues, including incorrect parameter replacements, before impacting your production systems.
4. Validate Post-Migration: After the migration is complete, thoroughly validate that all packages and connections are functioning correctly. Pay special attention to packages that use sensitive data and those relying on replaced environment variables to ensure they are executing as expected.
5. Secure Destination Environment: Ensure your destination SQL Server instance and SSISDB are configured with appropriate security measures, including strong passwords, least privilege principles, and network security.

Conclusion

Migrating SSIS Catalogs, especially those containing sensitive data and requiring intricate environment-specific adjustments, can be a complex undertaking. However, with the advent of tools like the SSIS Catalog Migration Wizard, this process has become significantly more manageable and secure. By eliminating the need to know the source SSISDB encryption key and automating the re-encryption process, coupled with the powerful ability to replace environment variable and parameter values during migration, the Wizard empowers administrators to perform SSIS migrations with confidence. This ensures the integrity and confidentiality of their sensitive data while proactively managing configuration changes throughout the transition. Embrace this powerful tool to streamline your next SSIS Catalog migration, and experience a truly hassle-free and secure transfer.

Installation

SSIS Catalog Migration Wizard can be installed as an extension to:

1. Visual Studio 2017, Visual Studio 2019 & Visual Studio 2022.
2. SSMS 18, 19, 20, 21(preview)
3. Standalone tool.

More details are available in this tutorial.

See more

The post Transferring Sensitive Data During SSIS Catalog Migrations to Another Server appeared first on AzureOps.

What Is SSRS Reports Migration Wizard?

SSRS Reports Migration Wizard is a tool that enables you to:

• Migrate reports, shared datasets, and shared data sources
• Copy subscriptions (standard and data-driven)
• Review and update connection strings and credentials
• Migrate between servers, folders, or environments
• Export and import SSRS items using a lightweight .SRMW file format
• Perform offline review and validation before actual migration

The wizard is available as a Visual Studio extension and as a standalone tool.

Prerequisites:
Before Migrating SQL Server Reports
1. You have access to both source and target SSRS servers.
2. Your user account has:
-at least Browser role on the source–
-at least Publisher role on the target
If you’re unsure how to grant access, follow the instructions in the Granting Access Guide.

Use Cases

• Migrating from dev to test/prod environments
• Consolidating multiple SSRS servers
• Backing up and archiving SSRS artifacts
• Migrating from the old SSRS report server to the new server.
• Migrate SSRS reports to Power BI report server.

Step-by-Step SSRS Report Migration Process

Follow the below steps to achieve SSRS report migration from one server to another.

Step 1: Select the Source

Choose your source SSRS server or a .SRMW file created from a previous export.

Step 2: Select the Target

Provide connection details for the destination SSRS server. You can migrate to a different server, or a different folder on the same server.

Step 3: Choose Report Items to Migrate

Select specific folders, reports, datasets, and data sources using a tree view. Filters and checkboxes make large-scale selection easy.

Step 4: Update Data Source Connection Strings – Migrating SSRS Data Sources

SSRS Reports Migration Wizard includes an optional step to update data source connection strings during the migration process. This is particularly useful when migrating reports and datasets from a source server to a target server that uses different connection details.

Fetch Data Sources

On this screen, click the Fetch Data Sources button. The wizard will scan the selected SSRS items (from the previous screen) and populate a grid with all connections that can be updated.

Each row represents a unique connection used by your reports or shared data sources.

View and Manage Connections

The grid displays the Extension, Connection String, and Credential Retrieval method for each data source. Click the Edit link in the Manage column, which allows you to modify the connection.

Convert to shared data sources if connection exists – If this option is selected, the wizard will attempt to convert embedded data sources in reports to shared data sources during deployment, provided a shared data source with the same connection details is available in the selected SSRS items for deployment.

Update Properties

When you click Edit, a new dialog box appears (labeled “Manage Connection Properties”). Here you can:

• Review the Shared Data Source(s) using this connection and Report(s) using this connection as an embedded data source.
• Modify the Connection String.
• Specify Credentials (e.g., Windows credentials or a user name and password) under “Log into the data source”.
• Click Save to apply the changes.

Important Notes

• The wizard cannot retrieve passwords from embedded or shared data sources on the source report server. The wizard will guide you to convert them ot shared data sources and provide credentials.
• The Dependent Objects shown in the grid are those that have a connection embedded within them. These objects are directly using this connection.
• The changes you make are not committed to the target server until the wizard completes the migration.
• If no connections are found for the selected items, a message box will inform you that there are no connections available for update.

Step 5: Review Changes

The wizard shows a migration summary with new, changed, or skipped items. You can export this list or proceed with the migration.

Step 6: Finish and Validate

Once migration is complete, a final summary screen shows migrated item counts and logs. You can rerun this process anytime.

Installation

SSRS Reports Migration Wizard can be installed as an extension to:

1. Visual Studio 2017, Visual Studio 2019, Visual Studio 2022 & Visual Studio 2026.
2. SSMS 18, 19, 20, 21, 22
3. Standalone tool.

Standalone Usage

Don’t use Visual Studio? You can still run the wizard as a standalone tool:

1. Download the .vsix from here.
2. Rename the .vsix to .zip and extract it.
3. Launch SSRS.Reports.Migration.Wizard.exe.

Pro tips:
1. Learn how to export all SSRS objects from the report server using SSRS Reports Migration Wizard.

The post How to Migrate SSRS Reports from One Server to Another (Step-by-Step) appeared first on AzureOps.