Blog

Ivanti DSM End of Life: Start Fresh with Intune and RealmJoin

Ivanti DSM reaches end of life on December 31, 2026. How to plan the move to Microsoft Intune with RealmJoin, keep the repackaging effort small and modernize software distribution on the way.

Ivanti DSM reaches end of life on December 31, 2026. After that date there are no updates, no security patches and no vendor support. Anyone still running DSM needs a migration strategy that replaces what DSM does today without rebuilding everything from scratch, and that fits the way IT is run now: cloud-managed devices, self-service and continuous updates.

RealmJoin is built to complement Microsoft Intune, and in DSM environments it takes over the part Intune leaves open: packaging, patching, self-service and automation. This guide walks through an Ivanti DSM migration to Intune and RealmJoin, from the first assessment to the day DSM is switched off.

What Happens After Ivanti DSM End of Life

Running Ivanti DSM beyond its end-of-life date is technically possible; the software does not stop working overnight. The risks grow, though:

  • Security vulnerabilities are no longer patched
  • Important software updates that are business-critical but not security-related can no longer be rolled out either
  • Compliance frameworks such as ISO 27001 may classify an unsupported DSM as an unacceptable risk
  • Bugs and integration issues have to be solved in-house, without vendor support
  • Migration partners and expertise get scarcer the closer the deadline comes

The deadline is fixed. How much is still running on DSM when it arrives is not.

Software Distribution After Ivanti DSM

Ivanti DSM was designed for a traditional IT model: on-premises infrastructure, domain-joined Windows devices, and centralized, largely manual processes. Modern environments ask for something else:

  • Cloud-managed devices that do not depend on the corporate network
  • Self-service software access for end users
  • Continuous updates for third-party applications
  • Less manual packaging and maintenance

So the question is no longer "What replaces Ivanti DSM?" but "What supports our future IT operating model?"

Why Microsoft Intune Is the Foundation

Microsoft Intune is the cloud-native endpoint management service in Microsoft 365. It provides device enrollment and lifecycle management, security policies and compliance enforcement, Conditional Access with Microsoft Entra ID, and cross-platform support for Windows, macOS, iOS and Android. For an organization on Microsoft 365, it is the logical foundation for a DSM replacement.

What Intune alone does not fully address:

  • Application packaging at scale
  • Third-party patch automation
  • Self-service application delivery
  • Managing a large software catalog efficiently

What RealmJoin Adds to Intune

RealmJoin extends Microsoft Intune into an application lifecycle and automation platform and closes exactly these gaps. Apps and patching is the module that matters most in a DSM migration; automation, helpdesk tools and local admin management come with it.

Pre-built, Maintained Application Packages

  • More than 3,000 enterprise applications ready to deploy
  • Hundreds of macOS apps, delivered through Intune
  • The complete iOS and Android app stores, managed from the same console (coming soon)
  • New vendor versions are detected within 15 minutes and roll out through Preview and Main channels with the delay you set

What is not in the catalog gets packaged on request within a short time, or you upload your own installer as an organic package; how that keeps the repackaging effort of a DSM migration small is covered under Package Catalog Size. Custom applications are supported through audited Git repositories, CI/CD-based packaging pipelines and standardized quality controls; the Package Store documentation describes what is in the catalog and how packages are maintained.

Self-Service Software Portal

End users install approved applications on their own through the App Catalog on the device. That takes load off the helpdesk and makes the transition easier for users, during the migration and after it. The self-service portal documentation shows how it works.

Automated Third-Party Patching

Once an application is subscribed, RealmJoin keeps it current: continuous updates, less security exposure, no manual maintenance.

Software Lifecycle Management

Version control and staged, automated rollouts, usage tracking and reporting, and visibility of the software assets on every device. Full lifecycle management without custom tooling.

Runbook Automation and Remediation

RealmJoin ships with a library of 175 runbooks and remediation scripts, maintained on GitHub. They cover routine configuration and settings tasks across the Microsoft 365 stack: Intune, Entra ID, Exchange Online and Teams.

Runbooks are PowerShell scripts that run in Azure Automation in your own subscription and are triggered from the RealmJoin portal. Admins and support staff run them without being Intune experts and without holding highly privileged Intune or Entra roles; granular permissions decide who may run what.

