The cloud can offer you benefits such as: decreased costs, increased security, and scalability to meet your business needs. However, migrating by yourself might not be so simple; many things can go awry if you don’t plan your migration accordingly. Thankfully, cloud migrations are our bread and butter so we can share a few tips to help your move to the cloud go smoothly.
Determine what you want to achieve with cloud migration. Are you looking for certain performance or to save costs? Understanding the goal is crucial for designing the target environment, or ‘cloud landing zone’.
You may want to consider a phased approach, which allows you to design, deploy, operate, and continuously optimize. ‘Lift and shift’ is just the first step. Once your workloads are migrated to the cloud, optimizations and enhancements are easier to implement and test. If you want to migrate your core workloads first and then add extra features, this is the approach for you.
Make sure you have a clear understanding of your application(s) and resources. There are methods to increase your understanding before you begin the shift.
For example, you can use assessment tools such as Azure Migrate to discover server workloads with dependencies, and Data Migration Assistant to discover MS SQL databases and run assessments for feature (Azure) compatibility. Azure’s App Service Migration Assistant can be used to evaluate running web applications for migration to PaaS App Services.
On-premises assessments will provide an idea on resource sizing, feature compatibility, and overall readiness for the lift and shift phase of migration. These must also be prepped for by deploying a virtual appliance, (VHD or OVA) on-premises, provide rights and open firewall ports to Azure tooling. By working with a partner like Intwo, we can help prep your environment for assessment.
Can your application be refactored or rearchitected into smaller services? Using cloud native features doesn’t have to be a large undertaking. For example, does your application utilize a file share or local drive storage? Can that application instead use object storage or Azure files? Splitting an application and utilizing cloud-native features will increase availability and resiliency, while decreasing management overhead. You can always start small to use cloud native features, there doesn’t have to be a major shift.
Every option comes with its own complex set of terms and conditions. If you don’t have time to read the fine print on every single one, working with experts who have committed the terms to memory will ensure that you’ve chosen the right SKUs for your application; choosing between Basic, Standard, or Premium SKUs will have an impact on performance, features, availability and costs.
For example, when selecting an Azure File Storage tier, Standard and Performance have very different performance levels, but also are charged differently. Standard SKU charges for how much storage you actually use along with storage transactions, whilst Premium SKU charges for the provisioned amount only.
Virtual machine SKU selection should be based on workload type, compute resources, and availability requirements. The Virtual Machine SLA from Azure depends on the SKU of the disk assigned – Standard HDD, Standard SSD, versus Premium SSD. Prices can vary largely between SKUs, so once again, make sure you choose the correct ones for your application.
Not all SKUs are available in all regions. Product availability and roadmap should be referenced as a part of your cloud design to confirm the SKUs you want to use are available in your migration timeline.
Be sure to test any backout procedures. Make sure everything is documented and have application teams and end-users ready for testing.
Having a solid backout plan is very important. If the migration process faces some obstacles, you should have a deadline set for backing out.
Moral of the story: make sure you are constantly testing! Always refer back to your rubric and expectations during the process.
How much data are you migrating? What is the bandwidth you are running to Azure? Running test migrations will give an idea of how long it will take.
You might also want to consider seeding your data for a quicker migration. Copy it all, and sync changes so there is less to copy during the cutover to Azure. You may need to use Azure Data Box for offline seeding. Big data migrations over the network can take weeks if not properly prepared for.
Making changes prior to and during a scheduled migration can have an impact on time required. For example, if an admin performs a data refresh before a scheduled migration, it could potentially add a large amount of data to copy, increasing the copy time. A change freeze to the environment is recommended to decrease amount of changes to be migrated.
Utilize automation and scripting for deployment and migration whenever possible. Automation helps to easily rebuild environments, increase consistency, and help with ongoing management.
Automation for Azure resources can be incorporated into your lifecycle management process to encourage continuous improvement and delivery.
ARM templates, PowerShell scripting and Azure DevOps are all aspects that are recommended for a successful Azure deployment.
Intwo has the deepest level of Microsoft Cloud experience available in the market today, delivered and supported by our global teams on a 24/7 basis, 365 days per year. This means a single global partner who delivers the leading global cloud experience for your business.
Creating and managing an Azure infrastructure requires an expert. Choosing SKUs, SLAs, and prepping your environment for migration is not a job for developers.
Security is one of the most crucial aspects when designing your cloud landing zone. Make sure you address all the security policies you already have in place and how these will transfer to your cloud environment. Azure provides secure underlying infrastructure and services, but they can only do so much; you must also be diligent in protecting what you put out there.
Be thorough when configuring new resources and verify settings before migrating any data to the cloud. For example, securing a Blob storage account can involve configuring: Private or Public access, Network access, Encryption at rest, Secure in transit, and Soft Delete.
Azure Policy and Azure Security Center should be used to enforce and alert on misconfigurations that put the environment at risk. For example, Azure Security Center provides recommendations for Virtual Machines to be associated to a Network Security Group to control network access.
You can deploy the required security solution that is complimentary to your existing enterprise security policies such as Identity Management, Multi-Factor Authentication, ACLs, Web Application Firewalls, Data Encryption, OS Patching, Anti-Malware, etc.
Use the dependencies that were captured in the assessment phase to help define the migration plan. For example, you may not want to migrate application server(s) to Azure while leaving their corresponding databases on-premises because this could lead to decreased performance and increased costs.
Some Azure resources have backup enabled by default – such as Azure SQL Databases, but does the default backup policy meet your frequency and retention requirements? Default backup settings should be reviewed.
Virtual Machines (VM, VMs), Storage Accounts, and App Services do not have backup enabled by default. VM backups can be easily configured using an Azure Recovery Services vault, but you need to remember to implement it.
Take your current backup requirements into consideration when assigning Backup Policies and storage type for data protection.
You will need to hire or train an infrastructure cloud specialist, or work with an expert partner to keep everything in order and managed correctly.
Cloud resources still require management. For example, Azure provides Virtual Machines and manages the underlying Infrastructure, but everything running within the VM Is still your responsibility: User management, Applications, OS patching, etc.
Overall management layer of the cloud environment needs to be considered in the design. Breakout of the number of subscriptions, resource groups, tagging, and administrator access management. Should management be broken out by Application? Environment (Production versus Testing)? A strategy should be defined at a high level to apply for all cloud resources.
Do you have other companies accessing your environment? How will they connect? Do they require Site-to-Site or Point-to-Site VPNs? If so, how will that be managed? What level of access do they require? Make sure that is also included in your initial design.
A major benefit of moving to the cloud is the ease of deployment and possibility for multiple, separate environments. Test environment(s) should be deployed and isolated from Production. All testing should be vetted in a non-production environment before rolling into production.
Multiple non-production environments and corresponding deployment process should be included in the initial design. Always make sure your environments match exactly to ensure like-for-like validation.
Software is imperfect, but Azure offers solid business continuity measures. Azure has a huge network of fail-safe conditions, but problems can still occur, and preparation is always key. Availability is outlined within each and every SLA, so nothing should ever be a mystery. Design your cloud landing zone for the availability you require.
To conclude, the most important step to a successful cloud migration is the planning and prep work. Make sure you have a solid outline, have read all the fine print and know what to expect.
Get help from our experts and make sure you don’t miss a thing from your initial lift and shift to everything that comes after.
Let's get in touch and tackle your business challenges together.
Rest assured. We've got you.
