Planning Your Migration Off On-Premises Exchange

Every organization still running on-premises Exchange faces the same quiet decision, whether or not they have named it: keep patching an internet-facing mail server against a steady stream of critical vulnerabilities, or plan its retirement. The CVE-2026-62911 authentication bypassAuthentication Bypass📖A security vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. that allows an attacker to circumvent the login verification process and gain unauthorized access to a system without providing valid credentials., which left nearly 22,000 servers exposed even after a patchPatch🛡️A software update that fixes security vulnerabilities, bugs, or adds improvements to an existing program. shipped, is only the latest prompt to make that decision deliberately rather than by default.

Why This Keeps Happening

On-premises Exchange is a large, complex application whose front-end proxy components sit directly on the internet and speak legacy authenticationLegacy Authentication🛡️Older authentication protocols (POP, IMAP, SMTP AUTH, older Office clients) that don't support modern security features like MFA, making them prime targets for credential attacks. protocols. That is close to a worst-case attack surfaceAttack Surface🛡️The sum of all points where an unauthorized user could attempt to enter or extract data from a system: exposed services, interfaces, accounts, and integrations. Reducing attack surface means removing reachability, not just patching., and it is why Exchange has produced a recurring pattern of pre-authentication and authentication-bypass flaws. The technique behind the latest one, described in the explainer on how NTLM relayNTLM Relay🛡️An attack where a valid NTLM authentication is forwarded in real time to a different service than the one intended, granting the attacker the victim's access without ever cracking a credential. attacks bypass authentication, is more than a decade old and keeps finding new footholds in the product.

Compounding the problem, the 2016 and 2019 product lines are near the end of their supported life, with extended security updates winding down. An internet-facing server whose vendor support is ending is a standing risk that grows with every month it stays online. The question is not whether another serious Exchange vulnerability will arrive, but whether you want to keep being on the hook to patch it within days.

Framing the Decision

Migrating off on-premises Exchange is a project, not a patch, so treat it as a risk-management decision with a few honest inputs.

• Count your true exposure. How many Exchange servers do you run, which are internet-reachable, and what would full mailbox compromise cost you? Be specific about the mail data and the Active Directory privileges those servers touch.
• Weigh the recurring cost of staying. Emergency patching, out-of-band mitigations, and the monitoring needed to catch exploitation all consume staff time indefinitely. That ongoing burden is the real price of on-premises mail, and it belongs in the comparison.
• Identify why you are still on-premises. Regulatory data-residency rules, custom integrations, or applications that relay mail through Exchange are common anchors. Each is solvable, but you cannot plan around constraints you have not written down.

Migration Paths

Most organizations land on one of three routes. A full move to a cloud-hosted mail platform eliminates the on-premises attack surface entirely and shifts patching to the provider, which is the strongest security outcome for most. A hybrid deployment keeps some mailboxes or mail-routing on-premises during a transition, which is pragmatic but leaves a smaller version of the same exposure, so it should be a waypoint rather than a destination. Staying fully on-premises is defensible only if you can commit to rapid patching, enforced Extended Protection, and strict network isolation as permanent operational disciplines.

Whichever path you choose, the goal is to shrink the internet-facing footprint. Even before a full migration, you can reduce an internet-facing Exchange server's attack surface by pulling management and replication endpoints off the open internet and enforcing channel binding on what remains.

Sequencing the Work

A migration that reduces risk starts by containing the current risk. Patch and harden what you have now, because an in-progress migration does not protect a server that gets exploited next week. From there, run the move in stages: pilot with a low-risk set of mailboxes, validate mail flow and integrations, then expand. Decommission each on-premises server as soon as it is empty rather than leaving dormant Exchange installs online, since an unused but internet-reachable server is exactly the kind of forgotten asset that shows up in the next Shadowserver exposure count.

The strategic point is that reacting to each Exchange vulnerability in isolation is a losing pattern. The CVE-2026-62911 exposure is a data point in a trend, and the organizations that fare best are the ones that use each incident to advance a plan they already have, rather than to launch another round of emergency patching.