This post is provided by Senior App Dev Manager, Bryan Towne to provide insight into to consolidation options for Azure deployments as you grow into or out of your current Enterprise Agreement.

Within the time that you consume Azure services there will come a point in which you will probably need to transition from your Enterprise Agreement (EA) and start using for a new one. One of the reasons is that Microsoft has been adopting a new type of agreement for to handle Azure consumption called the “Server and Cloud Enrollment” (SCE). Other ways that an EA change will be necessary is through attrition – either through a merge, acquisition, divestiture or simply your organization may have spun up too may desperate subscriptions for POCs. Maybe too much work has been put into those POCs using benefits from MSDN, Microsoft sales, or from “Pay as you go” (PAYG) subscriptions that you do not want to redo the deployment again under a new agreement. Also, if you are under deadlines because of a hardware refresh or need to exit a datacenter so as a result spun up subscriptions not tied to a EA was the course of action needed and now an EA consolidation is unavoidable.

At some point, your Azure deployments may hit a critical mass under too many independent subscriptions from which there is not any efficient governance on billing, management or security. Maybe your organization will vet out that Azure is the cloud service which will be the avenue your company chooses. And with that, it may be make more financial sense to have a consumption based SCE which will reduce the overall cost and increase benefits. Maybe teams under the same division will want to share the same management of resources or provide an accurate billing compartment for approvals or charge-back models. Think of an EA transition or consolidation similar to processes completed in the past to any other tool needed to be transitioned to the enterprise level or deemed for companywide implementation. There are far more reasons why an EA consolidation will be necessary however the end game is the same.

This post will not cover a subscription move or merge, this is simply an EA to EA change. It is important to note that there is a huge difference between a move and merge. A merge will require that the identity and billing of those resource take on new ownership so not all resource types will move automatically as seen in this article:

https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-move-resources

A subscription move or merge will also need to redeploy any marketplace applications (not Azure services) you are using within that subscription because it’s a billing change.

Changing identity from a Microsoft account (i.e. myname@outlook.com, myname@hotmail.com) to a Work\School account (i.e. myname@contoso.com) also known as Corporate Identity or CorpID. There needs special care to be taken with an AD consolidation, so please proactively reach out to your ADM to assist with that transition. I would also suggest that you read this article which illustrates the difference between Active Directory on-premise and Azure Active Directory:

https://blogs.msdn.microsoft.com/plankytronixx/2014/05/09/the-differencerelationship-between-azure-active-directory-and-normal-active-directory/

For the EA change, you are in luck as it is just a billing change on the back end. To complete this transition to a new EA you must open Microsoft Support case. You can open a case right from within the Azure portal under Support. Again, please talk with your ADM before making any billing or identity transition to be sure that any risks are identified ahead of time.

Microsoft will need these 4 data points to complete the move:

• Source EA#
• Target EA#
• Preferred transfer date
• Approval from EA admin from Target EA#

Below is some information relating to EA transfer and account transfer. Both ways can move accounts/subscriptions from one enrollment to another.

1) EA Enrollment transfer – Typically done by request when a new agreement is negotiated or there is some consolidation of enrollments such as when one EA portal customer is acquired by another.  Enrollment transfers are automated only when the partner specifies in the order system that a transfer should take place and provides the source and destination enrollment numbers for date aligned agreements (for example source ending Dec 31, 2016 and destination starting Jan 1, 2017)

• What Happens: Moves all roles (Enterprise Admin, Department Admin, Account Owner and subscription level roles) and all subscriptions from source enrollment to destination enrollment.  The transfer can be set to any effective date that is within the contract period for the destination enrollment but only for periods that have not been invoiced for overage in the source enrollment. It leaves the source enrollment in a transferred status which is available only for historic usage reporting.  No roles or subscriptions can be added to an enrollment in transferred status.
• What happens to the Department hierarchies? (i.e. when we transfer EA enrollment 1 and EA Enrollment 2 into new EA Enrollment 3, do hierarchies move along with enrollment transfer as well or do all accounts from EA1 and EA2 will get transferred to new EA3 as unassigned?
• Department is not moved as there may be different department set up in new EA. We are not able to move existing department set up but customer can specific if they wish to move the accounts under a specific department on the new EA
• Transfer effective date: Let’s say if transfer is requested on 4/10/17 with effective date of 4/1/17. Does that mean all Azure usage in EA1 and EA2 during the period of 4/1/17 to 4/10/17 will be transferred over to new enrollment and invoiced to EA3 from the monetary commit of EA3?  Yes, usages will be moved accordingly.
• How: Done by EA Portal Support team through a support ticket created by the field or customer at http://aka.ms/AzureEntSupport
• Advantages: This type of transfer impacts back-end accounting only so nothing changes in the authentication model or any of the subscription-level roles. 
• Potential Problems: Please note Enrollment transfers do not move monetary commitment from source to destination enrollment.  Those amounts are contractually bound to the enrollment.  Future invoices may continue If an enrollment transfer occurs in the middle of an enrollment contract period it does not cancel future orders for monetary commitment without contractual action being taken to true-down the source enrollment.  For example, if I have a 3 year EA agreement with an annual monetary commitment (MC) of 50K and I transfer the enrollment in year 2 after my MC is consumed, I will still be invoiced at the start of year three for 50K which is essentially unusable in the now transferred status enrollment. 

2) Account Transfer from one EA enrollment to another – Typically done when a single customer has multiple enrollments that may be set up for different business units and the account owner or workload is moving from one to the other.  Occasionally done when an account owner moves from one company to another.

• What Happens: Moves only the Account Owner role and any subscriptions owned by the account owner from source enrollment to destination enrollment. 
• How: Done by EA Portal Support team through a support ticket created by the field or customer at http://aka.ms/AzureEntSupport
• Advantages: This type of transfer impacts back-end accounting only so nothing changes in the authentication model or any of the subscription-level roles.  This leaves the source enrollment intact, active and useable for new roles and subscriptions to be added.

Premier Support for Developers provides strategic technology guidance, critical support coverage, and a range of essential services to help teams optimize development lifecycles and improve software quality.  Contact your Application Development Manager (ADM) or email us to learn more about what we can do for you.