How are third-party applications tested during Microsoft 365 migration?

Third-party application testing during a Microsoft 365 migration is a structured business-process check: each external application must still support the tasks users depend on after the tenant, accounts, mailboxes, files or collaboration services have changed. The test should cover technical compatibility, licensing, configuration, records, workflows and operational ownership, rather than treating every application as a simple sign-in test.

Start with an application register. Record every application that uses, receives or produces information connected with Microsoft 365. This may include customer relationship management systems, finance platforms, document management tools, e-signature services, backup products, workflow tools, meeting-room systems and sector-specific line-of-business software. For each application, document:

• the business owner and technical contact;
• the users, groups or departments that rely on it;
• the Microsoft 365 services and information involved;
• the licence type, subscription status and renewal owner;
• the current configuration and any custom workflows;
• the supplier’s supported configurations and migration guidance;
• the consequences if the application is unavailable or produces incorrect results.

This register gives the migration team a way to prioritise testing. A system used for a critical operational process needs a more detailed test plan and formal business approval than a low-impact utility used by a small number of people.

Check compatibility before building test cases. Review whether the application’s current version supports the planned Microsoft 365 configuration, identity model, domains, licensing arrangement and security policies. Suppliers may impose requirements for application registrations, tenant consent, supported authentication methods, API access, mailbox types or SharePoint and OneDrive configurations. A migration can expose unsupported legacy settings that were not visible during normal use, so these requirements should be confirmed before the production change.

Licensing also needs specific attention. A tenant move or change in user allocation may alter which application features are available. Test accounts should reflect the licence combinations used by real staff, including standard users, administrators, shared operational roles and users with restricted access. A successful test performed with an administrator account does not prove that ordinary users can complete the same task.

Build tests around real processes. Technical checks are useful, but they should be supplemented with representative user journeys. Examples include:

• creating a record in one system and confirming that the expected information is available in the other;
• sending an approval through a workflow and confirming that the correct people can review and complete it;
• opening, editing, versioning and restoring a document through the application;
• generating a report that uses Microsoft 365 information;
• processing an email-driven task, including replies, attachments and automated notifications;
• checking calendar, meeting or collaboration features used by the application;
• confirming that audit records, timestamps and ownership details remain meaningful after the change.

Use realistic but controlled sample records. Include normal transactions, incomplete information, duplicate entries, unusually large attachments, special characters and records with restricted visibility where those conditions occur in the organisation. The purpose is to expose handling problems that a basic demonstration may miss, while avoiding unnecessary use of live confidential information.

Separate technical testing from user acceptance testing. The technical team can confirm that an application is configured correctly and that its expected functions operate. Business users must then confirm that the results make sense in practice. They should test the tasks they perform regularly, review generated documents and reports, and verify that approvals, notifications and ownership rules match established procedures.

Assign a named approver for each important application. The approver should record whether the test passed, failed or requires a decision, together with the test date, account used, steps followed, evidence produced and any limitations. This creates an auditable decision rather than relying on informal confirmation that an application “seems to work”.

Test failure and recovery paths as well as successful use. Applications should be assessed for what happens when a service cannot be reached, a user lacks the required licence, an approval is rejected or an automated task cannot complete. Confirm how errors are displayed, where they are logged, who receives alerts and how work can be recovered without creating duplicate records. If the application queues transactions for later processing, verify that the queue behaves correctly when connectivity is restored.

Recovery testing is particularly important for applications that create or update business records. Check whether a failed transaction can be retried safely, whether partial completion is visible and whether the business can identify any records requiring manual review. These checks help distinguish a temporary interruption from silent data loss or duplication.

Use clear entry and exit criteria. Before testing begins, define what must be available, which test accounts and sample records will be used, and who can approve the result. Before the production cutover, agree which defects are blockers, which can be accepted temporarily and which require a documented workaround. A test should not be marked as passed merely because the application opens; the agreed business process must produce the expected result.

Record defects by impact and cause. Typical findings include an outdated application version, an unlicensed user, an incorrect redirect, a missing workflow step, an unexpected change in document ownership, an incomplete notification or an audit trail that no longer identifies the responsible user. Each finding should have an owner, corrective action and retest result. Repeating the relevant test after remediation is essential, particularly where a change affects several applications.

Repeat targeted checks around cutover. Pre-migration testing establishes a baseline, but it does not replace validation after the change. Immediately following cutover, repeat the highest-priority business journeys using representative user accounts. Confirm that new activity is being recorded in the correct location, that scheduled tasks are still operating and that users are not being directed to an old tenant, domain or configuration.

Continue with focused post-migration monitoring for issues that may appear only during ordinary use, such as scheduled synchronisation, overnight reports, periodic licence checks or infrequent approval routes. Review application logs and user-reported faults against the test results. Where a defect is found, preserve relevant evidence before changing the configuration so that the cause can be investigated accurately.

For a small or medium-sized organisation, this approach can be scaled to the importance of each application. The essential principles remain the same: maintain an accurate register, test real processes with suitable user roles, obtain business approval, document exceptions and validate the highest-risk functions again after migration. S2 Technology Group can use this structured approach as part of Microsoft 365 migration planning, helping organisations assess how their wider application estate fits into the change rather than treating migration as a data-transfer exercise alone.