Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Get Fabric Certified for FREE during Fabric Data Days. Don't miss your chance! Request now

Reply
AMD0791
Advocate III
Advocate III

Error moving Premium workspace to Fabric: VNetMigrationNotAllowedException

We have migrated quite a few workspaces from our Premium capacity to our Fabric capacity in a different region.  We've had a few errors related to the known issues for fabric items, but the message was clearly about the fabric items, and we're working through those few use cases.

 

I am now trying to move one workspace and the message is not helpful:

"This workspace does not support migration to another region or capacity type".  There is nothing to give us a clue about WHY it doesn't support migration.  The fabric items were deleted and there are no large semantic models in the workspace.

 

When I monitor the network traffic via the F12 developer tools , I see this error on the call to move the workspace:

"PowerBICapacityFoldersMigrationVNetMigrationNotAllowedException"

 

VNet migration?  I can't find any any datasets connected to a VNet gateway.  Most of the datasets aren't actively connected to any gateway because they are mostly manually updated by republishing.

 

Any ideas on what to look at for this?

 

Thank you!

2 ACCEPTED SOLUTIONS
lbendlin
Super User
Super User

Don't waste your time. Since you have a Pro license you can open a Pro ticket at https://admin.powerplatform.microsoft.com/newsupportticket/powerbi

Let them figure it out.

View solution in original post

Update for anyone in the future:  Microsoft had to fix it.

 

They described the root cause as a "residual Virtual Network (VNet) connection that had been deleted, but  the workspace still retained traces of those connections".  Their product team had to remove the residual VNet references from the backend.  

 

I don't know how any workspaces had a VNet connection, but whatever the product team did worked and I was able to move the workspace from P1 to F64.  We actually later had a 2nd workspace with the same glitch and they were able to fix it pretty quickly the same way. 

View solution in original post

14 REPLIES 14
v-hjannapu
Community Support
Community Support

Hi @AMD0791,

Thank you  for reaching out to the Microsoft fabric community forum.
Thank you @Nasif_Azam for your reply regarding the issue.

