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 of 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. 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 different Azure Services which integrate with Azure Lighthouse to help you to maximize your customer base and revenue.

Managed Services in the Azure Marketplace

For anyone that builds or buys cloud software that runs on Azure, the Azure Marketplace is an incredible resource.  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 which 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 the time of this writing, 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 to be private. MSPs can then provide a preapproved list (a “whitelist”) of subscription IDs than 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 with 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 not only sell their software but to 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 then 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 be talking about this topic in a bit more detail in an upcoming blog post

Azure Lighthouse with APIs, Scripts & GitHub

Microsoft invested significant effort in making the management experience for Azure Lighthouse consistent between the GUI in the Azure Portal and its APIs. While service providers who are new to Azure may start with the Azure Portal, it is important to learn Azure PowerShell or Azure CLI to be able to provide automated management for their tenants at scale. When using Azure Lighthouse, scripting your operational tasks becomes important 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 for them through private offerings or through your portfolio of ARM templates. Consider targeting specific (regulated) industries or verticals so that you can build up 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 will have to 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.

Thoughts, comments, or concerns? Let us know in the comments section below!

Thanks for reading!