Forum Discussion
Advocate IVError 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!
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.
14 Replies
- lbendlin
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.
AMD0791Update 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.
- AMD0791
I've done that as well. We have a call in a few days. Just want to have as much info as possible.
- AMD0791
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
- lbendlin
Wait what - are you not a tenant admin?
- Nasif_Azam
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:
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.
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.
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.
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:
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- AMD0791
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.
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.- AMD0791
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.