check if the Premium capacity has any VNet settings turned on in the Admin Portal, even if you haven’t used it before. Sometimes these settings can cause issues. Next, use the Power BI REST API like GET /groups/{groupId  to see if there’s any hidden stuff in the workspace that’s causing the migration error. Also, make sure all deleted Fabric items or dataflows are completely removed, as leftover data can create problems. If you’re in a hurry, try copying the reports and datasets to a new Fabric workspace as a workaround.

If the response has addressed your query, please Accept it as a solution and give a 'Kudos' so other members can easily find it

Best Regards,
Harshitha.

Thank you for the suggestion.  Are there specific settings you have in mind to check for VNET?  I didn't find any settings in Tenant Admin labeled Vnet or Virtual.

 

I have used the API to export the list of datasets and datasources and didn't find any hidden items.

 

We're trying to avoid recreating everything in a new workspace since there are a lot of users expecting their saved links to work.  I'd also like to nail down the problem in case we encounter it again.

Hi @AMD0791,

The VNetMigrationNotAllowedException error you are encountering is likely related to a VNet configuration at the capacity level rather than the Tenant Admin level. Please review the original Premium capacity settings in the Admin Portal by navigating to Admin Portal > Capacity settings > [Your Premium Capacity] > Settings. Check the Networking or Gateway connections sections for any existing VNet gateway or Private Link configurations, as these can impact migration even if they were previously set up but not actively used.

Additionally, verify whether the workspace contains any deleted Fabric items, such as dataflows or pipelines, that may still be in the Recycle Bin. These items can sometimes prevent migration. Open the workspace, go to View > Recycle Bin, and permanently remove any remaining items.

Please Accept as solution if this meets your needs and a Kudos would be appreciated.
Best Regards,
Harshitha.




Thank you for your very specific instructions.  However, I could not find any reference to networks or gateways on the capacity settings page.  It also seems that a capacity level setting would have prevented me from moving the first 50 workspaces that I've moved from our P1 to Fabric.

 

Likewise, I cannot find the "recycle bin" for the workspace.  I can't find any reference to that even existing in Power BI.  If you have screenshots showing how to get there, that would be great.

 

Thank you!

Hi @AMD0791
 I’m really sorry for the earlier confusion there’s no "Recycle Bin" for Power BI workspaces. Once a workspace is deleted, it’s permanently gone and can’t be restored unless you have a backup or saved a copy somewhere else.
about the capacity settings  you're correct again. There are no network or gateway options on the capacity settings page that would stop workspaces from being moved. That’s why you were able to move the first 50 workspaces without any issue.

Please check this link and give it an upvote, as Microsoft prioritizes items based on the number of votes.
Recover deleted workspace artifacts - Microsoft Fabric Community


vhjannapu_1-1751009144681.png

 

Thanks for your patience and understanding.
Regards,
Harshitha.

Dare I say "hallucinations"?   Workspaces definitely do not have recycle bins accessible to users.  You need to raise an extremely urgent ticket with Microsoft within 30 days of a deletion event to have them restore that in the backend. Be prepared for lots of heated discussions.

Nasif_Azam
Super User
Super User

Hey @AMD0791 ,

Based on the error message PowerBICapacityFoldersMigrationVNetMigrationNotAllowedException, it seems the issue might not be about active VNet connections at the dataset level, but rather a VNet integration setting tied to the workspace or the capacity it's currently in. Few things to check:

 

  1. VNet Integration at the Capacity Level: Is the source Premium capacity using VNet data gateway or VNet integration? Even if your datasets aren’t actively using it, if the workspace inherits from a capacity with VNet integration enabled, that could block migration.

  2. Check for Legacy Dataflows or Linked Entities: Sometimes dataflows or linked datasets retain metadata that causes migration to fail. Even deleted items can leave traces until fully purged.

  3. Use Power BI REST API to Inspect the Workspace: The Power BI Admin REST API can help check for hidden dependencies or configurations not visible in the UI.

  4. Try Cloning to a New Workspace: As a workaround, if urgent, consider cloning the reports and datasets to a new Fabric-backed workspace (export/import PBIX or use deployment pipelines) to bypass the migration blocker.

 

For Detailed Information:

VNet data gateway in Power BI

Power BI workspace migration to Fabric

Power BI Admin REST API – Get Workspaces

Deployment Pipelines in Power BI

 

 

If you found this solution helpful, please consider accepting it and giving it a kudos (Like) it’s greatly appreciated and helps others find the solution more easily.


Best Regards,
Nasif Azam



Did I answer your question?
If so, mark my post as a solution!
Also consider helping someone else in the forums!

Proud to be a Super User!


LinkedIn

Thank you for your extensive reply. Unforrtunately, the links are all 404 right now.  

I will look into the VNet at the capacity level, although I would expect that issue would affect a lot more workspaces.  TO my knowledge, we have never used a VNet with this capacity.

lbendlin
Super User
Super User

Don't waste your time. Since you have a Pro license you can open a Pro ticket at https://admin.powerplatform.microsoft.com/newsupportticket/powerbi

Let them figure it out.

Update for anyone in the future:  Microsoft had to fix it.

 

They described the root cause as a "residual Virtual Network (VNet) connection that had been deleted, but  the workspace still retained traces of those connections".  Their product team had to remove the residual VNet references from the backend.  

 

I don't know how any workspaces had a VNet connection, but whatever the product team did worked and I was able to move the workspace from P1 to F64.  We actually later had a 2nd workspace with the same glitch and they were able to fix it pretty quickly the same way. 

FYI - my initial call with support was less than spectacular.  The first request if we could move our F64 capacity to the same region as our P1 capacity.  Uh -- that's a pretty big ask and not really a "lets try something" option!  

They apparently could not gather anything helpful from the RequestID, etc from the error message.  They also did not have any specific guidance for exactly what that error might mean.  They wanted screenshots of the entire workspace lineage to prove that no datasets are connected to a VNET gateway.  Uh... I looked at that. 🙄

 

The one potentially helpful suggestion was to try to move the workspace to PRO, and then moved it again to F64.  I have not tried that yet.

 

This process of moving 100+ workspaces has really highlighted the shortcomings of their API responses and the ridiculousness of locking down the settings page so tight.  Since I don't own all these datasets, I can't see all the things on the settings pages to look for anomalies.  And there are a lot of things that aren't clearly exposed in the API.  They should allow workspace admins to at least SEE all the settings for all the datasets!

 

Next on the list:

* Confirm none of the models are set up for OneLake integration.  

* Remove these dataset owners from the VNET gateway, even though none of the datasets are configured to use it.  Maybe one of the datasets that isn't mapped to a gateway is somehow being flagged as using a VNET gateway?  I noticed on a screenshare that the VNET gateway was at the top of the list of gateways for one of these developers.

* Have the owners go ahead and set up those datasets to use our on-prem gateway

* Change cloud SQL endpoint connections to use a shared cloud connection instead of Default SSO

 

Wait what - are you not a tenant admin?

I am a tenant admin and a workspace admin for 90% of the workspaces.  But when I view the settings page for a dataset configured by someone else, I can't see all the settings.  It's been so helpful that the recently updated things so non-owners can at least see the gateway settings to be able to set those, or see how they're configured before a takeover.  But there's still a lot of things that are greyed out.

 

If I'm missing some magic ability to see all of this, please let me know!!  I know I could do a takeover, but I'd rather not because then people think I'm responsible for that data! 😆

I've done that as well.  We have a call in a few days.  Just want to have as much info as possible.

Helpful resources

Announcements
Fabric Data Days Carousel

Fabric Data Days

Advance your Data & AI career with 50 days of live learning, contests, hands-on challenges, study groups & certifications and more!

October Power BI Update Carousel

Power BI Monthly Update - October 2025

Check out the October 2025 Power BI update to learn about new features.

FabCon Atlanta 2026 carousel

FabCon Atlanta 2026

Join us at FabCon Atlanta, March 16-20, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.