DMS can’t launch schema conversion.

It seems that the loop persists despite your S3 and IAM configuration being correct. Based on your CloudWatch logs showing All source tree node info size: 0 , the DMS Schema Conversion tool is unable to "see" your SQL Server objects to begin the generative AI process.

Please verify the following three points regarding your Microsoft SQL Server source:

1. Verify SQL Server Version

DMS Schema Conversion typically supports Microsoft SQL Server versions 2012, 2014, 2016, 2017, 2019, and 2022. If you are using an older version (e.g., 2008 R2) or a very new preview release, the metadata extraction will fail to populate the tree, resulting in the "size: 0" error you are seeing in the logs.

Verify: https://docs.aws.amazon.com/dms/latest/userguide/data-providers-sql-server.html

2. Check SQL Server Edition

The edition of your SQL Server can impact metadata visibility:

• Supported: Enterprise, Standard, Workgroup, and Developer editions.
• Potential Issues: The Express Edition often restricts access to certain system metadata, which can prevent DMS from discovering schemas and tables.

Verify: https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.html

3. Permissions for System Views

Even if the connection test is successful, the user credentials stored in AWS Secrets Manager must have specific permissions to read the database catalog:

• Ensure the user has the VIEW ANY DEFINITION permission at the server level.
• Alternatively, ensure the user has explicit access to the sys schemas and INFORMATION_SCHEMA for the specific database you are trying to convert.

Without these permissions, the metadata refresh will return zero objects , causing the "DMS Schema Conversion cannot process your request" error shown in your screenshots. Once these rights are granted, try the "Refresh from database" action again in the Schema Tree.

I think you are correct in your suspicion: DMS cannot connect to Secrets Manager. Without this connection, the schema conversion tool cannot "unlock" the database credentials to see the objects, leading to the "size: 0" error

Regarding "Troubleshooting with Reachability Analyzer"

To perform the test:

• Source: Select Network Interface and find the ENI associated with your DMS Migration Project.
• Destination:

If using an Interface Endpoint: Select the VPC Endpoint for Secrets Manager.

If using the Public Internet: Use the public IP/DNS of the Secrets Manager service.

• Protocol & Port: Set to TCP and Port 443 (HTTPS).
• Goal: The analyzer will identify if a Security Group, Network ACL, or Route Table is blocking the traffic.

Even in a public subnet, communication with AWS Services (like Secrets Manager) can fail for several reasons:

• DNS Resolution: DMS requires the VPC attributes Enable DNS hostnames and Enable DNS support to be set to true to resolve the Secrets Manager endpoint.
• Public IP Requirement: For a resource in a public subnet to communicate with the internet, it must have a Public IP. -> "Enable auto-assign public IPv4 address"
• Security Group Egress: The Security Group attached to the DMS instance profile must allow outbound traffic on Port 443 to the Secrets Manager service.

Can you please also do the following - at least for testing:

• Create a VPC Interface Endpoint for Secrets Manager within the VPC to allow private communication
• Verify IAM Roles: Ensure the DMS role has secretsmanager:GetSecretValue permissions
• Manual Refresh: Once connectivity is fixed, right-click the source in the Schema Tree and select "Refresh from database"

The reason your schema conversion is stuck in EXECUTING without errors is visible in your CloudWatch logs: All source tree node info size: 0.

DMS is not failing due to permissions; it is simply finding zero objects to convert. The Generative AI conversion is a two-step process, and Step 1 (Metadata Extraction) has not populated the "Tree" yet.

Clear Solution Steps:

• Perform a Manual Metadata Refresh: In the DMS Console, go to your Migration Project. In the left-hand navigation (Schema Tree), right-click your source database and select "Refresh from database". You must wait for this to complete until you can actually see your tables/schemas listed in the UI tree.
• Verify Data Provider Permissions: If the refresh still results in size: 0, your database user likely lacks the permissions to read the system catalog (e.g., SELECT on ALL_TAB_COLUMNS in Oracle or INFORMATION_SCHEMA in SQL Server). Ensure the credentials in Secrets Manager have full metadata read access.

"DMS Schema Conversion uses lazy loading to load metadata only as it is needed... make sure to refresh them in your migration project."

source: https://docs.aws.amazon.com/dms/latest/userguide/schema-conversion-refresh.html

• Selection is Key: Once the tree is populated, you must select/check the specific schemas or tables you want to convert before clicking "Launch/Convert". If nothing is selected, DMS processes a list of zero items and stays in a loop.
• Check Bedrock Model Access: The GenAI feature specifically requires Amazon Bedrock model access (Claude 3/3.5) to be manually granted in the Bedrock console within the same region.

In short: Your S3 and IAM setups are correct (as proven by your S3 permission check files). The "silent" hang is purely because the metadata cache is empty. Populate the source tree first, and the conversion will launch immediately.

hey Florian,

thanks for your efforts but it seems none of those is the problem

Microsoft SQL Server 2022 (RTM-CU22-GDR) (KB5072936) - 16.0.4230.2 (X64) Nov 25 2025 23:31:11 Copyright (C) 2022 Microsoft Corporation Standard Edition (64-bit) on Windows Server 2022 Datacenter 10.0 <X64> (Build 20348: ) (Hypervisor) Standard Edition (64-bit)

and for authentication I am using "sa" user

note that the SQL Server is running on EC2 .. same vpc, same subnets as the instance profile

no problem connecting to the sql server running on EC2 using its public address via AWS SCT application

Based on the information provided, it appears you're experiencing an issue with launching schema conversion in AWS DMS. While I can see you've set up the necessary resources, there are a few things to verify:

First, ensure that your IAM roles have the correct permissions. The DMS instance profile needs appropriate permissions to access the S3 bucket, read from AWS Secrets Manager, and perform schema conversion operations. Double-check that the role has policies allowing actions like s3:PutObject, s3:GetObject, and the necessary DMS permissions.

Second, verify that your data providers are correctly configured and that DMS can successfully connect to both your source and target databases. The schema conversion process requires valid connections to assess and convert database objects.

Third, confirm that you're using a supported conversion path. The generative AI feature for schema conversion currently supports specific migration paths: Oracle to PostgreSQL/Aurora PostgreSQL, SQL Server to PostgreSQL/Aurora PostgreSQL, and SAP ASE (Sybase ASE) to PostgreSQL/Aurora PostgreSQL.

Additionally, check that your migration project is in the correct state. The conversion operation can fail if the resource is in an invalid state for starting the conversion process.

Since you mentioned there are no error messages in CloudWatch logs, you might want to check if there are any service quotas being exceeded, particularly around the number of concurrent conversion operations or API rate limits.

If the issue persists after verifying these items, I'd recommend reviewing the complete IAM policy attached to your DMS instance profile and ensuring all required permissions are granted, as access-related issues are common causes of conversion failures.
Sources
Converting database objects with generative AI - AWS Database Migration Service
Viewing your database migration assessment report for DMS Schema Conversion - AWS Database Migration Service
start_metadata_model_conversion - botocore 1.42.50 documentation

Hey Florian,

no objects have been loaded at all ..

hey Florian,

thanks for your efforts to help me solve the issue, but it seems non of the things above is the root cause

SQL Server is 2022 Standard Edition .. I am using "sa" user - all possible privileges .. so it should not be a problem ..

Can it be related to DMS not able to connect to secrets manager