adv

10 key warnings for your Windows 10 migration

3. Application compatibility issues are supposed to be getting better

Microsoft says that upgrading your line of business (LOB) programs to Windows 10 from earlier versions of Windows should be much easier than any previous version upgrade:

Most Windows 7–compatible desktop applications will be compatible with Windows 10 straight out of the box. Windows 10 achieved such high compatibility because the changes in the existing Win32 application programming interfaces were minimal. Combined with valuable feedback via the Windows Insider Program and telemetry data, this level of compatibility can be maintained through each feature update. As for websites, Windows 10 includes Internet Explorer 11 and its backward-compatibility modes for legacy websites. Finally, UWP apps follow a compatibility story similar to desktop applications, so most of them will be compatible with Windows 10.

In my experience, many traditional Win32 LOB programs come through a Win7-to-Win10 upgrade relatively unscathed — although you have to pay particular attention to .NET changes, and the Internet Explorer Compatibility View may save your bacon. When it comes to upgrading Win 8.1 UWP apps to Win10, there are pitfalls.

If you aren’t sure whether a particular third-party application is up and working with Win10, and what version changes may be in store, Microsoft has an exhaustive list on the Ready for Windows site.

The problem, of course, is that you have to re-evaluate and re-test your programs every six months (or, if you decide to skip a version or two, every 12 to 18 months). That argues well for an automated app testing regimen.

4. Automate upgrades as much as possible

In fact, the whole process of testing version upgrades — Windows itself, programs such as Office, drivers, and LOB apps — is screaming for automation. Michael Niehaus — who’s become the face of Microsoft’s Windows as a Service — recommends that you look at the process in three steps:

The never-ending six-month cycle that Niehaus recommends goes like this:

  • Plan and Prepare: run the Insider beta builds on test machines
  • Targeted Deploy: when the new version is released, deploy it on 10% of your machines to see if there are any problems
  • Broadly Deploy: “For some organizations, broad deployment can begin quickly; for others it can take longer. It is up to each organization to determine when to make that transition.”

It’s important to realize that the steps overlap each other: If you’re going to stay on the every-six-month schedule, you need to be at the Plan and Prepare stage at the same time you’re on the Broadly Deploy stage, particularly if shaking out bugs takes four months.

If that sounds like a full-time job, you’re likely right. In a larger organization, planning and churning through new versions of Windows every six months may well warrant a sizable staff. It will certainly require hardware and software resources.

David das Neves, an engineer at Microsoft Germany, has developed a detailed procedure to break out the steps and automate some of the process. At the core of his idealized deployment infrastructure: System Center Configuration Manager (SCCM). His description is lengthy and complex, but larger organizations may well save time and resources if they can put the full mechanism in place.



Comments