A technical, reseller-focused guide to moving customers off ageing RDS environments and onto a modern remote desktop platform.
If you support customers who’ve been running Remote Desktop Services for more than a few years, you already know the pattern: the server is getting old, the CALs are from two versions ago, the Windows Server edition is approaching or past end of support, and nobody’s entirely sure whether the licensing is compliant.
Now add that Microsoft officially began retiring the legacy Remote Desktop app from the Microsoft Store in May 2025, replacing it with the Windows App that pushes users toward Microsoft’s cloud ecosystem. The message from Redmond is clear: the legacy on-premises RDS experience is being deprioritised in favour of Azure Virtual Desktop and cloud-hosted solutions.
For many SA SMBs, moving to Azure isn’t practical or affordable. But staying on an ageing, unsupported RDS deployment isn’t an option either. CloudWare gives you a modernisation path that keeps things on-premises (or hosted locally), simplifies the licensing, and improves the user experience — all without requiring a forklift migration.
Here’s how to approach it.
Step 1: Assess What They’re Actually Running
Before proposing a migration, you need to understand the current environment. The discovery conversation should cover:
Server hardware and OS version. What Windows Server version is the RDS host running? Server 2012 R2 and 2016 are past end of mainstream support. Server 2019 is approaching the same milestone. If the hardware is older than 5 years, it’s likely due for replacement regardless of the software decision — which creates a natural opportunity to deploy CloudWare on fresh infrastructure.
Current licensing status. This is where you often uncover problems. Ask to see their RDS CAL documentation. Are they using Per User or Per Device CALs? Are the CAL versions compatible with their server version? (Remember: RDS CALs are backwards-compatible only — 2022 CALs can’t access a 2025 server.) Many businesses are running on the 120-day grace period and never properly licensed, or they licensed years ago and added users without buying additional CALs.
Published applications vs full desktop. Are users connecting to a full remote desktop, or are specific applications published as RemoteApps? This affects how you configure CloudWare — whether you’re replicating a full desktop experience or publishing individual applications.
Number of concurrent users. Not total users — concurrent users. A business with 30 staff might only have 10–15 connected to RDS at any given time. This number drives your server sizing and licensing requirements.
How users connect. Are they using the built-in Windows RDP client? The legacy Remote Desktop app? A third-party client? Are they connecting from managed corporate devices or personal BYOD machines? This determines whether you’ll migrate them to CloudWare’s HTML5 browser access, an RDP client, or a mix of both.
Line-of-business applications. What applications are being served via RDS? Accounting packages (Sage, Pastel, QuickBooks), ERP systems, CRM tools, practice management software? These applications need to be tested on the new CloudWare environment before you cut over users.
Step 2: Plan the CloudWare Environment
With the assessment complete, you can architect the replacement. Key decisions:
Server hardware. If the existing server is recent enough and properly specced, you may be able to reuse it with a fresh OS install and CloudWare. If it’s aged or undersized, recommend new server hardware as part of the migration project. For most SMB deployments (10–30 concurrent users), a single well-specced server with a current-generation Xeon or EPYC processor, 32–64GB RAM, and fast NVMe storage is sufficient.
Windows Server version. Deploy on the most current supported version — Windows Server 2025 Standard for most SMB scenarios. This gives the customer the longest support runway and avoids the backwards-compatibility CAL trap when they eventually need to upgrade.
CloudWare licensing. Work with CloudGate to determine the right CloudWare licence tier for the customer’s user count and requirements. Unlike the Microsoft RDS stack where you need to calculate and purchase Windows Server CALs + RDS CALs separately per user, CloudWare’s licensing is straightforward to quote.
Application compatibility. Install and test every line-of-business application on the CloudWare server environment before migration. Most Windows applications that worked on traditional RDS will work on CloudWare without modification — but testing is non-negotiable. Pay particular attention to applications that use hardware dongles, local printers, or COM port devices, as these may require additional configuration.
User access method. Decide whether users will connect via HTML5 browser (simplest for BYOD and mixed environments), native RDP client (best performance on managed Windows devices), or a mix. CloudWare supports both, so you can offer HTML5 as the default with RDP as an option for power users who want the native experience.
Step 3: Deploy in Parallel
The golden rule of any migration: don’t cut over cold. Deploy CloudWare alongside the existing RDS environment and run them in parallel until you’re confident everything works.
Install CloudWare on the new server (or the existing server if you’re doing an in-place modernisation) and configure the application publishing and desktop delivery.
Migrate users in groups, not all at once. Start with a pilot group of 3–5 technically comfortable users. Let them work on CloudWare for a week. Gather feedback on performance, application behaviour, printing, and any workflow issues.
Test critical workflows end-to-end. It’s not enough to verify that the application launches. Test the actual business processes — can the accountant process a payroll run? Can the lawyer generate a report from the practice management system? Can the branch manager pull inventory data? These functional tests catch issues that a simple application launch test misses.
Keep the old environment running as fallback. Until the migration is fully validated, the legacy RDS environment stays live. If a critical issue emerges, users can fall back to the old system while you troubleshoot. Only decommission the old environment once all users have been on CloudWare for a reasonable period (typically 2–4 weeks) without issues.
Step 4: Address the Common Pain Points
Every RDS-to-CloudWare migration surfaces a few common issues. Knowing them in advance makes you look prepared and competent:
Printing. Remote printing is the perennial headache of every remote desktop deployment. Test printer redirection thoroughly — both for local printers (when users are in the office) and for remote printers (when users are at home). CloudWare handles printer redirection, but specific printer models and drivers can cause issues. Resolve these during the pilot phase, not during full rollout.
Profile and settings migration. If users had personalised settings, saved files, or application configurations on the old RDS server, these need to be migrated to the new environment. Plan for this explicitly — don’t assume users will reconfigure everything themselves.
Drive mapping and file access. Ensure that mapped network drives, shared folders, and file server access work correctly from the CloudWare environment. Users who are accustomed to seeing their S: drive or their department’s shared folder will immediately notice if it’s missing.
User training. The connection method may change — from launching a Remote Desktop shortcut to opening a web browser and logging into a CloudWare portal. Even a simple change like this requires communication. Send clear instructions to users before the cutover, ideally with screenshots. A five-minute walkthrough saves hours of support calls.
Multi-factor authentication. If the old RDS environment didn’t use MFA, consider enabling it as part of the migration to CloudWare. It’s a security improvement that’s easier to implement during a migration than as a retrofit. Modern remote desktop solutions support MFA integration, and for any externally accessible remote access, it should be considered mandatory.
Step 5: Decommission and Document
Once all users are on CloudWare and the parallel period is complete:
Decommission the old RDS server. Remove the server roles, back up any remaining data, and either repurpose or decommission the hardware.
Retire old RDS CALs. If the customer purchased RDS CALs for the old server version, note that these can be used on the same or earlier versions of Windows Server if needed elsewhere — but they can’t be repurposed for a newer server version. In most cases, they simply become surplus.
Document the new environment. Deliver the customer a document covering: server configuration, installed applications, CloudWare licensing details, user access methods, admin login credentials, backup schedule, and a basic troubleshooting guide. This documentation is valuable to the customer and positions you as a professional services provider, not just a box seller.
Set up monitoring and support. If you’re providing ongoing support (and you should be — that’s where the recurring revenue lives), establish monitoring for the server and CloudWare environment. Proactive alerts for disk space, memory usage, and session counts prevent issues before they become outages.
What This Means for Your Business
A legacy RDS migration project is one of the highest-value engagements a reseller can deliver to an SMB customer. It combines:
Hardware sales — new server, potentially new CloudGate endpoints.
Software licensing — CloudWare licences, Windows Server licence.
Professional services — assessment, deployment, testing, user training, documentation.
Ongoing support — monitoring, maintenance, licence renewals, user management.
That’s a multi-layered revenue opportunity from a single customer engagement. And every customer running an ageing RDS environment — and there are thousands of them across South Africa — is a candidate.
The migration conversation starts with a simple question: “When was the last time you checked your RDS licensing compliance?” The answer almost always opens a door.
The Bottom Line
Microsoft’s direction is clear: the legacy on-premises RDS experience is being deprioritised. For SA SMBs that can’t or won’t move to Azure Virtual Desktop, that creates an urgent need for a modern alternative that’s affordable, deployable, and supportable by the local IT channel.
CloudWare is that alternative. And for resellers, the migration from legacy RDS to CloudWare is a repeatable, high-value service engagement that turns a licensing compliance headache into a modernisation project — with hardware, software, and recurring support revenue built in.
CloudWare migration support is available through the CloudGate reseller channel. Contact info@cloudgate.co.za or call 010 140 4400 for migration assessment tools, technical guidance, and reseller pricing. Visit www.cloudgate.co.za for product documentation.