Validation Checklist

Use this page as the final go/no-go gate after completing the detailed prerequisite procedures:

• Overview
• Entra Application Registration
• Provisioning Package
• AD Disjoin Account Preparation

The full rationale for each item appears in the prerequisite pages above.

---

Go / No-Go Rule

Do not continue to portal onboarding, production scheduling, or broad deployment unless every required item is checked, validated, and owned.

If an item does not apply to your migration scenario, mark it as N/A in your project records and document why it does not apply.

---

1. Scenario and Scope Validation

• Migration scenario is confirmed: AD-to-Entra, Hybrid-to-Entra, or Tenant-to-Tenant.
• Source tenant, target tenant, and post-migration join tenant are confirmed.
• Tenant-to-Tenant source and target responsibilities are documented.
• Device pilot group and production migration waves are defined.
• Unsupported devices are excluded or remediated before migration.
• Devices using unsupported profile types are excluded or remediated.
• Source object cleanup timing is agreed and documented.

---

2. Licensing Validation

• Microsoft Intune licenses are assigned and active.
• Microsoft Entra ID P1 or P2 licenses are assigned and active.
• Tenant-to-Tenant migrations have licensing confirmed in both source and target tenants.
• Target devices run a supported Windows edition: Pro, Enterprise, or Education.
• Windows Home devices are excluded or remediated.

---

3. Device Readiness Validation

• Devices are running Windows 10 or Windows 11.
• Devices meet minimum hardware requirements.
• TPM 2.0 or higher is available where required by the organization.
• Disk health and OS health are validated on representative devices.
• Devices have stable power and network connectivity for the migration window.
• Local user profiles are healthy, local, and not temporary or corrupted.
• Roaming profiles, mandatory profiles, FSLogix, Citrix UPM, VDI, and profile-container technologies are excluded or remediated.
• Workgroup-only devices are excluded unless separately approved for a supported scenario.
• BitLocker recovery access is confirmed where BitLocker is enabled.
• Local administrator or LAPS recovery access is confirmed.

---

4. Microsoft Entra and Intune Validation

• Microsoft Intune is the MDM authority.
• Intune automatic enrollment is configured for the target users or groups.
• Users or package account are allowed to join devices to Microsoft Entra ID.
• Windows enrollment restrictions allow the target devices.
• Device-limit restrictions will not block enrollment.
• Enrollment Status Page behavior is reviewed for the target devices.
• Microsoft Defender for Endpoint re-onboarding behavior is reviewed, if applicable.
• Target tenant device enrollment and compliance behavior are validated during pilot migration.

---

5. Conditional Access and MFA Validation

• MFA requirements for device join and registration are reviewed.
• Bulk enrollment / package account exclusions are configured where required.
• Conditional Access policies requiring compliant device state are reviewed.
• Conditional Access policies requiring hybrid-joined device state are reviewed.
• Trusted-location restrictions are reviewed for migration networks.
• Sign-in risk, user risk, and platform restrictions are reviewed.
• Cross-tenant access restrictions are reviewed for Tenant-to-Tenant migrations.
• Temporary exclusions are documented with owner, approval, and removal date.

---

6. Entra App Registration Validation

• App registration is created in the correct tenant or tenants.
• Required Microsoft Graph application permissions are added.
• Feature-dependent permissions are added where enabled, including LAPS retrieval, group restoration, or configuration profile handling.
• Admin consent is granted for all required permissions.
• Application (client) ID and Directory (tenant) ID are recorded securely.
• Client secret value is stored in an approved secrets vault or password management system.
• Client secret expiry date and rotation owner are documented.
• Entra app validation script returns PASS.
• Failed validation results are remediated before continuing.

---

7. Provisioning Package Validation

• Provisioning package is created in the correct tenant for the migration scenario.
• Tenant-to-Tenant package is created in the destination target tenant.
• Bulk enrollment token expiry is recorded.
• Migration waves are scheduled to complete before package expiry.
• Provisioning package is stored as a sensitive credential.
• Package is not stored in email, chat, public shares, tickets, source control, or unmanaged endpoint folders.
• Package is validated on a standalone non-production test device.
• dsregcmd /status confirms AzureAdJoined : YES after validation.
• Device appears in Microsoft Entra admin center as Microsoft Entra joined.
• Device appears in Intune admin center as an enrolled Windows device, if Intune enrollment is expected.
• Test device object is cleaned up or reset according to the lab process.
• Package is not uploaded to Opsole Migrate until validation succeeds.

---

8. AD Disjoin Account Validation

• AD disjoin account requirement is confirmed for the migration scenario.
• Dedicated standard user account is created for AD disjoin operations.
• Domain Admin credentials are not used unless explicitly approved.
• Account password is stored securely.
• Account expiry, password expiry, and lockout status are reviewed.
• Delegation is applied to the correct OU or OUs containing target devices.
• Delegation is applied at the lowest approved OU level.
• Cross-forest source AD requirements are validated, if applicable.
• Portal credential format DOMAIN\username is confirmed.
• Domain controller reachability is confirmed from representative devices.
• NTLM, GPO, security baseline, and endpoint hardening restrictions are reviewed.
• Manual disjoin validation succeeds on a test device in the same OU scope.

---

9. Network Validation

• Outbound HTTPS 443 is available from representative target devices.
• Required Microsoft endpoints are reachable.
• Required Opsole endpoints are reachable.
• DNS resolution is validated.
• Proxy behavior is reviewed.
• TLS inspection does not break Microsoft or Opsole service access.
• System-level connectivity works without interactive proxy authentication.
• Captive portal networks are not used during migration.
• Network location restrictions are reviewed for device registration and join.

---

10. Security Tooling Validation

• Opsole code-signing certificate trust is configured where required.
• Opsole runtime paths are excluded from real-time scanning where required.
• Opsole executables are excluded from real-time scanning where required.
• Scheduled task creation and execution are allowed.
• SYSTEM-context execution is allowed.
• Provisioning package execution is not blocked.
• No Opsole Migrate runtime files are quarantined during pilot validation.
• EDR isolation actions are paused or controlled during the migration window.

---

11. Application and User Experience Validation

• Representative pilot migrations are completed before production rollout.
• Microsoft 365 Apps sign-in behavior is validated.
• Outlook profile behavior and additional mailbox access are validated.
• OneDrive sync behavior and known folder redirection state are validated.
• Microsoft Teams sign-in and cache behavior are validated.
• VPN client behavior is validated.
• Business-critical line-of-business applications are validated.
• Third-party security, backup, monitoring, and remote support agents are reviewed.
• Services running under user or domain accounts are reviewed.
• Scheduled tasks with saved user credentials are reviewed.
• Pilot validation confirms no identified background process loads the user profile before the protected profile migration phase completes.

---

12. Operational Readiness Validation

• User communication is approved and scheduled.
• Users are instructed not to sign in while the migration banner is displayed.
• Service desk is briefed on expected migration behavior.
• Service desk is briefed on recovery and escalation steps.
• Recovery workflow is understood by support teams.
• Recovery ownership and escalation path are documented.
• Change approval is complete.
• Temporary exclusions have owner and removal date.
• Pilot exit criteria are met.
• Migration status and logs are visible in the Opsole Migrate portal during pilot validation.

---

13. Procedure Sign-off

---

Next Steps

When every required item is checked and signed off, continue with Portal Onboarding - Getting Started.