Top 10 Lessons Learned from Azure Migrations

1. Assertively move toward a cloud operating model

The traditional information technology organization will need to shift toward a modern technology organization, with a focus on becoming a Governance and Center of Excellence (CoE) org vs. a delivery organization.  Draw a clear line between the modern organization and the legacy org.  Setup clear operating protocols for what the new org does and doesn’t do and drain the old org.  Individuals from the legacy org can move into new org roles in conjunction with training and commitment.  The new org is accountable for governance of the cloud and onboarding application teams.  The application teams become accountable for application operations.

2. Create a cloud migration ROI model

The migration to the cloud has the opportunity to provide agility and security benefit, while at the same time being cost neutral or better.  Leverage your cloud provider’s cloud migration assessment offerings, usually offered for free, to create the model.  A cloud assessment model needs to take into account optimization, reservations, and other benefits vs. just calculator rates.  The assessments also determine what can be reasonably moved vs. what is more challenging.  At this point companies are performing these assessments not to determine “if”, but instead to determine what the destination environment looks like for budgeting purposes.  Similar to the Office 365 migrations of a few years ago, most companies aren’t seriously considering continuing to operate their on-premise datacenters, at least those with CIOs who don’t want to go looking for a job.

3. Build an iterative plan that serves both marketplace disruption and datacenter modernization

The best migration plan is one that has a concrete start and end, with a clear ROI articulated, transition plan out of the existing datacenters, and transition plan for the staff.  Getting stuck in the middle is not productive for anyone.  Start with establishing a governance plan and landing zone, as well as a scaled implementation pattern for onboarding. 

1. Assess cloud estate for migration
2. Build cloud migration ROI picture
3. Deploy cloud governance and landing zone
4. Establish CoE for new applications
5. Establish migration factory (assess, time, migrate)
6. Onboard migrated platforms into new operating model

4. The cloud migration is the best chance to mitigate ransomware

The single biggest gap that allows ransomware to compromise environments easily is the contiguous nature of our networks.  This was shown again recently in the oil pipeline compromise.  The migration of workloads to the cloud allows organizations to implement consistent micro-network segmentation throughout the legacy environment by modernizing it in the cloud.  Migrated workloads are moved into separate subnets, each of which has its own virtual networks.

5. Have very rigorous cost management practices

The cloud environment can be an opportunity for significant cost savings or tremendous waste.  The difference between optimized environments using appropriate reservations and non-optimized environments is millions of dollars.  Your migration needs to take cost optimization into account as part of the migration, not as an afterthought.  Don’t let anyone tell you “it doesn’t make financial sense to move legacy workloads to the cloud”.  It does make sense and it pays off, but if you fail to optimize you’ll miss out on many of the savings.  It is also important to define clear roles and responsibilities associated with cost management as part of the operational state, facilitating the right people caring about the right things.  If the application groups are accountable and responsible for cost, you’ll have a much more operationally responsible spend level than if it’s an endless piggybank.

6. Use DevOps practices for cloud provisioning

The cloud environment is not a place to repeat the deployment practices of the past.  Avoid leveraging third party portals in front of the Azure environment and further, avoid portals for the most part in general.  The deployment approach for the cloud should leverage infrastructure-as-code, even for legacy platforms.  The skill jump may be significant for some, but the transition is necessary as it aligns with how modern workloads are built.  The biggest waste of money in the cloud is when people drop a third party product in front of Azure for portal-based provisioning, which were very popular at the advent of the cloud, but have since crashed in popularity.  Don’t make that mistake.  If you build it right now, you’ll modernize your team and avoid spending money on technical debt that will provide little value.

7. Build cloud-consistent security controls

The movement to a cloud demands cloud-consistent security controls built around Zero Trust.  Ensure that access to your administrative layer is governed via an identity layer with conditional access and serious controls.  The loss of physical controls (that you manage) is replaced with identity controls as the primary guard of the environment.  Implementing the security to prove the identity of the person and the health of the endpoint is important to operating a secure cloud ecosystem.

8. Shift application accountability to the business

The Cloud Center of Excellence is accountable for governance and onboarding.  The move to the cloud then shifts operational accountability, where possible, to the business application groups vs. the CCoE.  This is especially true for new workloads and modern applications built in cloud-native platforms such as containers and serverless.  The DevOps team building the application is accountable for build, release, and operations, under the governance control of the greater CCoE.  This movement can sometimes take a while, as there will be applications that have no “business owner”, but over time the movement will bring the support closer to the people building or implementing the applications and reduce the overhead that the IT organization carries without a clear business cost justification.

9. Don’t forget backup

Many companies that move to the cloud fail to build appropriate backup and recovery policies.  You’d think this would be an obvious step, but unfortunately a lack of experience can sometimes cause many to assume protection where none exists.  Ensure your build-out contains a cloud recovery strategy that allows for the RPO/RTO objectives to be hit.  This doesn’t mean multi-cloud failover, but mainly is about leveraging the native capabilities of the cloud provider to facilitate the right level of availability or recovery.

10. Leverage Native Tools

Take advantage of the native tools available in the cloud to operate the environment instead of translating your existing platforms into the cloud unnecessarily.  I frequently see companies move their existing backup, log monitoring, antimalware, security, network, and application availability platforms to the cloud.  These can be replaced with cloud-native platforms that work together and typically accomplish the same purposes.  After you have used the full capabilities of the cloud native platform, then you may earn the right to leverage something that adds onto it, if it is really necessary and the cost-for-value is there.