Is Your Microsoft Entra Connect Still Supported? What IT Teams Need to Check Now

Microsoft Entra ID is not expiring. But the software connecting your on-premises Active Directory to it has its own support lifecycle—and an old installation can become a business risk even while users appear to be signing in normally.

For organisations running hybrid identity, Microsoft Entra Connect Sync deserves the same attention as a production server or firewall. It helps keep identities and selected directory changes aligned between the local environment and Microsoft’s cloud. If nobody owns its updates, a quiet background service can become a difficult operational incident.

Microsoft currently lists 23 October 2026 as the end-of-support date for Entra Connect Sync version 2.5.79.0. Several earlier releases have already retired. There is also a separate authentication deadline in April 2027 that requires more than installing an update.

Here is what IT teams should check—and how to approach the change without turning a maintenance task into an identity outage.

Technical information checked against Microsoft documentation on 6 October 2026.

First, identify which product you actually use

Three names are easy to confuse:

• Microsoft Entra ID is the cloud identity service used by Microsoft 365 and other applications.
• Microsoft Entra Connect Sync, previously known as Azure AD Connect, is software installed on a Windows server to synchronise on-premises directory information with Entra ID.
• Microsoft Entra Cloud Sync is a different synchronisation solution, with its own architecture and supported scenarios.

This article concerns Connect Sync. A version retirement does not mean that Entra ID Free, P1 or P2 is expiring, or that every Microsoft 365 customer must replace its identity platform.

If your organisation is cloud-only and does not use Connect Sync, these particular server-upgrade requirements do not apply to you.

Two deadlines—not one

1. The support deadline for your installed version

Microsoft’s release-history table lists these examples:

This is a selected list, not a complete lifecycle inventory. Check your exact build against Microsoft’s current release history, especially if you are reading this after October 2026.

Do not interpret an end-of-support date as a promise that synchronisation will stop at midnight. It means the version has left its supported lifecycle. Microsoft warns that retired versions may stop working unexpectedly and may lack current fixes and service improvements.

Equally, “it still synchronises” is not proof that the installed version is supported.

2. The mandatory authentication deadline: 7 April 2027

Microsoft’s current guidance requires organisations to:

1. Upgrade Connect Sync to version 2.6.84.0 or later.
2. Configure application-based authentication by 7 April 2027.

Microsoft states that synchronisation services will stop working after that date if these requirements are not met because legacy authentication is being retired.

These are two separate checks. Do not assume that installing a qualifying version proves that an existing server has been migrated to the required authentication configuration.

Also, 2.6.84.0 is the stated minimum for this requirement—not a recommendation to ignore later fixes. At the time of this review, Microsoft lists 2.6.92.0 as its latest release. Recheck the current release and known issues when planning your change.

What is the business impact if synchronisation fails?

The first symptoms may be changes that do not arrive where people expect them:

• A newly created on-premises user does not appear in the cloud.
• Group membership or selected directory attributes remain out of date.
• Password changes do not reach the cloud where password hash synchronisation is used and affected.
• Joiner, mover and leaver processes require manual investigation.

The exact effect depends on your configuration. Directory synchronisation and user authentication are related, but they are not the same thing. A synchronisation interruption does not automatically mean every existing user immediately loses Microsoft 365 access.

That distinction matters during an incident. Teams must investigate the actual sign-in method and affected components rather than treating every hybrid identity problem as a complete cloud outage.

For a UAE business with several offices, remote staff or a small IT team, the practical risk is often unclear ownership: the server exists, but nobody has recently checked its build, health, recovery plan or support deadline.

Five checks to make before booking an upgrade

1. Find every Connect Sync server

Identify the active server and any staging servers. Record the installed product version from the server’s installed-applications information, its operating system, and the team responsible for it.

Do not review only the machine currently exporting changes. An old staging server is not a dependable recovery option simply because it remains powered on.

2. Establish a health baseline

Review recent imports, synchronisation runs, exports and errors. Record any existing failures before the change so they are not confused with upgrade problems later.

Confirm how password hash synchronisation, pass-through authentication, federation and writeback features are used in your environment. Not every deployment uses every feature.

3. Document scope and customisation

Capture the forests, domains, organisational-unit filters, custom synchronisation rules and optional features that define your deployment. Export the configuration using Microsoft’s supported process and confirm what your recovery procedure actually covers.

Microsoft warns that directly modified out-of-box synchronisation rules can revert to defaults during an upgrade. Review those changes before proceeding; do not assume every customisation will survive unchanged.

4. Check prerequisites and release notes

Validate the intended release against the current Windows Server, .NET, TLS, database and permissions requirements. Read the known issues and changes between your installed version and the target release.

Download the installer through the Microsoft Entra admin center. Avoid treating an old installer saved on a shared drive as the current recommended version.

5. Agree the validation and recovery plan

Define the maintenance window, expected synchronisation behaviour, decision owner and recovery route. A VM snapshot alone should not be treated as a complete identity recovery plan.

Choose controlled test identities and approved changes. Document how you will prove that the intended objects and attributes synchronise correctly without exposing employee data or changing production access unnecessarily.

In-place upgrade or a staging-server migration?

An in-place upgrade may suit a straightforward deployment whose host and configuration meet current requirements. However, some upgrades can trigger full import and full synchronisation activities, which take longer than a normal delta cycle.

A swing migration uses a second server in staging mode to prepare and validate the replacement before switching production responsibility. Microsoft recommends this approach for scenarios such as substantial configuration changes or an operating-system upgrade.

The important control is not simply having two servers. It is validating the staged configuration and pending changes before cutover. Follow Microsoft’s supported switching sequence: place the previous active server into staging mode before promoting the replacement. Do not leave two Connect Sync servers actively exporting to the same tenant.

After successful cutover, update the remaining staging environment or deliberately decommission the old installation under an approved plan. An obsolete server that later resumes synchronisation can create difficult-to-trace problems.

Use Microsoft’s upgrade guidance to select the approach for your actual environment; this article is a planning guide, not a universal execution runbook.

Should you move to Cloud Sync instead?

Microsoft advises evaluating Cloud Sync when planning Connect Sync changes. That is a worthwhile architecture review—but it is not an automatic replacement decision.

Compare your required identity features, directory topology and operational dependencies with Microsoft’s supported scenarios before choosing a migration. Keep an urgent support-version upgrade separate from a wider redesign if combining them would introduce unnecessary risk.

The goal is a supported identity service, not a rushed platform change to meet a headline deadline.

What “finished” should mean

An installer completing successfully is only the first checkpoint. Before closing the change, confirm:

• The intended build is installed on the relevant active and staging servers.
• Imports, synchronisation and exports complete without unexplained errors.
• A controlled test change reaches the expected destination.
• Password and writeback behaviour is validated where applicable.
• No unexpected object deletions or scope changes are pending.
• The required application-based authentication configuration has been verified, rather than assumed.
• Monitoring, recovery documentation and the next lifecycle review have named owners.

Where this connects

Vivolution Technologies LLC can help assess your Microsoft environment, identify hybrid identity risks and plan a controlled improvement roadmap. Explore our Microsoft 365 services and cybersecurity services, or contact Vivolution to discuss your current setup.

Official references

• Microsoft Entra Connect: version release history and retirement dates
• Microsoft Entra Connect: upgrade from a previous version

Microsoft can revise release guidance and deadlines. Check the linked documentation before making production changes.