Sure thing. The subtle difference (not well articulated by me, I suppose) is that in one case, you are given the go ahead to go and rewrite everything to confo

Sure thing. The subtle difference (not well articulated by me, I suppose) is that in one case, you are given the go ahead to go and rewrite everything to conform to, say, an interface spec or API or whatever. This year's implementation or architecture may be scrapped, but then you get a cleanish slate. In the latter case, what's happening is you are usually building an adapter over something that exists, instead of throwing it away completely. What then happens is that there is a lot of stress involved ("Is this wrapping correctly?", "Does this still do what it used to?", "Have my tests covered all the use cases?", "Wait, fuck, this original thing never even had tests...so aren't my tests are kind of pissing in the wind?", etc.) and then inevitably the push is to fix the fixes, and then fix the fixes' fixes, and so on. And sometimes that's unavoidable (maybe the legacy code is, oh I don't know, numerical simulation of a heat-exchanger in Fortan77 that was cutting edge and now the original author is quite dead and buried). But, the painful thing (as mentioned) is when the person in charge even admits that the whole thing will be rewritten anyways. In that case, why the fuck is the rewrite being put off? It signals a lack of faith in the development team, and a lack of prior planning to deal with downtime or other issues coming up.