Predicting the time required to address an issue (i.e., a feature, bug fix or enhancement) has long been the goal of many software engineering researchers. However, after an issue has been addressed, it must be integrated into an official release for it to become visible to users. In theory, issues should be integrated into releases immediately after they are addressed. Yet in practice, the integration of an addressed issue might be delayed. For instance, an addressed issue might be delayed in order to assess the impact that it may have on the system as a whole. While one can often speculate, it is not always clear why some addressed issues are integrated immediately, while others are delayed. In this paper, we empirically study the delayed integration of 20,995 addressed issues from the ArgoUML, Eclipse, and Firefox projects. Our results indicate that: (i) despite being addressed well before the release date, the integration of 34% (ArgoUML) to 98% (Firefox) of addressed issues were delayed by one or more releases; (ii) using information derived from the addressed issues, we are able to accurately predict the release in which an addressed issue will be integrated, achieving an ROC area of above 0.72; and (iii) the workload of integrators is the most important factor in our integration delay models. Our results indicate that integration can introduce non-negligible delays that prevent addressed issues from being delivered to users. Thus, solely focusing on the time to address an issue is not enough to truly assess how long an issue will visibly survive in a software system.