>YMMV, but this approach is what causes software projects to balloon way beyond initial time requirements, and to be way out of date already when eventually released.
This is why you need to determine what your MVP is and ship when the MVP is done, rigorously. In this case, either they chose the wrong MVP, or they shipped before reaching it. Thus the current situation is a result of indecision, not agile methods. Agile is not an excuse to ship half-baked software.
Here's how I would have managed this project, for what it's worth: if we determined that migrating fully in the allotted cycles was infeasible, I would have moved all of the settings we didn't have time to migrate from the Control Panel into a command-line tool or registry keys, gotten rid of Control Panel when I shipped Settings, and then incrementally added the ones we missed back into the new view. What infuriates me most about Windows are compromises like this, which are plainly a result of prioritizing existing user workflows over creating a consistent user experience.