Using SSMA v10.0 on AzureSQL Managed Instance

Hi Hansen, David-E,

Thanks for sharing the details, I understand how confusing this behavior can be.

What you’re encountering is a known limitation related to how SQL Server Migration Assistant for Sybase interacts with Azure SQL Managed Instance.

SSMA performs some internal validation queries during connection and schema assessment, and in this case it is referencing master.sys.databases. While Managed Instance is highly compatible with SQL Server, it does enforce certain restrictions around system metadata access and cross-database references. As a result, queries that work on full SQL Server may fail on Managed Instance with the error you’re seeing.

To move forward, I recommend first updating SSMA to the latest version, as newer builds include fixes and improvements for Azure SQL compatibility. You can download it here: https://learn.microsoft.com/sql/ssma/sybase/sql-server-migration-assistant-for-sybase

Also, ensure that the connection in SSMA is made directly to the target user database rather than relying on the default master database context, as this can help avoid triggering restricted metadata queries.

If the error occurs during schema assessment or validation, you can try proceeding directly with schema conversion and migration. In many cases, the migration itself completes successfully even if validation encounters this limitation.

If the issue continues, a practical workaround is to use SSMA primarily for schema conversion, then deploy the generated schema using SSMS or Azure Data Studio, and handle data migration separately using tools such as Azure Data Factory or bcp.

This behavior aligns with documented differences between SQL Server and Managed Instance, particularly around system views and metadata access. You can review more details here: https://learn.microsoft.com/azure/azure-sql/managed-instance/transact-sql-tsql-differences-sql-server

Additional reference on system catalog views: https://learn.microsoft.com/sql/relational-databases/system-catalog-views/catalog-views-transact-sql

SSMA does support Azure SQL Managed Instance, but certain internal metadata queries like those referencing master.sys.databases can hit platform-specific limitations. Updating SSMA and adjusting the connection and workflow typically resolves the issue.

If the problem persists, collecting SSMA logs and sharing them would help with further investigation.

Hello Hansen, David-E,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your SSMA v10.0 on AzureSQL Managed Instance having issue.

The issue is not with SSMA v10.0 itself, it is caused by using SSMA for an unsupported or suboptimal migration scenario (SQL Server > Azure SQL Managed Instance), combined with potential networking and compatibility constraints.

First, confirm the migration scenario: for SQL Server to Azure SQL Managed Instance, do not rely on SSMA as a primary tool. Microsoft recommends Azure DMS or backup/restore methods instead - https://learn.microsoft.com/en-us/data-migration/sql-server/managed-instance/guide.

Next, ensure proper connectivity to the Managed Instance using a private endpoint or VPN, since MI is not publicly exposed. Validate access with a simple test:

sqlcmd -S <mi-hostname>,1433 -U <user> -P <password>

https://learn.microsoft.com/en-us/azure/azure-sql/database/connectivity-architecture.

Then assess feature compatibility before migration to avoid failures from unsupported components like FILESTREAM or certain CLR features. Use Data Migration Assistant (DMA) for this:

dma.exe /Assessment

https://learn.microsoft.com/en-us/sql/dma/dma-overview.

Choose the correct migration method: Azure Database Migration Service (online/offline) or native backup/restore to Azure Blob storage. Example restore command:

RESTORE DATABASE db FROM URL = 'https://<storage>.blob.core.windows.net/<container>/db.bak'

https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/sql-server-backup-to-url.

Ensure authentication is compatible with Managed Instance by using SQL authentication or Microsoft Entra ID instead of Windows-only logins. This avoids login mapping and access failures https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-overview.

Finally, use SSMA only for supported sources like Oracle, MySQL, or Access, not SQL Server migrations to MI. Following the correct toolchain eliminates the root failure instead of troubleshooting SSMA unnecessarily - https://learn.microsoft.com/en-us/sql/ssma/sql-server-migration-assistant.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.