Microsoft Azure

Azure migration design considerations

Running an Azure Proof of Concept (Azure PoC) can entail many services and parameters which should taken into account. More considerations are added if there is a migration involved in the PoC project. In this case, the Azure PoC subscription is used as an intermediary platform on which to perform an initial migration, test the proof of concept and validate functionality and then switch-over to production. There are various Azure migration design considerations which need to be taken into account. This article lists some high-level Azure migration design considerations.

The following steps should be considered when carrying out an Azure migration:

  1. Perform business and technical assessment of the current production environment. This is a complex auditing process and should be adapted to cover all services, apps and data in-scope for the migration. An Azure migration assessment template can be used, which will include all required assessment parameters (for example areas such as on-premise, cloud, authentication, datastores, security and performance). As a result of the assessment, a mapping of current services into Azure services will take place.
  2. Design Azure target environment for the migration. This includes design of Azure tenant and Azure AD licensing/features, management groups, subscriptions, resource groups, tags and policies. In large Azure environments, consider using Azure landing zones and Azure Blueprints. This, besides other things, will ensure that your target environment is built as per Microsoft best practices and will comply with Azure Well-Architected Framework (WAF) and Azure Cloud Adoption Framework (CAF). The Azure design should cover in detail all functional and non-functional aspects of the systems involved, including the Business Continuity and Disaster Recovery (BCDR), performance levels and security configuration of each Azure service involved. Additional specific design considerations should be made for each service, based on each service specific requirements (for example design considerations for Azure App Service, Azure database for MySQL, etc).
  3. Migrate a representative subset of resources from production to an intermediary Azure PoC environment. You can request an Azure PoC environment from Microsoft by submitting a request via your Tier-1 Microsoft CSP distributor or by other channels available by Microsoft. If your request is approved, you will have an Azure Pass offer with a PoC subscription to utilize for your preliminary migration tests. Otherwise you will have to work with a free Azure trial subscription for that purpose. When the PoC environment is fully configured, create functional tests, BCDR tests and performance/stress tests, coordinating systems engineers with software engineers in preparing and executing test scripts.
  4. Configure all security-related parameters in a security lock-down fashion and re-run all functional tests to verify your security config does not break any functionality. Also run security/penetration tests and security evaluation tests using services such as SSLLabs and Securityheaders.
  5. When all functional tests are completed in the PoC, you should move your Azure PoC subscription resources to your final Azure production subscription (for example Azure Enterprise Agreement or Azure CSP subscription). Alternatively, you can re-deploy all PoC resources from scratch in the target Azure subscription, by using ARM templates or Azure BiCep. Take into account that there are certain limitations when moving resources from one subscription to another. Functional and non-functional testing should be carried out again in the final target subscription.
  6. Plan for a cut-off migration of your apps and data from the current production environment to the target Azure environment. Plan for an end user/customer communication plan and required downtime, as well as a fail-back plan in case something does not work as expected. A common fail-back plan is to revert the customer-facing DNS FQDN to point to the old production infrastructure. For this reason it is important to always set the TTL parameter of all involved DNS records to the lowest possible value.

About The Author