An MSP Go-to-Market Strategy for Azure Lighthouse

If you are a Managed Service Provider (MSP), I hope you are excited about what Azure Lighthouse can do for your business. And if not, you should be. Not only can you reach more customers, but your operations can be simplified through the centralized view that Azure Delegated Resource Management (ADRM) gives you across all your tenants. 

Microsoft does not even charge a fee to MSPs for using Azure Lighthouse and selling their Managed Services, so the revenue is yours to keep! This is the fourth blog in the series, which will help you define your go-to-market (GTM) strategy for your services using Azure Marketplace, Azure Resource Manager (ARM) templates, or Managed Apps. 

But first, make sure that you check out the earlier posts about the Azure Lighthouse solution, its foundational technologies using ADRM and AAD, and Azure integration. That last blog post describes all the Azure Services that integrate with Azure Lighthouse to help you maximize your customer base and revenue.

Managed Services in the Azure Marketplace

The Azure Marketplace is an incredible resource for anyone who builds or buys cloud software that runs on Azure.  It aggregates every product that third parties can offer to Azure users, like an app store for the Microsoft cloud.  Now, MSPs can offer their services to clients through the Azure Marketplace, opening up their business to millions of new customers around the world. Managed Services are a new type of offering that rely on Azure Lighthouse, ADRM, and Azure Active Directory (AAD), and allows customers to easily purchase and onboard an MSP. 

While Consulting Services are not new to the Azure Marketplace, they have a broad scope and usually a fixed price.  Managed Services are different in that they are an ongoing engagement and use ADRM.

A Managed Service can be either public or private. Public ones are published in the Azure Marketplace and available to all users. At this time, there is no way to limit the consumer by their geography or Azure region, although this will likely be added in the future. 

The way to restrict who can access a plan is by configuring it private. MSPs can then provide a preapproved list (a “whitelist”) of subscription IDs that can access this service. Public plans are recommended for service providers trying to expand their business and find new customers without paying any additional customer acquisition costs. 

However, new customers may be hesitant to grant an unknown service provider broad access to their infrastructure. It can be best to keep the public offering fairly simple but have extended private offerings that you can upsell to these new tenants as you build trust with them. Also, consider offering them important services they may not have realized they could request, such as the Azure Health Service.

Another option is to have a hybrid offering, which allows you to include both private and public plans within the same offer. This gives you the broadest solution, allowing you to discover new customers and upsell them on additional services as you develop a relationship. You should also be aware that once you publish a public plan, you cannot change it to a private plan; you would need to remove it entirely if you want to republish it with any restrictions. Part of the publishing process requires you to provide a title, description, and other searchable terms.  

We’ll provide some best practices for app store optimization (ASO) in a future post, so be sure to keep an eye out for that!

Once a customer has purchased a Managed Service through the Azure Marketplace, they go through an onboarding process. This allows them to identify which subscriptions and resource groups can be managed by the MSP to perform their service. A manifest defined by the service provider will detail which Azure AD services, users, and groups will need access to the customer’s groups, which the tenant can accept, change, or decline. Once these permissions are assigned, the onboarding is complete, and Azure Delegated Resource Management (ADRM) will grant the MSP access to the approved tenant resources.

Azure Lighthouse with ARM Templates

If you are setting up services for a tenant without going through the Azure Marketplace, then you will use Azure Resource Manager (ARM) templates. An ARM template is a JSON file that defines the exact configuration of an Azure group, including all of its resources, settings, dependencies, and permissions. This is essentially a blueprint that is used to streamline deployment and guarantee consistency instead of repeating a series of manual configuration steps. The ARM template can be configured via the GUI-based Azure Portal, Visual Studio, Visual Studio Code or IntelliJ IDEA.

ARM templates are used with Azure Lighthouse as they allow an MSP to deploy a service for a tenant. This can be a fresh deployment for a new tenant or adding additional services to an existing tenant, such as after an upsell opportunity from the Azure Marketplace. Since the template will be created by the MSP, they can guarantee consistency across all of the tenants. This not only simplifies deployment, but also ongoing management and operations. For example, when the service provider needs to make a configuration change, they can do that programmatically across all their tenants. These ARM templates should be considered as valuable intellectual property for the service provider, as they take considerable time to craft and perfect. One advantage of using Azure Lighthouse and ADRM is that these templates remain in the service providers’ infrastructure, so by not exposing them directly to their tenants, they can retain and protect their IP.

Azure Lighthouse with Managed Applications (Apps) and ISVs

These Managed Services offered through Azure Lighthouse are not restricted to just service providers, but ISVs can publish these alongside their software, known as Azure Managed Applications (Apps). Azure Marketplace lets a developer sell their software and upsell the deployment and management services for it. When a customer purchases the software, they will deploy it into a resource group with ADRM access provided to that publisher. 

The ISV can perform ongoing maintenance, troubleshooting, and operational tasks for their customers. Azure Lighthouse has made this easier for ISVs or any MSP with expertise in managing a specific app. Again, we’ll discuss this topic in more detail in an upcoming blog post.

Azure Lighthouse with APIs, Scripts & GitHub

Microsoft invested significant effort in making the Azure Lighthouse management experience consistent between the Azure Portal GUI and its APIs. While service providers new to Azure may start with the Azure Portal, learning Azure PowerShell or Azure CLI is essential to provide automated management for their tenants at scale. When using Azure Lighthouse, scripting your operational tasks becomes necessary so that you can save each step into an ARM template to ensure that it is run the same every time. Fortunately, Microsoft has provided numerous code samples for ARM templates and a GitHub repository for Azure Lighthouse to get you started.

Final Go-To-Market Strategies

To summarize, you should publish your Managed Services with low-touch offerings through the Azure Marketplace to find new customers. As you build trust, offer tenants value-added services that you can deploy through private offerings or your portfolio of ARM templates. Consider targeting specific (regulated) industries or verticals to build expertise in these areas and differentiate yourself. As a service provider, you are likely also part of the Microsoft Partner Network (MPN). When you first sign up or during your annual renewal, you must provide some customer references. 

With Azure Lighthouse, you can simplify this step by associating your MPN ID with the tenant subscriptions you manage. The revenue you create through managing these customers is credited to your organization. If you publish an offer through the Azure Marketplace, this happens automatically. If you are onboarding a customer independently using an ARM template, you can still manually associate their ID so you are given credit. Remember that Microsoft does not take a cut of the revenue generated from these Managed Services, which will encourage broader Azure Lighthouse adoption.

Thanks for reading!