The important correction is that TeamViewer’s replacement is not simply a renamed legacy connector. It is a different operating model. Microsoft identifies the entries separately in Intune: TeamViewer (old) is the previous remote-assistance experience, while TeamViewer is the new experience. Organizations can use that distinction during coexistence testing, but should treat it as a migration between service models rather than a cosmetic administrative update.
What retires—and what does not
TeamViewer says the legacy Intune integration retires in April 2027. No precise day is established in the available documentation, so IT leaders should plan against the month rather than invent a more exact cutoff.
That retirement applies to the old connector, not to attended remote support as a concept. The newer TeamViewer integration can support attended and unattended access, with the behavior governed by TeamViewer device permissions and access-control policies. This matters because a service desk that primarily helps signed-in users does not have to move to Remote Help merely to preserve attended sessions.
Still, “attended access remains possible” is not the same as “every existing attended workflow will survive.” The legacy connector could connect to devices using QuickSupport without requiring that the device be managed or inventoried in TeamViewer. The new integration requires a TeamViewer-managed device. Unmanaged or bookmarked targets are no longer accepted in that new connection path.
That is likely to be the largest migration break. A technician may have had a reliable legacy process for a contractor’s PC, a temporary kiosk, a home device, or a recovery scenario where QuickSupport was launched on demand. If that endpoint is absent from TeamViewer management, the new Intune integration is not an equivalent replacement, even if it appears in Intune.
The new TeamViewer connector: dual management is the gate
For the replacement TeamViewer integration, the target device must be managed in both relevant systems:
- It must be managed by the organization’s Intune tenant.
- It must be a TeamViewer-managed device.
- It must have a TeamViewer Host or full client, rather than relying solely on an ad hoc QuickSupport-style connection.
This dual-management requirement changes the work before a migration. The question is not simply whether a device is visible in Intune. It is whether the same endpoint can be reliably resolved from Intune into TeamViewer’s managed inventory.
Microsoft’s documented lookup behavior provides a practical test. Intune passes the Microsoft Entra device ID to TeamViewer to find the target. If the Entra device ID is unavailable, Intune uses the device name as a fallback. Device name is a weaker identifier: duplicates, reused naming conventions, stale records, and inconsistent renames can create ambiguity. A pilot should therefore record whether every tested endpoint resolves by Entra device ID, identify every name-fallback case, and reject ambiguous matches before broad deployment.
This is more rigorous than comparing device counts or serial-number exports. A migration may look healthy in inventory reports yet fail at the moment a technician launches a session because the cross-service identity mapping does not lead to the intended TeamViewer record.
The new integration also shifts control toward TeamViewer’s own management plane. Device groups, policies, account scope, software deployment, and access-control permissions must all be evaluated alongside Intune configuration. Having an eligible device in both inventories is necessary, but it is not by itself proof that a help-desk workflow will work.
Licensing and commercial entitlement need their own verification. The currently identified TeamViewer routes include Tensor, TeamViewer One Standard, and TeamViewer One Advanced with an Enterprise Integrations or Microsoft Connect Pro add-on. TeamViewer Corporate is identified with Microsoft Connect. These labels should be treated as procurement checks, not assumptions: the organization needs to confirm its actual agreement, applicable add-ons, account scope, and the rights available to its technicians.
When Microsoft Remote Help is a better fit
Remote Help is not a drop-in substitute for every TeamViewer use case, but it can be the more coherent option for organizations that want remote assistance centered on their Microsoft tenant. Its clearest architectural boundary is also its most consequential one: the helper, sharer, and device must be in the same tenant.
That condition rules out a number of superficially plausible designs. A customer-tenant device cannot simply be supported by a provider technician in a different tenant through Remote Help. The same problem can arise with outsourced service desks, subsidiaries that maintain separate tenants, and bring-your-own-device situations where the applicable tenant relationship is unclear. The constraint covers the device as well as the people participating in the session.
Licensing must be planned at the user and device-workflow level. As the ordinary rule, Remote Help licensing is required for targeted helpers and sharers. There is an important exception for supported Zebra and Samsung Android Enterprise dedicated devices: because no user signs in as the sharer on those dedicated-device deployments, only the helper needs a license. That exception is narrow; it should not be generalized to other Android, shared-device, Windows, or macOS scenarios.
Remote Help also has more nuance around enrollment than a simple “managed devices only” rule suggests. Windows and macOS sharers can optionally be supported when their devices are unenrolled. However, auditing for those unenrolled-device sessions is limited. An organization that enables this capability should create a separately governed support process, with clear approval, logging expectations, and risk acceptance, rather than quietly treating it as identical to support for enrolled corporate assets.
For unattended Windows maintenance, Remote Help has firm requirements. The target must be a physical, corporate-owned, Intune-managed x64 Windows device that is Microsoft Entra joined or hybrid joined. Virtual machines, personally owned devices, and unenrolled devices are not supported for unattended control. That makes Remote Help potentially attractive for a standardized fleet of managed Windows PCs, but a poor fit for a maintenance estate that depends on VMs, personal endpoints, or unmanaged recovery targets.
Government cloud is a hard decision point
Government-cloud eligibility should be determined before either product is placed in a migration plan. It is not safe to assume that an unavailable Remote Help deployment automatically makes the new TeamViewer integration the fallback.
In GCC High and DoD, the legacy TeamViewer connector and the newer TeamViewer integration are listed as unavailable. Remote Help is also not supported in GCC High or DoD. In those environments, neither of the two migration candidates presented here should be assumed viable; the organization needs a different, environment-supported remote-assistance approach.
GCC requires more careful reading. Remote Help support is reduced in GCC rather than absent, while the new TeamViewer connector documentation says TeamViewer is unsupported in GCC and GCC High. These are not interchangeable statements. Teams should validate the specific features, licensing, and service descriptions applicable to their tenant instead of treating “government cloud” as one uniform compatibility category.
A decision framework for the April 2027 deadline
The most useful choice is usually driven by the target population rather than by product preference.
Choose the new TeamViewer integration as the leading option when the organization already has, or can establish, a reliable TeamViewer-managed inventory for Intune-managed endpoints; needs TeamViewer’s attended or unattended model; and can validate the required commercial entitlement and policy configuration. This is the more natural route for organizations whose operational remote-access design is already rooted in TeamViewer management.
Choose Remote Help as the leading option when helpers, sharers, and devices operate in the same tenant; the endpoint estate aligns with supported platforms; and the organization wants a Microsoft-tenant-centered support workflow. It deserves particular consideration for a corporate-owned, Intune-managed Windows fleet where the unattended-use restrictions are acceptable.
Neither option should be assumed to replace legacy TeamViewer workflows involving unmanaged QuickSupport targets or bookmarked endpoints. Remote Help may accommodate some unenrolled Windows and macOS attended scenarios, but with limited auditing, while the newer TeamViewer integration requires TeamViewer-managed targets. Those are different exceptions with different governance consequences—not a general answer for every unmanaged-device case.
Build a migration inventory around workflows, not products
A productive discovery exercise starts by classifying actual support sessions from the last several months. For each workflow, document the target platform, ownership, Intune enrollment state, TeamViewer management state, tenant of the helper and target, whether the session is attended or unattended, and whether the endpoint is physical or virtual. Add the required audit level and the software or operational dependencies that make the device reachable.
Then test representative endpoints against the relevant gates.
For the new TeamViewer path, confirm that the endpoint is Intune-managed, TeamViewer-managed, and equipped with the required Host or full client. Verify its Intune-to-TeamViewer lookup explicitly, recording whether resolution occurred through the Entra device ID or the device-name fallback. Investigate every fallback and every mismatch rather than accepting a successful connection to a similarly named device as evidence of correctness.
For Remote Help, verify that helper, sharer, and device are in the same tenant; confirm the normal licensing position or the narrow Android dedicated-device exception; and check whether the workflow depends on unattended Windows control. If it does, test against the physical, corporate-owned, Intune-managed x64, Entra-joined or hybrid-joined requirements. For unenrolled Windows or macOS attendance, document the limited-auditing implication and obtain an explicit governance decision.
Finally, test failure cases deliberately: an off-network device, a renamed endpoint, a duplicate name, a stale TeamViewer record, a virtual Windows device, a personal device, and a session that crosses tenants. A migration pilot that only proves the happy path on clean corporate laptops will not reveal the legacy workflows most likely to fail after retirement.
Plan coexistence early, but avoid unsupported assumptions
Because Intune labels the old and new TeamViewer experiences separately, organizations can use a staged transition to compare them while the legacy connector remains available. The objective should be to reduce the population dependent on the old model before April 2027, not to wait for a final-week bulk cutover.
A sensible sequence is to reconcile inventories, establish a device-identity success baseline, pilot the replacement with a narrowly defined set of managed endpoints, then migrate workflow groups in priority order. Unmanaged or cross-tenant scenarios should be isolated early because they are the most likely to require redesign or another supported tool.
There are limits to what can be concluded without a scoped test. Available material does not establish that the new TeamViewer integration supports every provider/customer or multi-tenant operating model. Nor does it establish the exact platform, ownership, client, and enrollment details for every contemplated TeamViewer workflow. Those questions belong in the vendor-confirmation and proof-of-concept plan.
The April 2027 retirement is therefore less a binary product-selection event than an opportunity to make remote assistance intentional. Organizations that identify their unmanaged targets, validate identity resolution, respect tenant boundaries, and test unattended maintenance separately will be far better positioned than those that assume the new connector is a transparent replacement for the old one.