[KevinJump]

Block List only allows element types. Nested Content would use any doc type, so after migration a Block List could point at doc types it can't use, and the customer would have to flip "Is an Element Type" by hand on each one.

What changed

• NestedContentConfigurationMigrator records each ncAlias in the migrations tracking table (key NestedContentElement:{alias}). Data types import before content types, so the record is there in time.
• New NestedContentElementTypeImportingHandler (on uSyncImportingItemNotification) sets Info/IsElement to true in the content type XML before it's deserialized, when the alias is tracked.
• Works for the migrate tab and a plain import (e.g. "Import from file"). Tracking persists, so re-importing the legacy file doesn't flip it back.
• Skips, with a warning, doc types that are allowed at root or already have content nodes, since those are being used as pages.

Not covered here

On a fresh site, a single import still gives Nested Content data types an empty Block List: the config migrator runs before the doc types exist, so it can't resolve ncAlias to a key. The migrate tab avoids this because it imports settings, then All. A plain one-off import needs a second import. Worth a separate fix.

Testing

Builds. Not run end to end. The test site has no Nested Content uSync files, so it needs a v13 export with Nested Content to verify.

🤖 Generated with Claude Code

[KevinJump]

Not needed. A dry run on a fresh v17 site (v17/main, no change) migrated Nested Content to Block List fine with a non-element doc type in the blocks: config and content convert, Umbraco saves both. The content page shows an error in the backoffice until the doc type is set to 'Is an Element Type', and setting it afterwards fixes it. So this is a post-migration step for the user, not worth a handler on every imported node.