Keep legacy applications moving when packaging becomes the blocker.

Application modernisation is the work of assessing legacy applications, choosing the right package route, and preparing them for current Windows delivery. In this route, EtherApps Forge captures the running application footprint, then helps produce MSIX, MSI, IntuneWin, or AppAttach outputs where suitable for Windows 11, Intune, AVD, or Cloud PC delivery.

Start by inventorying the app estate, identifying missing installers and compatibility blockers, then package each app into the route that fits the deployment target. Forge supports capture-first packaging, signing, manifest fix-ups, Intune-ready output, and App Attach paths so Windows 11 migration is not blocked by every legacy application.

A missing installer is not always a blocker. Forge can capture a live installation from a working machine or controlled VM, including files, registry, AppData, services, and dependencies. That capture can then be reviewed and turned into modern package outputs without waiting for a vendor re-download.

That is common with older applications, and it is normally a container behaviour problem rather than a broken app. Writing files next to the executable, assuming a fixed install path, or reading a machine registry location all behave differently inside MSIX. Forge stages the Package Support Framework to correct those cases with file and registry redirection and working-directory fix-ups, so the application runs as expected without a code change or a vendor rebuild.

Both. Alongside capture-first packaging for legacy applications, the forge_msix CLI is a drop-in replacement for Microsoft's makeappx.exe, so a development team or software vendor can turn a build folder into a signed, validated MSIX inside an existing CI pipeline. Estates modernising a mix of bought-in and internally built software use the same packaging route for both.

MSIX is the modern package format for Windows delivery, while App Attach is used for Azure Virtual Desktop app delivery where it fits the environment. Forge helps choose the output route per application, with MSIX, MSI, IntuneWin, and AppAttach outputs available from the same capture-led workflow.

Yes. EtherApps Forge's capture-first workflow and Forge MSIX CLI are built to run the same way across every client environment: capture, AI-guided routing, sign, and validate, whether that is one estate or many. MSP packaging factories and channel partners use the CLI and MCP automation to standardise output across customer estates instead of relearning a different packaging process per client, with a human reviewer still signing off each package before release.

Timing depends on the number of apps, installer quality, dependencies, review gates, and target platforms. The practical starting point is one real application: use the 7-day EtherApps Forge trial to capture, package, and validate a blocker before planning the wider migration wave.

No, and the capture-first assessment is what surfaces that early rather than after packaging has already started. Applications with kernel-mode drivers, low-level hardware dependencies such as USB dongles, or services that must run outside a user-session container generally cannot be safely packaged as MSIX or delivered through App Attach. Those apps get routed to a virtualisation, Azure Virtual Desktop, or explicit-replacement conversation instead of a package that will fail in production.

A signed MSIX package staged as a VHDX or CIM disk image on a file share your session hosts can reach, with the full certificate chain trusted on those hosts. Forge's capture-and-convert output produces that signed MSIX; the AVD-side storage and session-host configuration remains your own Azure setup.

It raises the stakes rather than resetting them. Windows 10 reached end of support on 14 October 2025, and commercial Extended Security Updates only run until 13 October 2028 at the latest, a paid bridge, not a long-term plan. If legacy applications are still the blocker to moving devices onto Windows 11, that packaging backlog is now sitting on the clock, not just the roadmap. Forge's capture-first route exists specifically so the one or two stubborn applications don't hold up the rest of the estate.

Not as-is. Intune requires Win32 apps to install silently, with no user interaction, before they can be wrapped with Microsoft's own Content Prep Tool and uploaded, an installer that needs a person at the keyboard fails that requirement outright. This is one of the most common reasons a legacy app stalls at the Intune stage. Forge's capture, combined with Package Support Framework fix-ups, is built to get around installers that were never designed for unattended, silent deployment.

Yes. Citrix Virtual Apps and Desktops and Citrix DaaS natively support MSIX packages and MSIX app attach on session hosts, so a signed MSIX from Forge's capture-first workflow deploys straight into a Citrix estate the same way it deploys to Intune or AVD. That makes Forge a way to modernise the App-V or MSI apps sitting inside an ageing Citrix estate, converting them to MSIX or a clean MSI, without needing a separate Citrix-specific packaging tool or a partner-led project.

Yes, for the same reason as Citrix: Parallels RAS (from version 19 onward) natively delivers MSIX packages and MSIX app attach to RDSH, VDI, and AVD session hosts. Forge's capture-and-convert output is a standard signed MSIX, so it imports directly into Parallels RAS's application packages feature without any Parallels-specific conversion step.