Phase 3: Plan migration and testing

Once you've gained business buy-in, the next step is to start migrating these apps to Microsoft Entra authentication.

Migration tools and guidance

Use the tools and guidance provided to follow the precise steps needed to migrate your applications to Microsoft Entra ID:

Plan testing

During the process of the migration, your app may already have a test environment used during regular deployments. You can continue to use this environment for migration testing. If a test environment isn't currently available, you may be able to set one up using Azure App Service or Azure Virtual Machines, depending on the architecture of the application.

You may choose to set up a separate test Microsoft Entra tenant to use as you develop your app configurations. This tenant starts in a clean state and won't be configured to sync with any system.

Depending on how you configure your app, verify that SSO works properly.

Authentication type Testing
OAuth / OpenID Connect Select Enterprise applications > Permissions and ensure you've consented to the application to be used in your organization in the user settings for your app.
SAML-based SSO Use the Test SAML Settings button found under Single Sign-On.
Password-Based SSO Download and install the MyApps Secure Sign-in Extension. This extension helps you start any of your organization's cloud apps that require you to use an SSO process.
Application Proxy Ensure your connector is running and assigned to your application. Visit the Application Proxy troubleshooting guide for further assistance.

You can test each app by logging in with a test user and make sure all functionality is the same as prior to the migration. If you determine during testing that users need to update their MFA or SSPRsettings, or you're adding this functionality during the migration, be sure to add that to your end-user communication plan. See MFA and SSPR end-user communication templates.

Troubleshoot

If you run into problems, check out our apps troubleshooting guide and Secure Hybrid Access partner integration article to get help. You can also check out our troubleshooting articles, see Problems signing in to SAML-based single sign-on configured apps.

Plan rollback

If the migration fails, we recommend that you leave the existing Relying Parties on the AD FS servers and remove access to the Relying Parties. This allows for a quick fallback if needed during the deployment.

Consider the following suggestions for actions you can take to mitigate migration issues:

  • Take screenshots of the existing configuration of your app. You can look back if you must reconfigure the app once again.
  • You might also consider providing links for the application to use alternative authentication options (legacy or local authentication), in case there are issues with cloud authentication.
  • Before you complete your migration, do not change your existing configuration with the existing identity provider.
  • Be aware of the apps that support multiple IdPs since they provide an easier rollback plan.
  • Ensure that your app experience has a Feedback button or pointers to your helpdesk issues.

Employee communication

While the planned outage window itself can be minimal, you should still plan on communicating these timeframes proactively to employees while switching from AD FS to Microsoft Entra ID. Ensure that your app experience has a feedback button, or pointers to your helpdesk for issues.

Once deployment is complete, you can inform users of the successful deployment and remind them of any steps that they need to take.

  • Instruct users to use My Apps to access all the migrated applications.
  • Remind users they might need to update their MFA settings.
  • If Self-Service Password Reset is deployed, users might need to update or verify their authentication methods. See MFA and SSPR end-user communication templates.

External user communication

This group of users is usually the most critically impacted in case of any issues. This is especially true if your security posture dictates a different set of Conditional Access rules or risk profiles for external partners. Ensure that external partners are aware of the cloud migration schedule and have a timeframe during which they're encouraged to participate in a pilot deployment that tests out all flows unique to external collaboration. Finally, ensure they have a way to access your helpdesk in case there are problems.

Exit criteria

You're successful in this phase when you have:

  • Reviewed the migration tools
  • Planned your testing including test environments and groups
  • Planned rollback

Next steps