AD迁移需明确目标与范围，验证信任及兼容性，选用ADMT、PowerShell或第三方工具，确保SIDHistory、权限及属性映射一致，并通过分阶段试迁与验证保障无缝过渡。
明确迁移目标与范围
批量迁移前先确认要迁移的对象类型：仅用户、还是连同组、ou、gpo一并迁移；是否需保留原始sid、密码、权限及moss/sharepoint中的映射关系。若目标是跨林或跨域（如从 old.corp 迁至 new.corp），必须提前验证双向信任、dns解析、防火墙端口（389/636/ldap(s)）及域功能级别是否兼容。不支持低于 windows 2000 混合模式的旧环境直接迁移。
选择合适工具链
根据场景复杂度和安全要求选型：
- ADMT（Active Directory Migration Tool）：微软官方推荐，适合跨域/跨林迁移，支持SID历史保留、密码迁移（需启用密码导出服务PES）、组成员身份复制、GPO关联迁移；需在源域和目标域分别安装，并配置信任与PES服务。
-
PowerShell + Get-ADUser / New-ADUser：适合轻量级、属性可控的同步，例如只同步姓名、邮箱、部门、电话等非敏感字段；可配合
Export-Csv和Import-Csv实现模板化导入；但无法原生迁移密码或SID，需额外调用copypwd或启用Set-ADAccountPassword（需管理员重置）。 -
LDIFDE / CSVDE：系统内置命令行工具，适用于纯结构导出（如OU、用户DN、sAMAccountName），但不支持密码、加密属性或二进制数据（如照片）；
ldifde -f export.ldf -s dc01 -d "ou=Sales,dc=corp,dc=com" -r "(objectClass=user)"是常用导出语法。 - 第三方工具（如 ADManager Plus）：提供图形化向导、冲突检测、预演模式、自动备份与回滚；适合无脚本能力或需审计留痕的中大型环境。
关键属性映射与一致性保障
用户属性不是简单复制，需按业务逻辑映射：
- 登录名（sAMAccountName）和UPN（userPrincipalName）需在目标域唯一，建议统一策略（如“姓.名@new.corp”）并提前校验重复；
- 邮箱地址（mail）通常需同步至目标Exchange或IDaaS平台，可利用PowerShell自动拼接：
$_.GivenName + "." + $_.Surname + "@new.corp"； - 组织单位（OU）路径需预先在目标域创建好，迁移时指定目标OU DN（如
"ou=Marketing,dc=new,dc=corp"）； - 若涉及MOSS/SharePoint权限延续，必须同步SIDHistory（ADMT默认启用），否则用户将丢失所有已有站点权限；
- 自定义属性（如 employeeID、ipPhone）需在目标域Schema中存在且权限开放，否则会静默跳过。
执行与验证要点
迁移不是一次运行就结束，而是分阶段闭环操作：
- 先在测试OU小批量试迁（如5个用户），检查属性值、登录能力、邮箱收发、权限继承是否正常；
- 启用详细日志（ADMT的日志级别设为“详细”，PowerShell加
-Verbose和Start-Transcript）； - 迁移后立即验证：用新账号登录域、访问共享文件夹、打开SharePoint页面、检查ADSI Edit中objectSid与sIDHistory字段；
- 增量同步场景（如对接IDaaS或钉钉），需开启AD回收站并配置USNChanged筛选，确保删除、禁用、属性变更事件能被捕获；
- 正式迁移后，建议保留源域对象至少30天（禁用而非删除），并更新DNS、组策略链接、服务主体名称（SPN）等依赖项。
