The residue is not a rounding error. In most organisations that have run a cloud programme, what remains on premises is the set of systems with the least tolerance for downtime: the manufacturing line controller, the clinical system, the trading application, the thing with a licence tied to a physical socket. They stayed because moving them was hard, and hard usually means important.
What happens next is a slow withdrawal of attention. The talented people follow the interesting work, the refresh budget follows the strategy, and the estate gets one more year of support every year. Nothing fails immediately. What degrades is the margin for error: support contracts lapse to next-business-day on systems that need four hours, spare capacity gets consumed, and the person who knew the storage layout retires.
Backup is where this concentrates. Backup jobs report success, and reporting success is not the same as being able to restore. The gap between the two is only ever discovered at the worst moment, and it is usually not the backup that failed, it is that nobody had tested the restore path, the recovery documentation referenced a system that has changed, or the recovery point turned out to be twelve hours older than anyone believed.
Capacity planning stops being connected to the application roadmap. Storage gets bought when it runs out rather than when the roadmap said it would, which means it gets bought at list price under time pressure. Hardware lead times then turn a capacity problem into a project delay, and the lead time is discovered rather than planned for.
The economics deserve honesty in both directions. Some of this estate genuinely should move and has not, because nobody has done the arithmetic since the first migration. And some of it will be cheaper on premises for its entire remaining life, which is a legitimate answer that a supplier whose margin is in cloud services has no incentive to give.