Moving from EA to MCA: what you should know

Moving from EA to MCA: what you should know

There was a new contractual model introduced recently for Azure enterprise customers, called MCA (or MCA-E). Some of the companies, previously using Enterprise Agreement (or EA) are going to transition(or already transitioned) to it.

This article focuses on the above mentioned scenario: EA to MCA transition process. It provides additional recommendations and lessons learnt from use cases in the field (author experience) that are not mentioned in official guidance here Set up billing for Microsoft Customer Agreement - Azure - Microsoft Cost Management | Microsoft Learn.

This article represents the individual author's view on the subject, not related/issued by author's employer and not considered as an official documentation of the author's employer.

The support on the actual process can be requested via contact to Microsoft account team.

MCA in short

MCA model introduces some changes, in particular in hierarchical, logical and billing structures. The easiest way to understand the hierarchical and logical changes is to check and memorize the image below. Understanding this diagram, new roles and updated billing model will already help you to cover 60% of "must-knows".


Figure 1: General view on changes after transition from EA to MCA

MCA changes (compared to EA)

As diagram above shows, these are the changes when transitioning from EA to MCA

  • EA becomes Billing Profile
  • Department becomes Invoice Section
  • Account Owner becomes Subscription Creator

If you had no departments before transition, there will be a default invoice section created. Having a single invoice section will result in an invoice without any groupings.

You can always easily add, change or removed unnecessary parts even if you didn't do it before transition. You also can move subscriptions left and right under another or new Invoice section, create/remove new invoice sections. Be careful however with updates on Billing profile level as it is your transitioned EA. Make sure that you don't remove any child entities and educate the owners accordingly.

MCA benefits

One of the top benefits of MCA from my point of view is the ability to have multiple invoices with sections, and individual payment methods - unlike the single EA invoice, where internal rebilling was responsibility of the customer.

Figure 2: MCA hierarchy


Billing accounts, profiles and invoice sections

When customer signs MCA, he gets a Billing account created, which represents agreement with Microsoft. So MCA adds a layer on top of Billing profile (previously known as EA as shown on picture). That gives a possibility to combine multiple agreements represented as Billing profiles and subsequentially multiple invoices per profile and option to choose a certain payment method. Each Billing profile will have one invoice that can have multiple invoice sections to simplify cost calculation per department and rebilling routine


Figure 3: Example of invoice with 2 Invoice sections

Single Invoice section vs multiple Invoice sections

You can have only one Invoice section under Billing profile, but from my point of view you will loose some of the benefits of MCA (when it comes to mapping cost per Invoice section, previously known as Department). The invoice will look similar to what you had in EA, without grouping costs in sections, so if any insights is needed to map the cost per workload, department or any other logical entity --> having only one Invoice section is not the best choice. You will have same effort to calculate it yourself as it used to be in EA prior transition.

Conclusion - if you want a view on the cost per team, department, branch, etc.. according to their actual Azure usage, you should create multiple invoice sections per each logical entity that you want to consider as separate in terms of cost.

Example

Let's say you have 2 teams in your company, one has a heavy workload selling tickets for public transport on country level and another one a light application used by HR to record vacation requests. It may be the case that you will want to split total monthly cost between these teams fairly based on what they have actually used. In this case it would be a good idea to create 2 invoice sections, Ticketing and HR, and make sure they have their workloads in subscriptions that are under corresponding Invoice Section (as subscription can only belong to one section). Then you will receive an invoice as on Figure 3 where costs will be summarized in separate sections according to Azure subscriptions and resources under it.

Well, it may happen that you have these workloads in one subscription. In that case you can move one of these 2 workload resources to separate subscription (guidance available here Move resources to a new subscription or resource group - Azure Resource Manager | Microsoft Learn ) and then assign that subscription under its own invoice section.

Multiple Billing profiles vs single Billing profile

With larger companies operating on global level with branches in different countries or with affiliates and with multiple EAs, multiple Billing profiles will be created after transition (one profile per EA). Sometimes customers have only one EA before transition, meaning that they will also have only one Billing profile. But if they include affiliate or partner (which previously was done via CSP/Azure Plan model and with quite complex non-transparent structure), it will be added under their Billing account as new separate Billing Profile. Also in this case affiliates do not need a separate contract, tenant(identity layer known previously as Azure Active Directory and nowadays as Entra). It means contractual effort is reduced to minimum, unlike effort required for every new party involved in EA era ( as every affiliate required its own agreement, tenant).

