Reassigning Microsoft Fabric Capacities in Bulk: Don’t Let an Expiring Trial Catch You by Surprise

Reassigning Microsoft Fabric Capacities in Bulk: Don’t Let an Expiring Trial Catch You by Surprise

Automation

by Erwin | Jul 14, 2026

Table of Contents

Avoid Losing Fabric Items When a Trial Expires: Bulk Reassign Workspaces Between Capacities Using Fabric CLI

With the summer holiday season approaching, many organizations are running Microsoft Fabric workloads on trial capacities that were originally created for proof-of-concepts, workshops, or development activities. What often gets overlooked is that Fabric trial capacities eventually expire, and when they do, the consequences can be significant. According to Microsoft Fabric community guidance, you have only seven days after trial expiration to reassign your workspaces to an active capacity. After that retention period, non-Power BI Fabric items are removed according to the retention policy.

For a tenant with a handful of workspaces, manually reassigning capacities might be manageable. But what if you need to migrate dozens or even hundreds of workspaces from Capacity A to Capacity B?
Fortunately, there is an easy way to automate this process.

Why Reassign Capacities?

There are several common scenarios:

  • A Fabric Trial capacity is about to expire.
  • You purchased a new Fabric capacity and want to move workloads.
  • You're consolidating capacities to reduce costs.
  • You're separating development, test, and production workloads.
  • You're moving workspaces to a larger SKU due to increased usage.

Whatever the reason, workspace reassignment is a straightforward administrative task that can be automated through the Fabric CLI and Fabric APIs.

The Hidden Risk of Trial Capacities

Many organizations start their Fabric journey on a trial capacity. It works great for evaluations, hackathons, and pilot projects. However, when the trial expires, the clock starts ticking.
Fabric Trail Expire
Microsoft states that after trial expiration, you have a seven-day window to save your Fabric content by assigning the affected workspaces to an active Fabric capacity. If you don't migrate the workspaces assigned to your Fabric trial capacity before your free Fabric trial capacity expires, the workspaces will be moved to Power BI with license mode Pro and you will not be able to use Fabric (non-Power BI) items. Fabric items not moved to a Power BI Premium or Fabric capacity within 7 days after your trial ends may be permanently deleted. If you have Power BI items, they will continue to exist in the workspace. Items that you created in other workspaces not assigned to your Fabric trial capacity will be unaffected.

I've seen customers develop:

  • Lakehouses
  • Notebooks
  • Data Pipelines
  • Dataflows Gen2
  • Semantic Models
  • Warehouse solutions

...only to discover during a holiday period that their trial is expiring.

My advice: don't wait until the last day.

Bulk Migration with Fabric CLI

Instead of opening every workspace manually, you can automate the entire process.

The approach is simple:

  1. Enumerate all Fabric workspaces.
  2. Identify the current capacity.
  3. Optionally filter specific workspaces.
  4. Assign them to the target capacity.
  5. Create a migration report.
  6. Helps you avoid manual workspace-by-workspace administration

tasks = []

filter_set = (
    {w.lower() for w in filter_workspaces}
    if filter_workspaces
    else None
)

workspaces = get_workspaces()

for ws in workspaces["result"]["data"]:

    workspace_name = ws.get("name", "").removesuffix(".Workspace")
    capacity_name = ws.get("capacityName", "")

    # Optional workspace filter
    if filter_set and workspace_name.lower() not in filter_set:
        continue

    # Skip unassigned workspaces
    if capacity_name == "N/A":
        continue

    if assign_capacity_to_all_fabric_workspaces:

        if capacity_name != target_capacity:

            print(f"Moving {workspace_name}  from {capacity_name} to {target_capacity}" )
            result = assign_capacity(workspace_name,target_capacity )
            tasks.append({"Workspace": workspace_name,"Source Capacity": capacity_name,"Target Capacity": target_capacity,"Remarks": result})

        else:
            print(f"{workspace_name} no action needed, capacity already assigned")
            tasks.append({"Workspace": workspace_name,"Source Capacity": capacity_name,"Target Capacity": target_capacity,"Remarks": "Capacity already assigned"})
 
    else:

        if capacity_name == source_capacity:
                        
            print(f"Moving {workspace_name}  from {source_capacity} to {target_capacity}" )
            result = assign_capacity(workspace_name,target_capacity )
            tasks.append({"Workspace": workspace_name,"Source Capacity": capacity_name,"Target Capacity": target_capacity,"Remarks": result})

        else:

            print(f"{workspace_name} skipped current capacity: {capacity_name}" )
            tasks.append({"Workspace": workspace_name,"Source Capacity": capacity_name,"Target Capacity": target_capacity,"Remarks": "Skipped - not on source capacity"})

Check out the script on GitHub and adapt it to your environment:

Check out my GitHub repository for the complete migration script.

Fabric_Tooling/NB_WORKSPACE_CHANGE_CAPACITY

Whether you're cleaning up trial capacities, consolidating environments or moving to a larger Fabric SKU, automation can save a lot of time and reduce the risk of missing a critical workspace.

Why Automation Matters

I've noticed many Fabric environments that started as small experiments and quickly grew into business-critical platforms.

A workspace that started as:

"Let's just test Fabric for a few days"

Can suddenly contain:

  • Production pipelines
  • Business reporting
  • Data engineering workloads
  • Governance processes

When a trial capacity approaches expiration, manually managing dozens of workspaces becomes error-prone.

Automating the migration process provides:

  • Repeatability
  • Traceability
  • Faster execution
  • Lower risk
  • Full reporting

Final Thoughts

