WSUS deprecated -
migration plan to Endpoint Central

WSUS (Windows Server Update Services) - the system that has underpinned patch management in Poland for many years - is entering a wind-down phase. In September 2024 Microsoft announced that WSUS is deprecated. What does that mean in practice? WSUS still works and is supported, but Microsoft will no longer develop it - no new features, and the direction is cloud solutions. This is not a crisis to fix yesterday, but a clear signal to plan migration. In this article I show a plan to move from WSUS to Endpoint Central: 7 steps, a schedule, risks, and real costs.

What does it mean that WSUS is deprecated?

In September 2024 Microsoft announced that WSUS is deprecated. This is an important distinction - "deprecated" is not the same as "end of support". In practice it means:

• No further development - Microsoft no longer adds capabilities to WSUS and does not accept new feature requests.
• WSUS still works - existing functionality is preserved and updates are still published via the WSUS channel.
• No hard end-of-life date - Microsoft has not announced an end-of-support or removal date and declares feature support within the Windows Server 2025 lifecycle.
• A clear direction - Microsoft recommends moving to cloud solutions: Intune and Windows Autopatch for workstations and Azure Update Manager for servers.

Why did Microsoft do this? WSUS is older technology - its interface and management model do not keep up with modern scenarios (remote laptops, mobile devices, hybrid work). Microsoft steers customers toward cloud solutions, but for companies that need on-premise, Endpoint Central is a strong alternative.

Risk of staying on WSUS in the long run

WSUS works today and is supported - no need to panic. The problem appears over a few years, if you leave patch management on a tool that is no longer being developed:

• Functional stagnation: WSUS will not gain support for new scenarios (remote devices, multi-OS, modern reporting). Over time it will become harder to cover real business needs with it.
• Compliance: Auditors increasingly note the use of technology that has been withdrawn from development. It is worth having a documented migration plan.
• Technology risk: The longer you stay on a tool without development, the harder and more sudden the migration may become in the future.
• Limited scope: WSUS only handles Microsoft updates - it does not patch third-party applications or non-Windows systems.

Rotech Group observes that many Polish companies stay on WSUS because "it works and is not broken". That is true - but the deprecated status is a good moment to calmly plan a move to an actively developed solution, before it becomes a necessity.

Comparison of alternatives: Endpoint Central vs Intune vs NinjaOne

Migration plan from WSUS to Endpoint Central - 7 steps

• Step 1: WSUS audit (week 1)

  Log into WSUS, check: how many computers are syncing, how many patches are already deployed, what problems exist (orphaned computers, sync errors). Create a CSV with the list of machines (hostname, IP, OS, Windows version). This will be input for Endpoint Central.

• Step 2: Install a test Endpoint Central instance (week 1-2)

  Test server on Windows Server 2019+, Endpoint Central installation (15 GB disk, 8 GB RAM minimum). Install the agent on 5-10 test machines. Make sure the agent starts, communicates with the server, and collects inventory. If OK, move to step 3.

• Step 3: Copy WSUS configuration to Endpoint Central (week 2)

  In Endpoint Central: Patch Management > Policies. Create a new policy matching your WSUS policy. Example: WSUS has a schedule "Security patches every second Sunday at 2:00" - replicate the same in Endpoint Central. The goal is zero changes to schedules, just a different system.

• Step 4: Test deployment - 5% of machines (week 3)

  Install the Endpoint Central agent on 5-10% of your machines (a representative sample: mix of laptops and desktops, different OS). Monitor for 1-2 weeks: do agents install, do they collect data, do patches deploy on schedule. Reporting: the Endpoint Central dashboard shows live progress.

• Step 5: Roll-out phase - 50%, then 100% (weeks 4-6)

  After verifying on the test group, deploy to all machines in phases: 50% on Monday, 100% on Friday. Every 1-2 days check the dashboard: are agents installing without errors, are there network or firewall issues. If there is an error on 10% of machines (which is normal), fix it for those 10% and retry.

• Step 6: Decommission WSUS (weeks 6-8)

  When 90%+ of machines have the Endpoint Central agent, you can disable WSUS: stop the WSUS service (WsusService) on the server, but do not remove the role immediately - keep it for 2-3 months as a backup. If a problem appears, you can fall back quickly.

• Step 7: Training and documentation (weeks 6-8)

  Training for the IT team: how Endpoint Central works, how to read dashboards, how to escalate problems. Documentation: patching procedures, schedules, support contacts. Reporting for the director: before/after - WSUS metrics vs new Endpoint Central metrics.

Migration costs and ROI - how much can you save?

Direct migration costs (50-200 machines, 3-4 weeks):

• Endpoint Central Professional license (1 year): approx. 8,000-12,000 PLN
• Implementation (setup, tests, training): approx. 10,000-15,000 PLN
• Test server (can be a VM, no extra hardware costs)
• Total: approx. 18,000-27,000 PLN

Potential savings - illustrative example:

The numbers below are only an illustrative calculation - plug in your own data. Real savings depend on infrastructure scale, hourly rates, and current processes.

• Reduced administration time: if the IT team currently spends, say, 1-2 days per month on manual WSUS work, automation in Endpoint Central can free a meaningful portion of that. Example: 100 hours per year at 50 PLN/h is about 5,000 PLN.
• Lower incident risk: faster and more complete patching (including third-party applications) reduces attack surface. Savings from avoided incidents are hard to estimate - they depend on industry and risk profile.

ROI: Calculate payback time on your own data - divide the actual migration cost by realistic, measurable savings (mainly IT time). Treat reduced incident risk as a supporting argument that is hard to quantify, not as a hard line item in the calculation.