Remediation scripts complement them by fixing configuration issues directly on managed clients. Like runbooks, they are hosted on GitHub and managed through the portal.

The library also includes scripts for reporting and auditing. Every action can be logged centrally in Azure Log Analytics within your own tenant.

LAPS for Cloud-Managed Devices

Microsoft Entra and Intune include a built-in LAPS solution, limited to a single local admin account per device. RealmJoin adds its own agent-based implementation with three account types, each for a specific use:

  • Emergency account: a persistent local admin account for break-glass access, even when the device cannot reach the network or Intune.
  • Support account: created on demand for daily support work and removed automatically after a configurable expiration, so no standing admin credentials remain.
  • Privileged account: lets power users request temporary local admin rights for themselves through SelfLAPS, without IT intervention.

All account types are configured in the RealmJoin portal, including on-demand creation, expiration periods and password presets. Passwords are stored encrypted in an Azure Key Vault in your own tenant, and every password request is logged for auditing.

A Console for Helpdesk and Operations

On top of that, RealmJoin adds a unified console for helpdesk and operations: device inventory, integrated helpdesk tools and one-click administrative actions.

Ivanti DSM vs Intune vs Intune + RealmJoin

CapabilityIvanti DSMIntuneIntune + RealmJoin
Software distribution
Entra ID integrationLimited
Mobile device managementLimited
Cloud-native architecture
Third-party patchingLimited
Pre-built app catalogLimitedLimited
Security updates for third-party apps beyond 2026
Self-service portalLimitedLimited
Runbook automation
LAPS for cloud devicesLimited
Deployment visibilityLimited
Vendor support beyond 2026

For Intune, "Limited" on the catalog and patching rows means the Enterprise App Management add-on of the Intune Suite: a curated catalog with updates for the apps in it, licensed separately.

Why RealmJoin Is a Strong Ivanti DSM Alternative

Organizations use RealmJoin to modernize software distribution in Intune environments and to reduce operational overhead at scale. It is not a one-to-one replacement for Ivanti DSM; it is a modernization layer for Microsoft Intune.

  • Eliminates most of the application repackaging effort
  • Accelerates the migration timeline
  • Adds automation for the routine work around Intune
  • Enables cloud-native software distribution
  • Improves the end-user experience

Instead of replicating DSM, organizations upgrade their IT operating model along the way.

Key Decisions for the Ivanti DSM Replacement

Package Catalog Size

DSM environments often include hundreds of applications built up over many years. Repackaging them is typically the most resource-intensive part of a DSM migration.

RealmJoin addresses this on three levels. The Package Store provides 3,000+ ready-to-use, continuously maintained packages, deployable through the RealmJoin Agent or Intune; it covers the majority of common enterprise applications without any packaging effort. For applications not in the store, the packaging team packages on request; generic packages contain no customer-specific configuration and are available to all customers at no additional cost, and only packages that need customer-specific customization draw from a custom packaging contingent. And organic packages let you upload your own installer as a ZIP file through the portal for binary transport with a fixed configuration; they are built automatically within minutes, need no ticket and cost nothing extra, but come with a fixed installation path and cannot be updated after creation.

Most of a DSM catalog can therefore be covered without significant repackaging effort or cost: through the store, through generic packaging requests, or through organic packages for the simpler binaries.

Modernization or Lift-and-Shift

Ivanti DSM end of life is an opportunity to move to cloud-native infrastructure, eliminate legacy dependencies, reduce operational overhead and gain scalability. Organizations that modernize achieve stronger long-term outcomes than those that replicate the legacy system.

Core Components of the Migration

A complete migration from DSM to Intune covers application packages, software deployment workflows, device and security policies, user and group configurations, and patch management processes. Intune combined with RealmJoin provides modern equivalents for all of them.

Ivanti DSM Migration to Intune in Ten Steps

1. Assess the existing DSM environment

Analyze the current setup: applications, deployment workflows, dependencies and infrastructure. This defines the scope and complexity of the migration and prevents surprises mid-project.

2. Identify business-critical applications and use cases

Prioritize the applications essential for daily operations. This keeps the business running and determines which workloads are validated first, before the broader rollout begins.

3. Define the target architecture

Establish Microsoft Intune as the cloud-native management foundation and define how RealmJoin extends it with application lifecycle management, automation and software distribution. Document this architecture before touching anything else.

