HP is winding down HP Anyware. New sales stop on May 7, 2026. Support and maintenance run through October 31, 2029. The Trusted Zero Clients and the rest of the PCoIP hardware estate are end-of-lifed alongside the software. HP is pointing customers at HP Z Remote Graphics Software (RGS) as the replacement for the workstation use cases that still fit. That story works for some fleets. For a lot of the studios we talk to, it doesn't. The protocol swap is the small part. The operating model around the protocol is the work, and any honest migration plan for a mixed-OS shop is at least two protocols, not one.
The timeline is generous. You have working software with vendor support for another three and a half years. The studios most at risk here are the ones who treat the announcement as a procurement emergency and lock in a replacement this quarter that they then live with for the next decade. Anyware migration is the kind of decision that wants a real evaluation cycle, two or three pilot teams on the shortlist, and a proper read on artist experience under load. None of that fits inside a panic window.
The honest read is that this is the forcing function a lot of session-broker re-architecture has been waiting for. Studios that grew up on Teradici through the PCoIP years have estates architected around assumptions from 2018 or 2019. Identity sits in one corner, license servers in another, the broker is doing more than its share of the load, and the color-managed reference monitor pipeline was tuned for a specific protocol's behavior and never re-validated. Anyware kept working, so nobody re-opened the question. Now the question is open. The teams that use this window well will come out of it with a session broker they actually understand, a license inventory that reflects what's installed rather than what was bought, and an identity story that survives the next audit. The teams that don't will end up running the same architecture on a new protocol and discovering, eighteen months in, that nothing got cleaner.
The protocol question is the easy part of this. Pixel streaming has matured. RGS is a real product with real lineage. Amazon DCV is in production at meaningful scale across our peer set. Parsec for Teams and Splashtop Business have moved well past the prosumer ceiling. The browser-native challengers are getting genuinely usable for certain artist roles, particularly review and approval flows. You can pick a protocol on a Tuesday. The harder questions sit one layer up. Who owns the session broker once you've migrated, and is that the same team who owned the PCoIP estate? How do you handle license sprawl during the eighteen to twenty-four months when half the fleet is on the old protocol and half is on the new? And what about the color pipelines that were calibrated against PCoIP's specific chroma subsampling behavior, validated against the new protocol without burning a week of supervisor time per show? Those are the questions that decide whether the migration is a success.
The genuinely awkward bit is macOS. HP RGS supports Windows and Linux as the workstation host. There is no Mac sender path. For a Windows or Linux post house, that's a constraint you can plan around. For a Mac-heavy creative agency, a color house running on Mac Pros, or any of the editorial shops that standardized on Apple silicon over the last few years, RGS handles the Windows and Linux parts of the fleet and the Mac side needs a separate evaluation. Realistic alternatives there: Amazon DCV has a macOS server, but only on EC2 Apple silicon instances - it hosts cloud Macs, it will not stream your on-prem Mac Pros. Parsec and Splashtop both run as native Mac senders, and a couple of the browser-native options are starting to look credible for editorial-class workloads. None are drop-in equivalents to PCoIP. Latency, color under load, license and security postures all differ. Pick one without piloting it under your actual reference monitor and you'll spend the year after the cutover apologizing to your colorists.
If you're running a mixed-OS estate, your migration plan is two protocols. Stop trying to make it one. The cost of running two pixel-streaming stacks in parallel for the migration window is real but bounded. The cost of forcing the Mac side onto a protocol that doesn't fit, or of leaving the Mac fleet on Anyware until the support clock runs out in October 2029 with no replacement chosen, is much larger and much harder to unwind. The May 7, 2026 sales cutoff is a procurement deadline. Operationally, the October 2029 support window is the real runway. Use the next six months to inventory honestly: hosts, OSes, artist roles, color-critical pipelines, license stacks. Use the six months after that to pilot two or three candidates against your actual workloads rather than vendor benchmarks. Then make the call with twelve to eighteen months still in the bank, enough to migrate without rushing and enough to back out of a wrong call if the pilot doesn't survive contact with the work.
I've watched a few of these protocol transitions over twenty years inside studios. They are never as clean as the migration document suggests, and they are never as catastrophic as the first vendor briefing implies. The ones that go well are the ones where the operations team treated the transition as a chance to fix the architectural debt they already knew about. The Anyware EOL is the same shape. Three and a half years is enough time to do it properly. Whether you actually do it properly is the only interesting question on the table.
