We and also other MS Partners and even MSFT folks using demos.microsoft.com are suffering in the "every few month" create a new tenant issue. Every few months we create a new tenant and as we show O365 AND EMS we deploy it fully with Azure. This results now in dozens of MODxxxxxx zombie directory piling up in the Azure Portal over time. Sofar I created a script to clean up the most to delete them but:
1. Neither Enterprise Apps added "by users" like Box and Salesforce are removable via Powershell!
2. Nor you could delete afterwards the whole azure AD tenant to get rid of that stuff. Neither by GUI nor by Powershell. This is as there is always in the background a still connected subscription. Which only can be deleted by the support.

Imagine now just in my own case I have to open currently around 6 tickets to remove them and every body else also need to open a ticket to get rid of demos.microsoft.com tenants. This is really expensive for the PG. So please add there a feature for the MOD tenants to be deleted easily. May be you connect it with the "Delete" button in the demos.microsoft.com console. Thank you very much!

Let's face it. You've built the new portal architecture so that you can scale to ∞ services and you've done this by leveraging LESS, TypeScript and Knockout. You've also sandboxed the extensions development so that a single extension cannot go on and destroy the whole experience.

A lot of people already have requested you to open source the portal design. Also, you have clients using the portal who aren't satisfied because they can't quickly find what they're looking for or having all their key information they're looking for simply cannot be put in the same view.

So I urge you to consider the following steps.

Step 1, UI

1. Extract LESS, Markup and TypeScript out from the Azure Portal project
2. Open source it as a style guide in Github much like Bootstrap
3. Let the community report you issues and help fixing them

Stage 2, Extensions
1. Add option to the Windows Azure Pack to use the new portal design (still uses the old one)
2. Add ability to build your own custom extensions to the Windows Azure Pack Admin & Tenant
3. Open Source the Windows Azure Pack extension SDK in Github

Stage 3, Middleware
1. Build a minimal proof-of-concept application for the extension architecture with ASP.NET Core
2. Integrate the UI into the Application
3. Open source it

Stage 4, Azure Portal
1. Study what you learned from all of this and bring it all together
2. See what the community has come up with
3. Open Extensions marketplace for the real Azure Portal much like what you're doing in here: https://www.siteextensions.net/

Stage 5, Monetize

You have loads and loads of clients and you can't possibly satisfy everyone's needs in the world. Let people help you by being able to publish extensions through the Azure Marketplace. For free or for fee. Add integration points to Flow and Office 365.

And you are not the only one who's having the problem with multiple teams all pushing changes to the same multi tenant product. Showing a direction with your own ASP.NET Core technology on how to systematically work on a multi-tenant product which by design of architecture is a perfect fit for microservices architecture can only work as a motivation for new startups to adopt ASP.NET Core and Service Fabric. Now that the initial investment for proper architecture isn't such a monumental effort.

So please.