When software is deployed, there is always a conflict between deploying what “seems to work”, and what “I would ideally like to deploy”. As time passes, and new versions of deployed components are available, this decision has to be made once and again: should I upgrade to new releases, or should I stick to the current deployment that “seems to work”? The problem is more complex in presence of dependencies, which are usual in most of the component repositories used today (generic software distributions, such as Linux-based distributions, or language-specific repositories, such as npm or pypi). To deal with this problem, we introduce the notion of technical lag, which tries to capture the “lag” between the releases we have in a certain deployment in production, and the releases we would “ideally” have, according to some criteria (for example, “the most recent available release”, “the most stable release”, “the release with the least security bugs still open”). The presentation will introduce the notion of technical lag, and how we have applied it to study technical lag in some specific cases.