dkimani Thanks for replying. I don't think you've really addressed my point about backwards compatibility - this will be a rare occasion when Microsoft completely breaks an automation process which was previously offered to system administrators to administer a system, breaking many scripts. I can't remember the last time you did this.
'As part of the parity work, we are looking at both the MSOL (MSOnline) and Azure AD libraries of Azure AD cmdlets and mapping the functionality onto the MS Graph PowerShell SDK, to make sure that all scenarios are available. We have started working on a cmdlet map for MSOL vs Microsoft Graph PowerShell, and Azure AD Graph PowerShell vs Microsoft Graph PowerShell, as part of the migration documentation.'
Again, if Microsoft was following the route that it has followed in the past, and which happy and repeat customers have come to expect, you would be using that information to update MSOL and Azure AD libraries to keep them working with MS Graph in the background.
'Microsoft Graph cmdlets are autogenerated from the Microsoft Graph API schema. The process has many advantages, for example, providing a rich set of cmdlets that cover the whole API landscape. The disadvantage is that the resultant cmdlets may not be as user friendly, when compared to human authored cmdlets. Consequently, we are actively working on usability improvements of MS PS SDK cmdlets docs and examples and more tools on migration.'
This just shows that you've lost sight of the 80/20 rule. What you had before made it easy to use the 20% of functionality that 80% of PowerShell users actually need - and what you're doing now will make life harder for those 80% of people - your 'gain' being complete API coverage for the 20% minority who need the remaining functionality. Come on guys. PowerShell is a sysadmin tool first and foremost, and most sysadmins only need to use a tiny subset of MS Graph functionality (managing users, groups, licenses, MFA) which is already covered by relatively easy-to-use MSOL and AzureAD modules. You should be maintaining those modules, and only expecting the minority who need the full functionality of MS Graph to use the new cmdlets - which in your own words are 'rich' but 'not as user friendly'. Extra hint - most of that minority will be developers, who don't access Graph via PowerShell anyway. This is basic stuff.