Why compare Cloud PC or VDI with physical desktop TCO?
A physical PC presents a visible purchase price, while a Cloud PC or virtual desktop presents a visible monthly seat charge. Comparing only those two numbers can hide most of the decision boundary.
Physical desktops also bring refresh, repair, electricity, imaging, deployment, help-desk, shared management, and disposal cost. Cloud delivery also brings endpoints, user licensing, concurrent compute, profile storage, network, security, image administration, migration, training, and data-export cost.
This calculator places those items on the same 36-month or 60-month cash-flow timeline and compares both nominal and present-value TCO.
Moving compute to the cloud does not normally remove the physical endpoint. Users still need a supported laptop, thin client, monitor, keyboard, audio device, and reliable network.
The cloud option therefore has its own endpoint purchase, refresh, repair, electricity, deployment, and residual-value inputs. You can enter zero for a reused device or a cash-only BYOD view, but the calculator warns you to review security, support, and opportunity cost separately.
Decisions the model is designed to support
- Which option has lower three-year and five-year TCO after office, development, and graphics users are separated?
- Is the difference driven by devices, recurring provider charges, electricity, or internal operations effort?
- At what user count does fixed platform cost spread far enough to change the result?
- At what common concurrency rate does pooled VDI compute change the present-value winner?
- Does the conclusion survive the next device refresh and the remaining residual value?
Separate fixed Cloud PC seats from pooled VDI consumption
Fixed per-user Cloud PC
A Windows 365-style quote assigns a Cloud PC license to a user. Enter that amount as the monthly fixed seat price for the matching workload profile.
If compute and base storage are included in the seat, leave the concurrent compute rate and additional storage fields at zero so that the same service is not counted twice.
Pooled virtual desktop infrastructure
Azure Virtual Desktop-style delivery can separate access licensing from the Azure resources that host user sessions. Use an official pricing calculator or an actual bill to normalize host consumption per concurrent user-hour and profile storage per user-month.
The model does not invent a VM SKU, session density, region, reservation, or autoscale schedule for you.
When both a seat and compute rate are positive
This combination is not automatically wrong. A separately licensed pooled deployment can legitimately have both access rights and resource consumption.
It is wrong when a fixed Cloud PC seat already includes compute and the same compute is entered again as an hourly charge. The calculator keeps the input but raises a boundary warning so that you can check the written quote.
Build an equivalent comparison baseline
1. Segment office, development, and graphics users
Browser and document work, compilation and data tools, and GPU or high-resolution graphics should not share one untested size. Enter users, concurrency, active hours, physical PC price, fixed cloud seat price, pooled compute rate, and additional storage separately for each profile.
The profile labels are not SKU recommendations. Confirm CPU, memory, storage, GPU, display, and application requirements with device telemetry and a representative proof of concept.
2. Convert internal effort into loaded cost
Loaded labor cost should use one consistent treatment of compensation, benefits, and organizational overhead. The desktop side counts deployment and recovery effort at every refresh plus monthly help-desk hours.
The cloud side counts endpoint deployment, image and profile administration, host and cost management, support, migration, and initial training. Do not claim staffing savings unless the measured time can actually be removed or reassigned to useful work.
3. Align work location and network scope
The remote-work share applies to the physical option remote-access input and helps you check the network scope of the cloud quote. It does not automatically monetize office space, commuting, or productivity.
Latency, jitter, bandwidth, video quality, USB, printing, camera, and audio compatibility remain proof-of-concept questions. Add actual circuit, dedicated connectivity, firewall, or support quotes when the target design requires them.
Calculation method, refresh events, and residual value
Monthly TCO combines recurring cost, device purchases, deployment and training labor, shared upfront cost, and exit cost, then subtracts the residual value of the assets still held at the end of the horizon.
Every monthly cash flow uses the same annual discount rate. Desktop provider cost, cloud provider cost, loaded labor, and electricity can use separate annual growth assumptions so that one forecast is not silently applied to unrelated items.
Physical desktop recurring cost
repair + software and security
+ remote access + electricity
+ help-desk labor
+ shared infrastructure
Cloud recurring cost
fixed seats + concurrent compute
+ storage + incremental licensing and network
+ endpoint repair and electricity
+ administration + shared platform
Refresh and residual-value convention
Both the physical PC fleet and the cloud endpoint fleet are purchased in month one and refreshed as a full cohort at their separate user-entered cycles. This is a planning simplification rather than an asset-ledger model.
The final residual factor declines linearly from 100 percent at purchase to the user-entered end-of-life residual at the refresh point. A 36-month device viewed over 36 months reaches its end-of-life residual, while a 48-month endpoint viewed over 36 months retains twelve months of modeled life.
Replace the assumption with evidence from your asset register and recent disposal or resale outcomes. It is not a forecast of accounting book value or market resale price.
Read the 36-month and 60-month views together
Decision focus across the 36-month and 60-month TCO views| Period | Cost that becomes visible | Decision to review |
|---|
| First 12 months | Devices, peripherals, setup, migration, and training | Peak funding and transition readiness |
| 36 months | Medium-term contracts and the first desktop refresh boundary | Three-year sourcing and refresh decision |
| Months 37 to 60 | Second device purchases and continued cloud seats | Whether lifecycle timing reverses the result |
A three-year view can miss a refresh just beyond month 36. A five-year average can make a large first-year transition look smaller than the cash funding it requires.
Check whether the winner is the same in both horizon rows. If it changes, use the annual cumulative present-value table to identify the device refresh or recurring provider charge that creates the crossing.
Worked example with ten fictional users
The figures below are unit-test values in fictional currency units, not market prices or vendor benchmarks. The example has ten office users, 50 percent concurrency, 100 active hours per month, no cost growth, no discounting, and a 36-month horizon.
The desktop has a purchase cost of 1,000 per user, peripherals of 100, and enough repair, software, network, electricity, support, and shared cost to produce a first-month recurring cost of 1,100.
The cloud option has a seat of 40, concurrent compute of 0.2 per hour, storage of 5, an endpoint of 200, and a large shared setup cost of 10,000. Its first-month recurring cost is 1,115.
Ten-user fictional validation scenario| Metric | Physical desktop | Cloud PC or VDI |
|---|
| First-month recurring cost | 1,100 | 1,115 |
| Device purchases | 10,000 | 2,000 |
| Operations, deployment, and training effort | 380 hours | 115 hours |
| 36-month nominal and PV TCO | 53,700 | 54,590 |
Interpretation of the example
At ten users, the physical desktop is lower by 890. The large shared cloud setup is spread across more seats as the modeled organization grows, producing a user-count break-even near 11 users.
If all three profile concurrency rates are replaced with one common rate, the concurrency break-even is about 37.64 percent. Neither number is a market threshold; each is only the crossing implied by the fictional inputs.
Interpret break-even and sensitivity carefully
User-count break-even
The calculation preserves the current mix of office, development, and graphics users and scales all profile counts together. Shared setup and monthly platform cost stay fixed while user-level costs scale proportionally.
Actual minimum seats, volume tiers, host rounding, and contract thresholds can make the real quote stepwise. Request quotes at the adjacent integer user counts before relying on the crossing.
Concurrency break-even
The model keeps user counts and active hours fixed, then assigns one common concurrency percentage to all three profiles. It finds the point where pooled compute makes both present-value TCO results equal.
A fixed-seat Cloud PC with a zero hourly compute rate is insensitive to this value, so no crossing is a valid result.
The sensitivity table compares the current user-weighted concurrency with values twenty percentage points below and above it, bounded at zero and 100 percent.
If the winner changes frequently across the three rows, collect a distribution by hour, weekday, peak season, and disconnected session rather than committing from one average.
Proof-of-concept and quote checklist
- Measure user profiles. Collect at least several weeks of CPU, memory, GPU, storage, active time, concurrency, and network-quality evidence for the three workload groups.
- Request the same written scope. Ask every supplier to separate seats, VMs, disks, profile storage, backup, traffic, licensing, security, support, tax, currency, commitment, termination, and export.
- Inventory endpoints separately. Review remaining life, thin clients, laptops, monitors, docks, headsets, video offload, and peripheral compatibility.
- Run a representative proof of concept. Test headquarters, home, branch, and other real locations with login, applications, compilation, graphics, meetings, printing, USB, offline work, and recovery.
- Replace assumptions with measured values. Re-enter concurrency, active hours, administration effort, extra licensing, and network cost from the trial before reviewing both horizons again.
Limits and cautions
- The calculator does not recommend a Windows 365, Azure Virtual Desktop, Citrix, Omnissa, AWS WorkSpaces, physical PC, or other vendor product.
- It does not determine Microsoft 365, Windows, VDA, RDS, Office, Defender, Intune, contractor, or external-user licensing rights.
- It does not size session hosts, choose VM SKUs, set session density, model minimum active hosts, or reproduce reservations, savings plans, and autoscale schedules.
- It does not calculate tax, currency conversion, recoverable indirect tax, depreciation, lease classification, impairment, or contract termination treatment.
- It does not invent productivity gains, office-space savings, hiring benefits, outage probability, security-loss reduction, or carbon value.
- User counts remain constant during the horizon and each device fleet refreshes as one cohort. A changing workforce or asset-level acquisition dates require a separate cohort model.
Frequently asked questions
Can I enter only the Cloud PC seat price?
Yes, if the seat truly includes compute, storage, management, security, and support, and every separate endpoint, network, migration, training, administration, and exit input is intentionally zero.
Most quotes have exclusions, so confirm the written scope before leaving those fields empty.
How should I model an existing PC reused as the cloud endpoint?
A cash-only view can set endpoint acquisition to zero. A full economic view should consider remaining life, the next refresh, repair, electricity, security, support, and the value of any alternative use.
How do I measure concurrency?
Divide simultaneous signed-in users at a point in time by the total users in the profile, then review the distribution across several weeks. Include peaks, disconnected sessions, seasonal demand, minimum hosts, and ramp-up timing in the supplier design.
Is lower present-value TCO enough to approve migration?
No. Cost does not replace performance, latency, GPU, offline, peripheral, security, data-residency, licensing, recovery, accessibility, and contract review.
Use TCO to structure the shortlist, then complete a proof of concept and security, legal, finance, and operations review.
Why is there no user-count break-even result?
The two present-value cost lines may not cross between zero and 100,000 users, or their fixed and per-user structures may be parallel.
If the supplier has minimum seats or volume tiers, compare separate quotes at the relevant integer thresholds.
Official sources and update boundary
Sources were checked on August 14, 2026. Present-value and lifecycle structure follow NIST Handbook 135e2022, while complete-cost and sensitivity discipline follows GAO-20-195G.
Microsoft documentation supplies the boundary for assigned Windows 365 licenses, Azure Virtual Desktop resource and licensing cost, autoscale, workload sizing, endpoint requirements, and network quality. No Microsoft list price is embedded in the calculator.
- NIST Handbook 135e2022 for lifecycle cost and present value
- GAO-20-195G for complete cost, assumptions, and sensitivity
- Assign licenses for Windows 365 for the per-user seat boundary
- Understand and estimate Azure Virtual Desktop costs for resources and licensing
- Licensing Azure Virtual Desktop for internal, external, and product rights
- Azure Virtual Desktop autoscale scenarios for concurrency and host scheduling
- Cloud PC size recommendations for workload segmentation
- Cloud PC endpoint requirements for the continuing physical-device boundary
Build a TCO baseline from actual quotes and measured usage
Start with the three workload profiles and your current refresh and support cost, then normalize every cloud inclusion to the same unit.
Once the 36-month and 60-month winner and break-even points are visible, use the result as the baseline for the proof-of-concept checklist and supplier quote comparison.