MCA and single tenant

I mention tenant effort here, as having one tenant is considered best practice by Microsoft. It means that we reduce attack surface, by keeping it simple and secure (KISS principle reference from my fellow identity colleague). Operating with multiple tenants creates additional complexity and cost, not to mention technical migration required if you ever decide to consolidate them. Experience shows that allowing multiple tenants in organization leads to raising uncontrollable number of tenants, as every creator of subscription assumes it as a standard allowed option. Once subscription is created, it is linked to one and only tenant creator sets. It is permanent unless you migrate resources to another tenant.


MCA new roles & action required

New role names in MCA will require you to change your automation, pipelines, etc anywhere where you use the EA roles (non-existing after transition). Typically, changes are needed in your cost reports or subscription automation scenarios. But it is recommended to think broader on the impact possible after that change.

Roles are documented in this document Billing roles for Microsoft Customer Agreements - Azure - Microsoft Cost Management | Microsoft Learn (if you relied on EA roles --> you need to use new ones accordingly)


Before transitioning

Make sure you familiarized yourself with official document here Set up billing for Microsoft Customer Agreement - Azure - Microsoft Cost Management | Microsoft Learn.

  • The person who signs MCA will become billing account owner and he/she will be required to perform few steps and kickstart the transition.
  • You have to check if your current marketplace offers support transition ( i.e. private plans, availability in target MCA, etc.. ) For this you will need to contact publisher and inform him about upcoming migration. They will then need to preform some actions to make that service available and transferrable to MCA. If not done, transition of this resource and its subscription will fail.
  • You should also check with Microsoft account team on commitment transfer details (reservation and savings plan). Make sure your have acknowledged the fact that if reservations or savings plan need to be cancelled and repurchased (happens during transition process), new end term will be added (like if it was new purchase on the date of transfer)
  • If any resource fails to be migrated during the process, then entire subscription that hosts it remains in EA until it is fixed. In that case you will need to start transition once again. That includes subscriptions with reservations or savings plans that were not transferred successfully due to some blockers. It also means you pay full price for resources transferred to MCA that should have been covered by these commitments until transition to MCA is successful. That's why it is recommended to pre-check these details with Microsoft account team upfront.



Transition itself ( not covered in this document as it is explained extensively here https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/mca-setup-account#start-migration-and-get-permission-needed-to-complete-setup)

After transition

  • Check if everything was migrated on Azure portal. You can do that either on the transition status page or manually navigating to EA and validating no subscriptions are left over there.
  • Add/change roles and members assignments when needed.
  • Verify applicability of any conditions existed in EA
  • Verify your cost reports and automation
  • Verify hierarchy of MCA, change or add new components like invoice sections
  • Use principle of least privilege and avoid assigning billing profile and account roles. Remember best practices of at max 5 Billing profile owners( EA admins) and on break glass account. Remove redundant admins during or after transition and perform access reviews.
  • If not needed, disable auto renewal of commitment offerings ( reservations and savings plans ). At scale --> by Azure policy
  • Check Azure Cost Management section, it is expected that some of your users may loose access to previous EA view. Make sure you export costs in EA just before transitioning to get latest backup.
  • Understand new APIs of MCA described here Migrate EA to Microsoft Customer Agreement APIs - Azure - Microsoft Cost Management | Microsoft Learn
  • Azure calculator prices of your company will only be shown to billing profile level roles. It means your lower level users with only see Azure list price even after logging in on calculator page with company email. Do not rush into granting them billing profile roles as it will have big consequences such as them becoming admins and being able to monitor and play with all resources under Billing profile which is not the purpose. If this is really needed, create a dummy empty Billing profile and assign users Billing profile role ONLY THERE. Like this they will be able to see actual pricing in calculator, but since they are attached to dummy profile --> they will not see any resources or have an option to manage them, The real resources are actually residing in another billing profile where they are not having any role entitlement as admins.

Tina Jennings

Impactful insights for the Digital Transformation journey

6 天前

This is really good! Thank you!!

回复
Manoj Nair

Senior Cloud Solution Architect Manager-Azure, Microsoft NV, Belgium

2 个月

Thanks for sharing!!! Am sure it will be useful for organizations embarking on this change.

要查看或添加评论,请登录

Dina Fatkulbayanova的更多文章

社区洞察

其他会员也浏览了