Inventory the Windows release and installed roles
| Source item | Capture before deciding |
|---|---|
| Windows Server release and edition | Exact version, build, installed roles, application versions and recovery media. |
| .NET Framework, IIS and Windows services | Framework version, IIS configuration, COM dependencies and service identities. |
| SQL Server | Database version/edition, collation, jobs, linked servers and application dependencies. |
| Portable services and modern .NET | Source availability, supported Linux runtime and platform-neutral dependencies. |
| Active Directory and Windows infrastructure roles | Authentication, DNS, SMB, printing, policies and management dependencies. |
A Windows system image is not a Power installation
Plan to deploy eligible software into a supported Power OS. Copying or restoring a Windows VM does not convert its CPU architecture or provide a supported Windows guest on Power. Record the exact Windows release for vendor support and application-upgrade decisions; do not infer portability from how new it is.
Windows-only application dependencies can decide the outcome
Microsoft distinguishes .NET Framework’s Windows dependencies from modern .NET. A service tied to classic ASP.NET, COM, Windows authentication APIs or other Windows components needs explicit conversion work or a retained Windows tier. Rebuilding the project is only one part of validating the business application.
If the vendor supplies only a Windows edition, request its supported deployment choices before considering a replacement application. Keep the approved commercial and functional scope with that decision.
SQL Server on Linux still requires x64
Microsoft’s SQL Server Linux requirements specify an x64-compatible processor. Moving from Windows to SQL Server on Linux therefore does not establish a supported Power database engine.
Keep SQL Server on a qualified x86 platform and assess a separate portable application tier, or approve a database-engine conversion. The latter can change SQL, stored procedures, integrations and application support; use the SQL Server engine-conversion checklist.
Modern .NET and other portable services can be assessed separately
A platform-neutral web or service tier may be a Power Linux candidate when its runtime and dependencies are supported. Red Hat’s .NET 8 notes include ppc64le, illustrating that modern .NET has Power options; select a currently supported runtime and RHEL combination for the actual project.
Check NuGet native assets, database drivers, filesystem assumptions and authentication. Run integration and load tests against any database or identity service that remains elsewhere.
Keep required Windows roles available during a split deployment
Moving an application tier does not remove its directory, file-share or scheduler dependencies. Document which Windows services stay, who maintains them and how Power reaches them. Test credentials, network delays and outage behavior. A split deployment is useful only if the business can support and recover both sides.
Plan a split Power and x86 environment before retiring the source server.
Plan the Power destination with Midland
Use the assessment to decide which workload belongs on Power before comparing hardware. Midland’s Power model catalog supplies the server identities; software eligibility and measured workload demand decide the configuration.
Prepare the conversion inventory and Bring your current OS, application and database versions to Midland.
Sources and release checks
Technical guidance checked October 21, 2026. Confirm the exact application edition, OS release and target architecture with its vendor before ordering. Older technical papers explain migration methods; they do not establish current certification.