Implemented scope
Implemented within documented permissions, object or content types, service limits, options, and validation paths.
Use the public material below to evaluate fit, identify unsupported assumptions, and prepare a more useful migration discussion.
These resources are public technical summaries. Environment-specific permissions, procedures, test cases, and runbooks are produced for an approved assessment or engagement.
Compare Active Directory, Entra ID, Exchange, SharePoint, OneDrive, and Teams scope.
See how ready, review, remediation, and deferred findings become an execution scope.
Review content handling, operational metadata, secrets, responsibility, and required egress.
Understand discovery, mapping, frozen scope, execution, reconciliation, and evidence.
See which topology, volume, fidelity, deployment, and responsibility variables affect scope and price.
Standalone technical guides written for delivery teams. No sign-up required.
Where ADMT stops, what a modern replacement must cover, and how to compare without inheriting hidden risk.
Phase-by-phase: discovery, assessment, mapping, dry runs, pilot waves, validation, rollback, and decommission.
Identity, Exchange, SharePoint, OneDrive, Teams, domain cutover, and validation gates in delivery order.
How SID history preserves resource access, what it requires, where it breaks, and when to restamp ACLs instead.
Each guide states the implemented path, required permissions, source and destination readiness, service-specific workflow, validation evidence, and manual boundary.
Status applies only to the stated capability, prerequisites, and exclusions. A supported connection or object type does not make every artifact in that Microsoft workload supported.
Implemented within documented permissions, object or content types, service limits, options, and validation paths.
Implemented, but availability depends on Microsoft API approval, Graph endpoint stability, licensing, tenant state, or completion of another workload.
Implemented with environment-dependent behavior that requires representative validation, success criteria, change control, and rollback ownership.
Assigned to native tooling or an administrator, or not automated in the current release. It must not be represented as part of the supported path.
BridgeAD public material follows four rules so technical evaluators can distinguish product behavior from delivery assumptions.
The recommended pilot verifies the operating loop before expanding object volume or workload breadth.