In short: Forge captures an application from its live, working installation and repackages it for a modern, supported operating system, so it needs no original media, no source code and no surviving vendor. It is low cost, it resolves compatibility problems rather than only packaging around them, and in practice it is the fastest route we have for getting a legacy application onto a supported OS. It is not magic: an application that cannot run on the target OS at all still cannot, and the output is validated against your estate before production.

Who this is for
  • An application is the reason a machine is still on an unsupported operating system
  • The installer, the source or the vendor is gone, and nobody can reproduce the install
  • You have an App-V estate to move and the packages carry years of undocumented tweaks
  • A migration has stalled on a handful of applications nobody wants to own
What it costs to leave it

One unmovable application does not stay one problem. It becomes the exception in every patching cycle, the machine security reporting has to footnote, and eventually the reason a whole upgrade programme stalls, because nobody has found the time to solve the one hard case.

Part of a series, so the player offers the rest of it afterwards. Plays from YouTube. Nothing is requested from YouTube, and no cookie is set, until you press play.

What capture from a running state actually means

It packages the application as it exists on a machine where it already works, rather than replaying an install nobody can reproduce.

Conventional repackaging starts from setup media: you run the installer in a clean capture environment and record what it does. That is the right approach and it is what we use whenever the media still exists. It stops being available the moment the media does not, which for genuinely old applications is most of the time.

Capture starts from the other end. The application is already installed and already working on some machine, so its actual installed state, the files, the registry, the configuration accumulated over years, is the source of truth. That state is what gets packaged.

Where it is the right answer, and where it is not

It is the right answer when the install is unreproducible and the application still matters.

Reach for it when:

  • The media, the source or the vendor is gone.
  • The install was customised over years and nobody documented what changed.
  • An App-V package carries connection groups, scripts and dynamic configuration that no converter preserves cleanly.

Do not reach for it when:

  • You still have working source media. Repackage from that: a capture inherits whatever state the source machine was in, so it needs more validation, not less.
  • The application installs kernel-mode drivers or Windows services, requires elevation at runtime, or installs other applications. Those constraints belong to the target platform and no packaging tool removes them.
  • Nobody actually uses it. The cheapest migration is always retirement, and discovery routinely finds applications everyone assumed were critical and nobody has opened in a year.

What we do with it

We use Forge as one tool inside a packaging service, not as the service itself.

A tool does not inventory your estate, decide which of three hundred applications will never convert, or sit on a call at eight in the morning when one of them breaks in production. The judgement is the work: discovery first, then a per-application decision on whether it is repackaged from source, converted, captured, delivered another way, or retired.

Forge is what we use for the captured ones, and it is the reason that group is much smaller a problem than it used to be.

What we do with EtherApps Forge

  • Discovery across the estate, so the decision is per application rather than per platform
  • Capture and repackage where the install cannot be reproduced
  • App-V to MSIX migration, including the connection groups and scripts converters lose
  • Testing and remediation against your target build before anything reaches production
  • Delivery through Intune, Configuration Manager or app attach for AVD and Windows 365

Related

Frequently asked

Does Forge work if we have lost the installer completely?

Yes, that is the case it exists for. It packages the application from its current working installation rather than from setup media, so the requirement is a machine where the application still runs, not the original media, the source code or a vendor who still trades. That is why it so often unblocks a migration that has been stuck for years on one application: the blocker was almost never technical, it was that nobody could reproduce the install.

Is captured output as good as repackaging from source?

It is good enough to run in production, and we would still repackage from source when the source exists. A capture takes the application as it is on one machine, which means it inherits whatever that machine's state was, including any local drift. That is not a reason to avoid it, it is a reason to validate the output against your target build rather than assuming it. Where you have working media, use it; where you do not, capture is the difference between migrating and not.

Will it fix an application that is fundamentally incompatible with Windows 11?

Not on its own, and no packaging tool will. If an application installs kernel-mode drivers or Windows services, needs elevation at runtime, installs other applications or writes into its own Program Files directory, those constraints come from the target platform. Forge resolves a great many compatibility problems, particularly the ones that come from missing dependencies and lost installation state, but the genuinely incompatible tail needs another route: published from a virtual desktop, isolated on a segmented machine, or retired. Discovery is what tells you which group yours is in.

How much does it cost?

It is a low-cost tool, which is a large part of why it is worth reaching for early. The cost that actually matters on a legacy migration is rarely the licence, it is the months an estate spends stalled on a handful of applications, so the useful comparison is against that rather than against another product. We can quote the tool on its own if you want to run it yourself, or as part of a packaging engagement where we do the work.

Other vendors we support

Not sure where you stand with EtherApps Forge?

Tell us what you are running and we will tell you plainly whether it needs action, including when the answer is that it does not.

Ask us