What does not belong in the cloud and when hybrid Exchange pays off

The question is usually asked the other way round: what can we move to the cloud? The reverse is more useful. The applications that stay in-house for good reasons determine the shape of the whole environment, not the ones that move easily anyway.

Four reasons something stays in-house

These four come up regularly in practice. They are not a complete list. Licensing questions, vendor support statements and plain economics come on top case by case. But everything else is usually a question of order, not of whether.

• Special hardware: a machine controller, a measuring station, a card reader with its own interface. What is physically attached usually stays physically attached. Detours over network forwarding exist, but they are the exception and want testing.
• Latency: applications where milliseconds count do not tolerate a detour. That concerns production and control more than office work.
• Data residency requirements: where rules demand a specific storage location, the rule decides, not the technology.
• Dependencies: an application that hangs off three others does not move alone. Such chains are the most common reason a project stalls halfway.

What follows: the hybrid environment

When part stays and part goes, the result is not half a cloud but its own operating model. It has three properties worth knowing before you commit.

• Two identity worlds have to fit together. Whoever signs in locally should be able to work in the cloud without a second password, the part that is most often underestimated.
• The internet connection becomes the critical line. What used to run in-house now depends on it. Whether a second line is needed follows from how long an outage is tolerable.
• Backup and monitoring must cover both worlds. Two separate tools mean two separate blind spots.

The most common case: hybrid Exchange

With email the hybrid form appears most often: mailboxes sit partly on site, partly in the cloud, and to users it looks like one system. Three reasons speak for it, and they apply only where they actually hold.

• Many mailboxes: beyond a certain number not everything can be moved in one weekend. Moving in waves requires both sides to work at the same time.
• Large archives: where years of email sit, the transfer alone takes days. Parallel operation prevents nobody being able to work during that time.
• Applications that need the server: a scanner that sends mail, or a line-of-business application with a fixed server address. Frequently such devices only manage plain SMTP without modern authentication. They need an alternative route before switching off, and that is rarely built in an hour.

The reverse also holds: if the move is feasible in one weekend and no application depends on the old server, there is little to be said for the detour. A hybrid deployment brings its own technology, which has to be set up, understood and, if something goes wrong, taken apart again. One qualification remains: for the move itself it is needed in most cases. The question is not whether, but for how long.

The point most often left undone

In a migration a hybrid deployment is usually an intermediate state, not a destination. An intermediate step with an end date is a plan; one without becomes a permanent burden: two systems want maintaining, and fault-finding becomes harder, not easier. Where applications stay in-house permanently, the hybrid form is the destination, but then deliberately chosen, not left over.

This is exactly where something fundamental has changed. For years the rule was: anyone keeping user accounts on site and synchronising them to the cloud could not switch off the last Exchange server, because the mailbox-related attributes were only manageable there. In many organisations a server stood solely for that purpose, needed by nobody, yet removable by nobody either.

There is now a way out: Microsoft has moved the management of these values into the cloud and writes a defined subset of them back into the local Active Directory. Both are generally available by now, though the configuration you have to create still carries the label „Preview" in the admin centre. One prerequisite comes with it too: writeback runs through Entra Cloud Sync, which is set up in addition to the existing synchronisation. You do not have to replace that.

The time pressure comes from another direction: support for Exchange Server 2016 and 2019 ended on 14 October 2025. Anyone keeping the last server is either running a version without security updates or moving to the Subscription Edition. We have described what that means in detail in the article on the last Exchange server.

How do you start?

With a list of applications and the question of which of the four reasons above apply to each. Whatever meets none of them is a candidate for moving. Vendor support, licence terms and plain economics still need checking. The order follows from effort and dependencies. How that classification works in detail is on our page about cloud strategy; the operating model itself is described under hybrid infrastructure. A first conversation costs nothing.

Status: August 2026. The Exchange details (end of support, cloud-side management and prerequisites) are verified against the Microsoft documentation and keep changing. Before making a change, look up the current state.