4. Set up Intune and evaluate RealmJoin in parallel

RealmJoin requires Microsoft Intune as its foundation. For organizations not yet on Intune, this step runs as two parallel tracks: activating Intune for the Microsoft 365 tenant and onboarding RealmJoin. Book a demo to evaluate the migration against your current environment.

5. Map DSM applications to RealmJoin packages

Compare the current application portfolio with the RealmJoin catalog. Identify which applications are already covered by generic packages and flag the gaps that need packaging. This mapping is the foundation of the migration plan.

6. Request packaging for the missing applications

RealmJoin provides packaging as a service. Submit a request for what the catalog does not cover: generic packages are shared with all customers and included in the subscription, organic packages are ready within minutes, and only customer-specific customization draws from a custom packaging contingent. Most of the internal packaging effort of a DSM migration disappears at this step.

7. Configure Intune and RealmJoin for deployment

Configure Intune policies and compliance settings, connect RealmJoin, and define package assignments and deployment groups. RealmJoin packages follow structured assignment and configuration workflows, which keeps the process auditable and repeatable.

8. Validate deployments in a pilot

Test real-world scenarios before the broad rollout: installation behavior, assignment logic and targeting, update and patching workflows. RealmJoin's staged rollouts through Preview and Main channels make it straightforward to validate behavior in a controlled group before scaling.

9. Enable self-service and scale the rollout

Once the pilot is validated, activate the App Catalog for self-service and expand the deployment in controlled phases. This reduces helpdesk involvement, improves the end-user experience during the transition and gives IT visibility into the rollout progress.

10. Decommission Ivanti DSM

Once all applications are migrated to RealmJoin packages, deployable through Intune and managed through lifecycle automation, retire Ivanti DSM and complete the transition. Keep this step gated on full validation; decommissioning too early is one of the most common migration mistakes.

It's Not Too Late

Ivanti DSM end of life is close, and that is fine. You do not have to be finished by then; you have to have started, and starting is fast. One Microsoft Entra admin consent connects RealmJoin to your tenant, most of your catalog is in the Package Store already, and we have taken customers from zero to their first pilot deployments in under eight hours. From there the move runs in stages you control: pilot group first, then the Preview and Main channels, self-service when you are ready. Whatever is still on DSM at the end of the year is a shrinking list, not a risk. Book a demo and we start with your catalog.

Frequently Asked Questions About the Ivanti DSM Migration

When does Ivanti DSM reach end of life?

December 31, 2026.

Can I keep using Ivanti DSM after end of life?

Yes, but without updates, security patches and vendor support, which brings security, compliance and operational risks.

What should I prioritize in a DSM migration project?

The size of the application catalog, the packaging effort, self-service capabilities, patch automation and how well the target fits a cloud-managed environment.

What is RealmJoin?

RealmJoin is an application lifecycle and automation platform for Microsoft Intune: pre-built application packages, automated patching, a self-service App Catalog, runbook automation and local admin management (LAPS).

How does RealmJoin reduce the migration effort?

By removing most of the repackaging. A large, continuously maintained catalog of Windows and macOS applications covers the common ground; what is missing is packaged on request, shared as a generic package at no additional cost where no customer-specific configuration is involved, or uploaded as an organic package in minutes. Only customer-specific applications draw from a custom packaging contingent.

How long does an Ivanti DSM migration take?

The first pilot deployments take a day, not a quarter: connecting the tenant is one admin consent, and most of the catalog is already in the Package Store. How long the full move takes depends on the size of your catalog and the pace you choose; it runs in stages you control.

Does RealmJoin require on-premises infrastructure?

No. RealmJoin is a SaaS platform hosted in Microsoft Azure in Europe. It connects to Microsoft Intune and Microsoft 365 with one admin consent, and the sensitive parts, such as runbooks, local admin passwords and logs, run in your own tenant.

Something else?

Have a look at the FAQ in the documentation or get in touch.

Sources

Replace DSM, Don't Rebuild It

RealmJoin is the companion to Microsoft Intune: 3,000+ maintained packages, packaging on request, staged updates, self-service and 175 runbooks, connected to your tenant with one admin consent. Most DSM catalogs are covered before the first custom package is needed.

See RealmJoin in practiceGet Started