You shouldn't try to fix this by changing the ACLs on System Volume Information. I wouldn't take ownership of or reset the permissions on the System Volume Information\Dedup folder, since that could damage the deduplication metadata.
First, confirm that the Data Deduplication feature is installed and that the migrated volume is recognized correctly:
Get-DedupVolume
Get-DedupStatus -Volume D: | Format-List *
Get-DedupMetadata -Volume D:
Also check the Deduplication Operational log for errors. Specifically, Microsoft recommends checking the dedup status, metadata, event logs, and filesystem health whenever files become inaccessible after a migration.
If the volume was moved to another server, make sure the Data Deduplication role is installed:
Install-WindowsFeature FS-Data-Deduplication
Make sure deduplication/data access is enabled for the volume.
The Dedup chunk-store ACLs should not need to change as part of the AD domain migration, since Data Deduplication lets applications and users access optimized files normally via the deduplication filter.
If either the Get-DedupStatus command or the event log shows chunk-store/metadata errors, do not make any more permission changes; instead, work from a known-good backup or raise a Microsoft support case. Microsoft expressly cautions against altering the protected Dedup metadata and advises using supported backup and restore or direct disk migration methods when dealing with deduplicated volumes.
Sharing these references with you:
Troubleshoot Windows Server Data Deduplication
Understanding Data Deduplication
Get-DedupStatus PowerShell reference
Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.