When we launched the Resource Manager model last year, we introduced a multitude of benefits such as Role Based Access Control (RBAC), single-click deployment for complex applications using templates, per-resource tagging for chargebacks, new resource manager deployment policies (including service curation), and more. Relative to its predecessor, the Azure Service Management (ASM) model, the Resource Manager model made a giant leap in providing new functionality. From creating and sharing templates to managing dependencies across application resources to grouping resources for tagging, we have seen Resource Manager catalyze a growing community of interesting templates and solutions found on GitHub for developing, deploying and managing  applications. In fact, the recently released Azure Stack is based on the Resource Manager model and extends this ecosystem to on-premises environments as well.

As you transition to using the Resource Manager model, a key priority for us is to ensure all of the Azure services support the Resource Manager model. To that end, we migrated the majority of Azure services to support this new model (refer to full list). For most of the remaining services that don’t yet support this model, we’re planning to add support within the next few months.

As you’re thinking of building new applications in Azure or starting new projects, we strongly encourage you to use the Resource group model. However, if some of the services that you will be using don’t yet support the Resource Manager model, or if you’re simply adding resources to existing projects using the ASM model, we’d suggest you continue using the ASM model. Although new features and capabilities will be prioritized to be offered only via the Resource Manager model, we have no plans to deprecate the ASM model.

Even as you plan new deployments using the Resource Manager model, you may still have existing deployments that were created in the ASM model. In such cases, you may need to manage services or connect virtual network environments (VNets) created using the different models. Today, you can connect two Azure VNets created under the two models, as well as connect to them from on-premises using a VPN (as shown below).

If you are using ExpressRoute though, circuits created in the ASM model can only be used with VNets in ASM model, and circuits created in the Resource Manager model can only be used with VNets created in Resource Manager model. We understand it can be cumbersome and expensive to have two ExpressRoute circuits to connect to different environments and are working to address this by 2016 Q2 at which time you will be able to use just one ExpressRoute circuit to connect to both environments.

Helping you simultaneously manage and connect to both environments is an imperative for us, while you plan migration of ASM environments to the Resource Manager model.

Speaking of migration, we recently published some scripts to help you migrate Virtual Machines from ASM to the Resource Manger model. We are also working on a few more solutions that will help reduce the VM reboots and network downtime when migrating. The following table gives the expected timeframes when we hope to make these solutions available.

We know transitioning to the new Resource Manager model poses challenges if you have a number of deployments already in the ASM model, but are confident that you will enjoy the benefits of the new model. In the meantime, we’ll continue to do everything we can to help you migrate and connect your environments.