Contractor Windows Desktop Handover: Access, Files and Monthly Costs

Start with a project environment the contractor can use

Fictional Harbour Operations brings in Jules to improve a client application across two development sprints. A useful Windows workspace includes the chosen editor, Git, runtime, repository access, build instructions, approved test accounts and a project folder. The point is a complete environment that can be resumed across the contract, not a single sample-file demonstration.

The business and contractor must install and configure their chosen applications and confirm licensing for a cloud Windows environment. Test the actual project’s dependencies and resource requirements. Do not assume support for nested virtualisation, a hardware dongle or every development tool. The screenshots here show current Jump-Teams with fictional people; no paid desktop was provisioned and no client application was executed for this demonstration.

Keep the access layers separate

Administrator may be needed for approved installation or configuration work. Standard can be appropriate for day-to-day use of already configured applications. Neither label replaces application-level permissions, project confidentiality rules or a backup process. A Team Admin is not automatically the same thing as a Windows Administrator.

Prepare the first session

1. Write the project brief. Name the deliverable, applications, repository, test data, working dates and handover owner.
2. Choose the desktop. Select a region and size for the contractor’s device, connection and workload. Decide Months or Hours from expected use.
3. Set up access. Invite the correct person, assign responsibility and configure the separate Windows account and privilege required.
4. Prepare the tools. Install licensed applications, check versions and keep secrets out of reusable instructions and screenshots.
5. Rehearse the work. Confirm the contractor can connect, open the project, run the agreed build or business task and save the result where the business expects it.

A complete working check must be done by the people operating the real environment. Do not interpret an illustrative Team screen as proof that an application or project is ready.

Make handover part of the working routine

Agree where the current source, project files and exported business records belong. Keep a short setup note with application versions, repository location, build steps and known issues. Store passwords and tokens in an appropriate approved secret store, not in that note or a shared connection file.

Schedule a review before the contract ends. The owner should know what is complete, what is unfinished, which applications are licensed to whom, and what must be transferred. A persistent desktop can preserve the working environment while retained, but the business should keep separate copies of the records it needs.

For monthly work, review the desktop’s actual billing date and up-to-300-hour uptime allowance. Stop it when work finishes. For Hours, include retained service charges even during a quiet handover week. Use the team budget worksheet to avoid treating a stopped desktop as a zero-cost desktop.

Complete the handover before ending access

1. Inventory the work. List source, documents, exports, unfinished tasks and application setup notes.
2. Transfer and verify. Put the required files in business-controlled storage and confirm the owner can open them. For a development project, rehearse the documented build in the intended successor environment.
3. Review application ownership. Transfer repository or document ownership where necessary and check licence reassignment rules.
4. Review credentials and permissions. Revoke obsolete tokens and application access through their respective services. Review Windows access and Team membership separately; do not assume one removal covers everything.
5. Decide the desktop’s future. Keep it for an authorised successor, retain it temporarily under an explicit budget, or end it through the product’s available controls after checking the consequences.
6. Verify closure. Check remaining access, billing and retained data rather than treating a single click as complete offboarding.

Deleting a desktop can permanently remove its data. Complete and verify the export before choosing deletion. Cancellation, stopping, removing membership and deleting the machine are different actions; follow the notices shown for the actual resource.

When a monthly contractor workspace makes sense

Months can fit a contract with recurring Windows work over a predictable billing period. It gives a full monthly desktop price with up to 300 uptime hours, while the project environment remains available between sessions. Hours may be cheaper for light or irregular work once compute and retention are both included. Neither plan makes application licences or contractor onboarding automatic.

For simultaneous work, give the contractor and internal colleague separate suitable desktops: one active Windows user can use a desktop at a time. See remote team onboarding for the joining process and the Jump-Teams walkthrough for the product’s people and desktop controls.

Questions to settle before you choose

Plan your first working desktop

Choose the actual role, applications, device and working hours first. Then use the Jump-Teams guide to organise access and the current calculator to compare plans. A representative working test is more useful than buying capacity for an assumed workload.