Att konvertera äldre Windows-applikationer till MSIX innebär att ta en äldre applikation, oavsett om den kom som en setup.exe, en legacy MSI, ett App-V- eller ThinApp-paket, eller en levande installation vars media försvann för flera år sedan, och bygga om den till ett signerat MSIX-paket som installeras och avinstalleras rent på Windows 11 och distribueras via Microsoft Intune. Organisationer väljer vägen från legacy till MSIX eftersom det moderna containerformatet ger förutsägbar installationshygien, en ren väg till Azure Virtual Desktop och Windows 365, och ett stödbart sätt att hålla årtionden av line-of-business-programvara igång medan äldre paketeringsformat fasas ut. Den här guiden täcker hela resan: vad som räknas som legacy, varför MSIX är målet, konverteringsvägarna jämförda, vad som tenderar att gå sönder, när MSIX är fel svar, och ett praktiskt arbetsflöde du kan följa applikation för applikation.
Vad som räknas som en legacy Windows-applikation
Legacy har mindre att göra med ålder än med hur en applikation paketerades och hur mycket av dess ursprungliga sammanhang som fortfarande överlever. Flera mönster dyker upp i nästan varje miljö.
- setup.exe- och legacy MSI-installationsprogram. Leverantörsinstallationsprogram byggda för Windows 7 eller tidiga Windows 10, ofta med hårdkodade sökvägar, anpassade åtgärder och tysta installationsväxlar som ingen dokumenterade.
- App-V-paket. Virtuella applikationspaket från en App-V-miljö som nu behöver en plan framåt, särskilt där App-V-serversidan har nått slutet på sin stödda livslängd.
- ThinApp och andra virtualiserade format. Applikationer inkapslade i ett äldre virtualiseringsformat som organisationen går ifrån när den standardiserar på en enda modern container.
- Applikationer med förlorade installationsmedia. Programvara som körs problemfritt i produktion men vars installationsprogram har försvunnit för att leverantören lade ner, nedladdningsportalen är låst, eller media låg på en resurs som städades bort.
- Applikationer infångade från äldre Windows-versioner. Line-of-business-verktyg som bara någonsin installerades på referensmaskiner med Windows 7 eller tidiga Windows 10 och nu måste flyttas till en aktuell baslinje.
Den gemensamma nämnaren är att den körande applikationen, inte ett orört installationsprogram, ofta är den mest tillförlitliga sanningskällan.
Varför MSIX är det moderna målet
MSIX är ett containerbaserat paketeringsformat som isolerar en applikations filer och registerskrivningar från resten av systemet, så att installationer och avinstallationer är rena och lämnar lite efter sig. Den hygienen är den främsta anledningen till att team standardiserar på det, men tre praktiska fördelar brukar besegla beslutet.
Det körs där moderna miljöer körs. MSIX stöds internt på Windows 10 version 1709 och senare, och på Windows 11, så ett konverterat paket riktar sig mot de plattformar som de flesta organisationer redan är på väg mot. Äldre Windows-versioner behöver kompatibilitetslagret MSIX Core.
Det passar molnleverans och virtuell leverans. MSIX app attach kopplar dynamiskt en applikation till en användarsession på Azure Virtual Desktop utan att installera den på sessionsvärden, vilket håller avbildningarna slimmade och skiljer applikationens livscykel från operativsystemet. På fysiska enheter och Windows 365 Cloud PC:er distribueras samma signerade MSIX via Intune till hanterade slutpunkter.
Det distribueras via verktygen du redan kör. En signerad MSIX läggs till i Intune och tilldelas användare eller enheter i stegvisa ringar. Signering är inte valfritt: Windows kräver att varje MSIX-paket signeras med ett certifikat vars kedja går till en rot som enheten litar på, och det installerar inte ett osignerat paket. Det finns ingen leverantörssignatur att ärva från en infångad applikation, så paketet tar din organisations eget kodsigneringscertifikat.
Konverteringsvägarna jämförda
Det finns ingen enda väg från legacy till MSIX. Rätt metod beror på om källinstallationsprogrammet överlever, hur många applikationer du flyttar, och hur komplex var och en är. Jämfört per metod snarare än per produkt:
| Metod | Bäst för | Automatiseringsnivå | Att se upp med |
|---|---|---|---|
| Manuell ompaketering med MSIX Packaging Tool | En handfull applikationer med rena installationsprogram eller besvärlig installationslogik som behöver ett mänskligt öga | Låg, praktisk hela vägen | Långsam och svår att upprepa identiskt mellan paketerare |
| Skriptad eller batchkonvertering via paketeringsverktygets kommandorad och mallfiler | Större miljöer där många installationsprogram konverteras i bulk | Hög, mallstyrda körningar | Kräver solida mallar och validering per applikation efteråt |
| Capture-first-konvertering på en kontrollerad ren VM med AI-styrd granskning | Applikationer med förlorade media, äldre virtualiserade format eller komplexa fotavtryck | Hög, agentisk med mänsklig granskning | Bekräfta licensrättigheter innan du återfångar en installerad applikation |
Microsoft MSIX Packaging Tool ligger till grund för de två första vägarna. Det skapar ett MSIX-paket från ett MSI-, EXE-, ClickOnce-, App-V 5.1- eller skriptinstallationsprogram, och för App-V konverterar det 5.1-formatet direkt medan 4.x-paket i stället konverteras från sitt källinstallationsprogram. För bulkarbete körs samma verktyg från kommandoraden mot en konverteringsmall som bär paketinformationen och inställningarna, så att en konfiguration kan återanvändas över många applikationer och senare versioner:
MsixPackagingTool.exe create-package --template C:\conversions\LineOfBusinessApp.xml -v
Generera mallen en gång via verktygets gränssnitt och återanvänd den sedan för skriptade körningar. Där installationsprogrammet saknas helt blir capture-first den praktiska vägen: den körande applikationen fångas från en levande, ren maskin och byggs om till ett paket, vilket är den mark som capture-first-vägen till MSIX för komplexa applikationer täcker på djupet.
Legacy-källor flödar genom infångning och åtgärder till moderna utdata distribuerade över Intune, Azure Virtual Desktop och Windows 365.
Vad som ofta går sönder, och hur PSF hjälper
Ett konverterat paket som installeras är inte detsamma som ett som fungerar. Eftersom MSIX kör applikationen inuti en container som omdirigerar vissa fil- och registerskrivningar, börjar vissa beteenden som var problemfria vid en traditionell installation att fallera.
De vanliga bovarna är en applikation som skriver in i sin egen installationsmapp, en som är beroende av en specifik arbetskatalog som containern inte ställer in, och en som förväntar sig parametrar eller en miljövariabel vid start. Detta är precis vad Package Support Framework (PSF) finns till för att åtgärda. PSF är ett open source-kit från Microsoft som tillämpar riktade fixar på en applikation utan att röra dess källkod, så att den beter sig inuti containern. Det kan korrigera arbetskatalogen, omdirigera filskrivningar till en stödd plats och köra ett skript vid start för att förbereda den miljö applikationen förväntar sig.
Två begränsningar är värda att känna till innan du börjar. MSIX stöder inte Windows-drivrutiner, så en applikation som installerar en drivrutin i kärnläge containeriseras inte rent. Tjänster stöds, men bara från Windows 10 version 2004 och framåt och bara som per-maskin-tjänster som körs under ett systemkonto; per-användar-tjänster stöds inte, och ett tjänstepaket behöver administratörsrättigheter för att installeras. Konfiguration per användare spelar också roll: en infångning på maskinnivå för inte med sig licensfiler eller förstagångstillstånd som skrivits in i en användarprofil, så det tillståndet måste hanteras medvetet.
När MSIX är fel mål
MSIX är rätt mål för de flesta skrivbordsapplikationer, men inte för alla, och att tvinga fram det är en vanlig orsak till omarbete. Välj en annan utdata när en applikation kräver en Windows-drivrutin, är beroende av en per-användar-tjänst, eller förlitar sig på djup shell- eller COM-integration som måste vara synlig utanför paketet. I de fallen håller en signerad MSI applikationen distribuerbar samtidigt som den respekterar vad containern inte kan göra, och en infångad nyttolast kan ligga bredvid den. Där det omedelbara behovet är molnhanterad leverans snarare än containerisering distribueras ett IntuneWin-paket, Win32-applikationsformatet byggt med Microsoft Win32 Content Prep Tool, lika enkelt via Intune. Disciplinen är att låta varje applikations fotavtryck avgöra formatet, snarare än att binda varje applikation till MSIX innan du förstår den.
Ett praktiskt arbetsflöde från legacy till MSIX
Oavsett blandningen av källor håller samma sekvens arbetet förutsägbart.
- Inventera. Lista varje applikation, dess ägare, version, installationskälla, och om de ursprungliga media fortfarande finns.
- Rationalisera. Avveckla det ingen använder och konsolidera dubbletter innan du lägger ner någon möda, så att du bara moderniserar det som förtjänar sin plats.
- Välj en väg per applikation. Använd inventeringen för att peka varje applikation mot manuell, skriptad eller capture-first-konvertering, och flagga dem som passar bättre för MSI eller IntuneWin.
- Fånga eller konvertera på en ren VM. Arbeta på en ren, uppdaterad Windows 11-maskin så att du paketerar applikationen och inte röran från ett arbetande skrivbord.
- Åtgärda. Tillämpa PSF-fixar där containern ändrar beteendet, inklusive ett startskript där ett behövs.
- Testa på representativa enheter. Kontrollera start, centrala arbetsflöden, licensaktivering, användarspecifika inställningar och avinstallation på enheter som matchar målmiljön.
- Signera. Signera varje paket med ett betrott kodsigneringscertifikat vars identitet matchar manifestets utgivare.
- Distribuera via Intune i ringar. Tilldela en pilotring först, bredda sedan så att varje problem dyker upp på ett fåtal enheter snarare än över hela miljön.
De envisa fallen, förlorade media och äldre virtualiserade format, är där en infångningsledd metod betalar sig. Våra guider om hur du ompaketerar en applikation när installationsprogrammet är förlorat och en migrering från App-V till MSIX går djupare in på de två vägarna, och modernisera äldre Windows-applikationer täcker bedömningen som ligger framför dem.
Var EtherApps Forge passar in
Det mesta av svårigheten i ett program från legacy till MSIX ligger i svansen: applikationerna utan installationsprogram, med ett äldre virtualiserat format, eller med ett fotavtryck som är för komplext för att konvertera i blindo. EtherApps Forge är byggt för den svansen. Det är en Win32-applikation som du distribuerar inuti din egen miljö snarare än en SaaS-tjänst, så att infångningar och paketering stannar under din kontroll, och det fångar applikationer från både äldre Windows-versioner och aktuella, vilket är precis vad en äldre miljö behöver.
Arbetsflödet är agentisk applikationspaketering med mänsklig granskning: en AI Controller, som körs på en VM i Azure inuti din egen kontrollerade miljö, analyserar det infångade fotavtrycket och rekommenderar en väg över MSIX, MSI, IntuneWin och app attach, medan en paketerare bekräftar beslutet snarare än att låtsas att svåra applikationer paketerar sig själva. Varje licens inkluderar utbildning och support, och en kostnadsfri provperiod på 7 dagar låter ett paketerings- eller slutpunktsteam bevisa utfallet på en riktig applikation innan den bredare miljön binds. För leveranssidan täcker MSIX-paketering och utrullning signering, PSF-granskning och Intune-utrullning, och agentisk applikationspaketering förklarar fångst-och-granskningsmodellen i sin helhet. Du kan se själva produkten på EtherApps Forge.
Från legacy till MSIX är ett beslutsjobb innan det är ett paketeringsjobb: inventera miljön, dirigera varje applikation till metoden som passar, åtgärda det containern ändrar, signera resultatet och distribuera via Intune med tillförsikt.
Modernisera dina äldre Windows-applikationer med en bedömning och capture-first-metod som förvandlar odokumenterad programvara till signerade, distribuerbara paket.