Planning terminal servers: use, licensing and migration

Start with applications

Headcount alone is not a sizing metric. Record applications, concurrent sessions, peak periods, data paths and peripherals. Accounting software with a database, large print jobs or graphics-heavy line-of-business applications create different load from office work. Measure CPU, memory and storage I/O during representative periods and label assumptions that remain estimates.

Identity and access

Clarify directory services, multi-factor authentication, roles, external access and disabled-account behaviour. RDP supplies sessions but does not replace an access policy. Clipboard, drive redirection, printers and local devices should be deliberately allowed or restricted. Microsoft documents Remote Desktop Services roles; actual licensing must be checked against users, devices and usage.

Inventory licences

Windows Server, RDS access, Office and business software may use different metrics. Each of the four standard NUXOA terminal plans includes three terminal users; extra users and Office are itemised separately. Check additional software separately. Before quotation list product, version, procurement model, user group and existing agreements.

Pilot and migration

Select genuine pilot users from different roles. Test sign-in, printing, scanners, shares, exports, email integration and sign-out. Inventory profiles and data, set a cut-over window and define a rollback point. Migrate further accounts only after business acceptance. Keep old access paths only as long as the rollback plan requires.

Backup is not migration

Backups protect the new service but do not automatically move profiles, permissions and application settings. Identify data that must remain consistent. NUXOA terminal plans include automatic backups with seven daily onsite and two weekly offsite copies. Your contract specifies retention and recovery objectives. Acceptance should include a documented restore test.

Move locations without hidden dependencies

Check whether business software currently depends on local shares, a licence server or printers with fixed addresses. These dependencies are easily missed when moving into a hosted environment. Record the connections required to office locations and responsibility for their internet access. A central workplace can simplify provisioning, but it cannot compensate for an interrupted connection at the endpoint. The pilot should therefore include testing from the locations where people will actually work.

Derive a workload profile from a real working day

For example, a team has 18 employees, with around ten working concurrently. Everyone starts their business application in the morning, and month-end adds large reports. A measurement on a quiet afternoon misses those conditions. Capture sign-in, normal work and peak activity separately. Include communication between the application and its database, along with long print jobs, rather than watching processor utilisation alone.

Record missing measurements and the headroom reserved for uncertainty. Ten concurrent sessions do not imply a universal memory recommendation. Two business applications may consume more resources per session than several simple office tools. NUXOA's six models provide a starting point, but do not replace testing with your software. Where demand is unclear, a limited pilot provides stronger evidence than an apparently precise calculation based on headcount.

Separate clients, users and licences

A workplace may use a thin client, notebook or another suitable endpoint. Reusing existing equipment depends on its operating system, RDP client, screen configuration and peripherals. Pay particular attention to local scanners, label printers, signature devices and USB-dependent software. Successful sign-in does not demonstrate that those devices support the required workflow or that their manufacturer supports the planned configuration.

For licensing, inventory users and devices separately. Microsoft describes different access-licensing models for traditional RDS deployments; hosting and application terms can add further requirements. Have existing contracts and version rights checked against the actual deployment. An Office licence installed on a local PC cannot automatically be transferred to a hosted multi-user environment. The relevant question is the agreed usage right, not simply whether your inventory includes the product name.

Make acceptance produce a clear result

Create a pilot task list that a business department can execute: open a document, enter a transaction, export a PDF, produce a printout and close the application correctly. Each task needs an expected result and an owner. Repeat important operations with several users working concurrently. A server being reachable is not a substitute for the business team accepting the way its applications work.

For cut-over, specify a final data synchronisation, the point at which old write access is disabled and a clear rollback decision time. Continuing to change the source system after migration can produce conflicting records. Document which system becomes authoritative and when. After the move, review profiles, permissions, backups and the availability of all required services. Keep the acceptance record with the operating documentation so later changes can be checked against it.

• Run the pilot with different user roles and the most demanding workflows.
• Record the data state, cut-over time, approval and rollback decision.
• After migration, check sign-in, printing and restoration separately.

Compare the offer

Compare CPU, RAM, SSD, backup capacity, included users and extra licences. You can choose from four standard plans or two custom configurations on request. Start on the terminal-server page where standard tariffs fit; use a request profile where application load, data or licensing still needs joint sizing.