If you're using Microsoft Fabric Trial capacities today, take a few minutes to check:

  • Which workspaces are assigned to the trial.
  • When the capacity expires.
  • Whether a long holiday period overlaps with the expiration date.

Remember that Microsoft provides only a limited grace period after trial expiration to save your Fabric items by moving the workspace to an active capacity.

The good news is that moving workspaces from Capacity A to Capacity B can be fully automated. A simple Fabric CLI or REST API script can handle the migration in minutes and help you avoid an unpleasant surprise when you return from vacation.

Tip: Even if you're not currently running a trial, keeping an automated capacity migration script in your Fabric toolbox is a great operational practice. Sooner or later, you'll need it for a capacity upgrade, consolidation, or tenant migration.

Feel free to leave a comment

Using Azure Automation to generate data in your WideWorldImporters database

CASE:

For my test environment I want to load every day new increments into the WideWorldImporters Azure SQL Database with Azure Automation. The following Stored Procedure is available to achieve this.

 EXECUTE DataLoadSimulation.PopulateDataToCurrentDate

@AverageNumberOfCustomerOrdersPerDay = 60,

@SaturdayPercentageOfNormalWorkDay = 50,

@SundayPercentageOfNormalWorkDay = 0,

@IsSilentMode = 1,

@AreDatesPrinted = 1;

For this case I'm going to use Azure Automation to Execute this Stored Procedure on a daily base.

More details on above Stored Procedure can be found here.

In case you don't have a WideWorldImporters database in your Azure environment you can download it from GitHub.

  1. Create an Azure Automation Account
  2. Add module to Azure Automation Account
  3. Adding a SQL Server Credential 
  4. Create a Runbook
  5. Create a Schedule

Create an Azure Automation Account

First of all we need to create an Azure Automation Account in our Azure Environment.

Go to the portal and search for Automation and click op Create

Create Azure Automation

Fill in the details and select the correct subscription and Resource Group.

Create Azure Automation

Click on create and wait for the account to be created. The new Automation Account configuration blade will be opened once the provision is completed.

Add module to Azure Automation Account

The next step is that we need to add the “SQLSERVER” module to our Automation Account.

Select Modules and Browse Galery.

Create Azure Automation

Search for sqlserver Created by matteot_msft.

Create Azure Automation

Then click on Import and OK and wait for the import to complete.

Add SQL Server Credentials

Click on add a Credential, this is a secure way to hold your login name and password that will be used to access the Azure SQL Database.

Create Azure Automation

Add a Credential name AzureSQLDBAutomationAccount and define a password.

Create Azure Automation

If this account is not created in your Azure SQL Database, then you need to add this account as well:

[sql]

--Execute in Master Database

create login AzureSQLDBAutomationAccount with password='Your defined Password'           

--Execute in WideworldImporters Database

create user AzureSQLDBAutomationAccount

for login AzureSQLDBAutomationAccount

with default_schema= dbo

--add user to the dabase role

exec sp_addrolemember  N'db_owner' , N'AzureSQLDBAutomationAccount'
[/sql]

Create a Runbook

The next step is to create a Runbook.

You can Import an existing Runbook or Create a new Runbook.

For now we will Create a new RunBook.

Create Azure Automation

Name = “AzureSQLDB_Run_StoredProcedure”

Runbook Type =”Powershell”

Create Azure Automation

[ps]
param(
# Fully-qualified name of the Azure DB server
[parameter(Mandatory=$true)]

[string] $AzureSQLServerName = 'DBSERVER',

# Name of database
[parameter(Mandatory=$true)]

[string] $AzureSQLDatabaseName = 'DBNAME',

# Name of Procedure 'exec dbo.xxxxxxxx'
[parameter(Mandatory=$true)]

[string] $ProcedureName = 'exec name',

# Credentials for $SqlServerLogin stored as an Azure Automation credential asset
[parameter(Mandatory=$true)]

[string] $SqlCredential
)
$Credential = Get-AutomationPSCredential -Name $SqlCredential
$AzureSQLServerName = $AzureSQLServerName + '.database.windows.net'

$SQLOutput = $(Invoke-Sqlcmd -ServerInstance $AzureSQLServerName -Username $Credential.UserName -Password $Credential.GetNetworkCredential().Password -Database $AzureSQLDatabaseName -Query $ProcedureName -QueryTimeout 65535 -ConnectionTimeout 60 -Verbose) 4>&1

Write-Output $SQLOutput
[/ps]

This a simple Powershell script which can execute a Stored Procedure. More details about the PS Invoke-Sqlcmd can be found here.  You can download the Powershell script from my Github

Save the Runbook and then test the runbook. After you tested your Runbook you can Publish the Runbook

Create Azure Automation

Fill in the requested Parameters as showed in the picture above and click on Start. The requested procedure will be executed.

 

Create A Schedule

That last step is create a Schedule which will run every day to incremental load your data.

Create Azure Automation

 

Create Azure Automation

Define a Name, Schedule Start Time and the Recurrence for the Schedule and click on Create

Create Azure Automation

 

Fill in the requested Parameters and click on Save.

I assume that you have now succeeded in creating an Azure Automation Account with these steps and that you could execute a Stored Procedure in an Azure SQL Database. If you have any questions, leave a message in the comments below. Thanks for reading.

TIP:

To update your database to the current date you have to run this procedure quit  lot of times so create a query where you execute the Procedure 100x times in  a row. The downloaded database has data up to may 2016.

In case you get error regarding the Temporal Tables, check your errors in this blog post. I helped me a lot.

 

I my next blog I will describe how you easily can extract data(full and Incremental) from your WideWorldImporters Database to Azure Data Lake Gen2 with Azure Data Factory.