Should You Move Exchange to Microsoft 365 or Azure?
When an organization using Microsoft Exchange chooses to move to the cloud, one main benefit they get is that there is no more need for the on-premises infrastructure they’ve been using.
Azure vs Microsoft 365
A natural choice for them is to move to Microsoft 365 (formerly Office 365) which is a hosted public cloud by Microsoft for Exchange and related applications. This option brings many other benefits of moving to the cloud through the Microsoft 365 ‘Control Panel’, a set of tools including excellent GUI dashboards for self-serve by individual users.
The other option which is less considered is to move to Microsoft Azure in a Private Cloud setting instead of Microsoft 365 public cloud.
This blog mentions the viability of this approach of moving to Azure in a private cloud and highlights the many benefits an organization achieves by staying in the private cloud. It also mentions that any shortcomings or cons of this approach can be mitigated by adding a ‘Microsoft Exchange Control Panel software.
Data Ownership: Private vs Public
Before migration to the cloud, organizations have their Microsoft Exchange and other applications running on servers deployed on-premises or in the organization’s own data center space. The administrators would have root-level access to all machines and would use the necessary means to protect their data.
Azure is a Private Cloud
If the applications are moved to Azure (or to other cloud provider’s infrastructure e.g. AWS, Google Cloud Platform, Oracle Cloud, IBM Cloud, Alibaba Cloud etc.), the organization still has root-level access to all the (virtual) machines that their applications are running on.
These are single-tenant deployments where the organization chooses its topology entirely for itself. Their apps and data are as protected here as they were in their previous on-premises applications.
Microsoft (Office) 365 is a Public Cloud
When on-premises Exchange and other apps are migrated to Microsoft 365, that is a public cloud. It is run on shared infrastructure where the organization has no visibility of the machines it is running on. They do not have root access or any other access to those machines.
In addition, the deployments are multi-tenant with many organizations sharing the same instances of applications on shared servers under the hoods of Microsoft 365.
While data in the hands of Microsoft is generally considered safe, for many regulatory and compliance purposes, the two deployments are entirely different.
Costing: Server-based License vs User-based Subscriptions
For all existing deployments, the applications are already licensed through Microsoft using their existing server-based perpetual licenses. For a comparison see https://blog.hostingcontroller.com/2022/09/cost-comparison-microsoft-exchange-vs.html
Costing in Azure
While moving to Azure from on-prem, nothing changes in terms of licensing. Existing server-based perpetual licenses are deactivated on-premises and reactivated in the Azure machines. If an organization is going fresh, it will still get server-based perpetual licenses from Microsoft.
Costing in Microsoft 365
Server-based perpetual licenses need to be changed to user-based monthly or annual subscriptions. A one-to-one comparison is difficult as Microsoft offers bundles of different apps against subscriptions but the nature of license change remains a cost to consider.
Identity Data: Active Directory vs Azure AD
When moving to Azure, organizations are able to create an exclusive single-tenant instance of Microsoft Active Directory in the cloud. They can choose to have the same version and settings. They can establish trust between their existing on-premises AD and the cloud-hosted ADs for master-slave or master-master data replication and so on.
On the contrary, moving to Microsoft 365 requires moving identity to Azure AD. Although Microsoft has designed it to be a close look-alike for Microsoft Active Directory, it is not the same and differences emerge.
Deployment Configurations: Self vs Microsoft Chosen
There are many settings regarding deployment configurations like the number of databases, the topology of DAG(Database Availability Groups), and others. They have high availability, scalability, latency, security, and other requirements. They may have an impact on national, regional, or industry-based compliance requirements.
When moving to Azure, the customer chooses its deployment configuration and may choose one similar to the existing on-premises configuration. Microsoft 365 requires customers to follow Microsoft’s internal best practices with little to no choice or control.
Security and Encryptions Setting: Full vs Limited Control
Many customers use enhanced security and encryption settings for their data. When moving to Azure, since all deployments are single-tenant, customers can choose to keep the same settings as they had on-premises.
Regulatory Compliance: Organization Offered vs Microsoft Offered
For many national, regional or industry-based regulatory compliance reasons, customer organizations need to re-configure it on their own in the Azure cloud. While moving to Microsoft 365, customers need to rely on the details of compliance as offered by Microsoft.
Backup and Restore Options: Existing Tools vs Microsoft Tools
Customer organizations can continue to back up (and restore) data using existing tools, formats and policies as their existing on-premises tools. Since Microsoft 365 keeps data in shared multi-tenant settings, it only allows an ‘export’ of data and not the full backup/recovery as the organizations are used to doing.
Disaster Recovery Options: Full Choice vs Microsoft Choices
When it comes to DR, organizations’ may have complex needs. Since data is fully in the hands of the organizations and is held in single-tenant repositories, it can be copied or exported anywhere as per the organizations’ choosing. With Microsoft 365, organizations need to take one of the choices offered by Microsoft.
Integrations: Re-Configure vs Redo
Microsoft Exchange and its related enterprise applications usually have many third-party integrations already done. Moving to Azure, the integrations only have to be ‘reconfigured’ (e.g. changing IP Addresses). While moving to Microsoft 365, those integrations have to be redone. Many third-party vendors now support Microsoft 365 out of the box, but some don’t. Even if they do, it is usually more than a reconfiguration and the integration with Microsoft 365 needs to be redone engaging developers.
Azure With a Third Party Control Panel
Many customers choose to go to Microsoft 365 because of the ‘control panel’ which is developed by Microsoft and is available to all Microsoft 365 customers. This control panel is much more evolved than the PowerShell interfaces otherwise available to control the underlying applications. It provides multi-tenant self-serve GUI dashboards among others.
Hosting Controller (HostingController.com) provides a similar ‘Control Panel’ software for Exchange and related Microsoft enterprise applications like SharePoint, Skype for Business, Active Directory, Hyper-V, RDS and others. Together the end-user experience is comparable to Microsoft 365 public cloud in some aspects and far superior in others.
Hosting Controller installs on a separate Windows server and connects to Exchange and all other applications through their native scripting interfaces. On Azure, it can be deployed on a single Windows server. Among the many benefits it offers:
- An excellent GUI with self-serve security
- A comprehensive REST-based API
- Private-Cloud Cost Control Measures
- Audit-Trails of all changes
- Many more features
See website for more details.
Cloud Deployment Configurations
With Hosting Controller, organizations can also choose different cloud deployment configurations to better meet their organizational needs. Some different configurations are mentioned here.
Hybrid-Cloud Configuration
Hosting Controller control panel can also run on-premises with existing deployments. It could be a fully self-contained deployment for organizations that choose to stay on-premises. Alternately, instead of moving all of their infrastructure to the cloud, they can choose to move some of it to a private cloud and keep some on-premises: https://hostingcontroller.com/enterprise/Hybrid-Cloud-Controller.html
Hybrid Multi-Cloud Configurations
In this configuration, some of the apps (e.g. Exchange, SharePoint and AD) are running while other apps (e.g. Teams) are running from Microsoft 365 public cloud.
Alternately, with the same Active Directory organizational unit, some users may be running on-premises while others are running from Microsoft 365: https://hostingcontroller.com/enterprise/Multi-Cloud-Control-Panel.html
Hosted Multi-Cloud Configurations
This is similar to hybrid multi-cloud above except that in this configuration, some apps or users are running in a hosted private cloud like in Azure while others are running through Microsoft 365. Hosting controller provides full support for such configuration.
Details of such deployments can be found at https://hostingcontroller.com/Microsoft-Office-365/Hybrid-365-Control-Panel.html
About Hosting Controller
Hosting Controller is a control Panel software that supports many higher-level applications. For every application that it supports, it offers a public-cloud version with all the features mentioned above. It may also be used by organizations to manage application instances hosted in private clouds offered by cloud providers. More can be seen on the website at http://HostingController.com
To stay in the know with Hybrid Cloud Technologies, follow us on Twitter, LinkedIn, Facebook, subscribe to our YouTube Channel or talk to our Microsoft Enterprise application experts today to discuss your unique needs.
Originally published at https://bog.hostingcontroller.com on September 15, 2022.
Post a Comment