Application Readiness is delighted to announce we’ve teamed up with Zaptz Pty Ltd. Tasmania-based Zaptz will incorporate Readiness technology into their suite of proprietary products which automate Microsoft Server application migrations for their global customer base.
I had a chance to speak with Zaptz’s Business Development Leader Stephen Burke about the most important factors he sees with application compatibility in the era of Windows-as-a-Service.
Eric Embacher: Good morning Stephen! I think there’s like an 18-hour time zone difference between you and me! I’m in Victoria—Canada that is.
Stephen Burke: Greetings from the future! It’s tomorrow here already. App compatibility is still an issue.
EE: Hehe…I could have guessed that! So I wanted to ask you a few questions about the Zaptz and the state of the industry given your expertise in the industry.
SB: Sure, I’m ready.
EE: Do you think Microsoft’s current approach with Windows 10’s modernizing of the desktop has been effective?
SB: I feel that Microsoft is somewhat prone to over-simplifying some critical issues regarding application compatibility for customers moving to Windows 10. During a presentation last August, while acknowledging application compatibility required a lot of testing to validate apps when migrating to Windows 7, compatibility has become better migrating to Windows 10. They stated a desired approach was to move away from explicitly testing every single application in one’s portfolio, to instead prioritizing and finding the most important business-critical apps and validating those, and for the rest let’s just deploy and see what happens.
While it’s true that compatibility issues have reduced, raw compatibility is only one aspect of assessing the readiness of a client application portfolio for Windows 10 deployment or remediation of legacy Windows Server 2008-based applications to a modern server platform or Azure. Moreover the fundamental change from a 5-year + 5 year support regime to a minimum bi-annual update of the Windows 10 OS itself means that regression testing including compatibility, deprecated resources and sociability testing are also now an ongoing requirement for customers.
EE: I get the feeling that it becomes a bit tricky to propose such an approach to enterprise customers.
SB: Indeed. These companies are used to rigorous risks assessment and project critical path timelines which are expected to be predicated on definitive information.
Their approach doesn’t consider the effort required to “find the most important business critical apps”. Plus, I’m sure that enterprise customers would not appreciate MSAs and SOWs suggesting to “just deploy and see what happens”.
EE: How have the challenges of identifying readiness of applications for migration improved over the years, and how have they not?
SB: Microsoft has achieved significant improvements in assisting clients to identify applications which other customers have deployed via crowd-sourced data. They’ve also improved the tools used to understand the dynamic demographic information required in a migration program. However there is no more capability than the older MAPP tools to understand or determine the technical detail of application compatibility as Citrix AppDNA had done 10 or more years ago.
But Microsoft do not (and never will) map the hard-coded dependencies and references within applications which in many cases need to be modified for those applications to deploy to Modern Windows Servers, Azure and Windows 10.
EE: What is the key differentiator of Zaptz products versus Microsoft’s approach to the Microsoft MAPP or Analytics offering?
SB: We test actual applications in actual client implementation contexts. This includes application compatibility, deprecated resources such as legacy .Net, ASP, COM and IE as well as being able to test against a client SOE and the actual applications in the client’s unique portfolio as the applications have been remediated to be deployed to modern servers, Azure or Windows 10.
Moreover, with our Azure-based solution we can offer an ongoing service—ad-hoc or subscription—to enable the same application testing to be done as an automated process each time customers do their bi-annual Windows 10 updates (or ad hoc security patches for OS and/or applications).
EE: So you’re able to ensure your client’s applications will deploy in the client’s actual environment without repackaging?
SB: Correct. We also make these applications which go through our full service modernization process Intune-ready or deployable from the existing client management platform such as SCCM.
EE: How do you position Zaptz with regards to Microsoft Analytics?
SB: From a customer perspective, an Analytics approach to testing may identify applications that other customers have deployed but in order to deploy in the customer’s own environment they would need to do significant testing of their own. This testing needs to be more than just installing and starting the app, so the time required and skill sets necessary would need to be factored into what this would cost internally. And of course, for those bespoke applications customers have developed and which still support critical business systems, there will be no telemetry from Analytics. Indeed, there will always be a significant proportion of a customer application portfolio where no Analytics data exists.
EE: And what about tools like Desktop App Assure for non-compatible apps?
SB: The standard approach to using this service requires customers to have already done significant testing and to identify the problem to a high degree of granularity before submitting it to Microsoft, thus expending significant time and effort just to qualify to use the service. Our automated assessment process identifies problem apps and provides the required technical details to present to Microsoft without the need for manual testing and documentation. This enables customers to remove a lot of overhead.
EE: Thanks for speaking with me, Stephen. We’re looking forward to working with you.
SB: It was my pleasure, and same here.