Asset Deployment Strategy

Deploying the Stairwell forwarder strategically -- rather than in a random order across your fleet -- reduces total upload volume, shortens backscan times, and ensures your environment builds a clean baseline from the start.

Why deployment order matters

Stairwell deduplicates files globally. When an asset uploads a file, Stairwell checks whether it already has that file from another asset in your environment. If it does, the file is not re-uploaded -- the system simply records a new sighting.

This means: each asset you deploy gets cheaper. The first machines upload the most. By the time you're deploying your 200th workstation, most of the files on it are already known, and the forwarder uploads almost nothing.

Deploying in the right order takes advantage of this from the beginning.

Recommended deployment sequence

1. Golden image or lab machine

Start with a clean baseline machine -- your standard workstation image, a lab system, or a freshly provisioned server. This primes Stairwell with knowledge of your standard software stack (OS, approved applications, common frameworks).

Every subsequent deployment will find fewer unique files because the golden image already covered your software baseline. This dramatically reduces upload volume and backscan time for the rest of your fleet.

*Note that it is recommended to deploy to lab machines in a separate lab environment.

2. File servers and shared drives

Deploy to file servers and network-attached storage early. These hosts have wide file coverage and surface files that may be sitting on shared drives across the organization.

Note: the Stairwell forwarder ignores mapped network drives on endpoints. To collect from a file server, deploy the forwarder directly on the server -- not on the clients that access it.

3. Endpoint cohorts (similar machines together)

Deploy in groups of organizationally similar systems: all finance workstations, then all legal workstations, then all engineering workstations. Machines in the same cohort share most of their installed software, so the first few deployments in each cohort cover the group's unique files and subsequent deployments find almost nothing new.

This batching approach keeps upload volumes manageable and makes it easier to troubleshoot if a specific cohort has connectivity or policy issues.

4. High-churn and sensitive systems last

Deploy to developer workstations, build servers, and other high-churn systems after the rest of the environment is covered. Before deploying to these systems:

• Work with the team to identify build output directories, package caches, and other high-volume paths that should be excluded.
• Configure deny paths via a Stairwell policy before the first deployment on these systems.
• See Forwarder Performance Tuning for specific guidance on developer environments.

Setting deployment expectations

Timeline: Most environments complete full fleet deployment in 2--6 weeks, depending on fleet size, packaging tooling, and change-management processes.

Upload volume: Expect heaviest upload activity during the first 20--30% of your deployment. After that, each new batch of similar systems adds progressively less.

Backscan duration: A standard endpoint takes 2--8 hours to complete its initial backscan. Dense systems (file servers, developer machines with large build caches) may take longer. Normal endpoint activity continues during the backscan -- it does not need to complete before the forwarder begins responding to new file events.

Tracking deployment health

After each deployment batch:

• Confirm assets appear in Stairwell with a recent check-in timestamp.
• Verify sighting activity is arriving (indicates the forwarder is running and collecting).
• Check for assets that appear registered but have stale last-seen times -- these may indicate connectivity or service issues requiring attention before the next batch.