High-velocity cloud migrations, whether driven by world-changing events or simply a poorly timed data center exit, require a high level of attention and care. In this post, Cloud Architect Tim Perry shares some best practices for accelerated cloud migration.
I’ve worked with a variety of organizations across several sectors as they plan and execute their migrations to the cloud. While each journey to the cloud brings unique hurdles and challenges, high-velocity migrations, often triggered out of necessity rather than long-term transformational strategy, are particularly challenging. Read on for best practices I’ve learned for cultivating a successful high-velocity cloud migration — and moreover, benefiting from an accelerated approach to cloud adoption.
1. Engage the right people
Having the right people involved from the very beginning of any project will be instrumental to success. You need buy-in from impacted stakeholders and a team that is engaged, empowered, and skilled to execute.
While fundamental, in high-velocity migrations, this becomes paramount as the right people will ultimately form a migration “brain trust.” This would complement the traditional Cloud Center of Excellence (CCoE) that normally provides strategic counsel for cloud adoption. This brain trust comprises key members of the delivery team such as project managers, service delivery leads, cloud engineers, and architects. This pool of knowledge will be instrumental throughout the entire program.
In reality, absences will occur: long holidays, maternity leave or departing employees, for example. The goal is to involve key stakeholders and decision-makers as much as possible without creating too much friction and slowing the pace of delivery.
2. Prioritize clear accountability
In previous migrations, we’ve observed that accountabilities can become murky at times. This is typically a by-product of re-organization or shifting job roles that leave gaps in the communication chain.
In high-velocity migrations, very often the design and engineering teams will encounter a problem and need to pivot the solution. These changes must be communicated back through the appropriate channels, and approvals must be sought.
In these cases, it’s important that the approval process is streamlined and as easy and clear as possible. This enables teams to solve the problem quickly and move onto other things in the backlog.
A lack of clear accountability or application ownership can sabotage a migration. Often, an app owner is nominated but not informed or educated on related expectations.
The path to success here depends on an organization’s willingness to commit to a more agile, outcome-focused culture that encourages open collaboration and psychological safety. Without this in place, individuals often employ risk-averse decision-making that pre-empts broader discussions and increases delays.
3. Build a migration framework
A governing framework that outlines the guiding principles for how the migration will be delivered should be in place.
The framework should include:
- Guidance on identified accountabilities across every area, business unit, and platform affected by the migration
- Pre-defined architecture design principles and patterns for applications to adhere to when migrating to the cloud that works in conjunction with an architecture review framework
- Clearly defined thresholds in line with the customer’s cost model
- Clearly defined guidance on geo-political requirements that will impact cloud region selection and data storage requirements
- Clear directives and expectations for compliance and regulatory requirements that will impact migration to the cloud
- Primary expectations of results from running workloads in the cloud (such as expected savings or generation of more revenue from e-commerce), and budgetary constraints (what is allocated for the migration and the expected timeframe for completion)
4. Establish an architecture review framework
As mentioned earlier, migration architects and engineers at times are blocked by design review boards or groups because the solution doesn’t meet x, y, and z requirements.
We have seen these stakeholder groups delay migrations for reasons that are often technically valid. Often, depending on the problem’s severity, the only means of recourse is for the engineering team to escalate the issue up to the program delivery manager who in turn may escalate accordingly.
We understand and respect the process for escalation regarding these types of scenarios. Program ninjas will add contingencies to their timelines and resources to accommodate them.
However, an even better approach is to establish an agreed-upon architecture review framework to govern solution requirements.
Ideally, this framework would:
- Set forth clear guidelines and parameters with which design and engineering teams are to align solutions. This helps avoid any surprises when presenting to the stakeholder group for review and approval.
- Simplify the workflow to enable offline architecture review
- Call for automatic approval for any migration design that meets the hard specific requirements such as no PII data or applications for internal use only.
A word of caution: There is no time for arbitrary review in a high-velocity migration. Too often we’ve seen solution designs sandbagged by stakeholder groups for arbitrary (although sometimes valid) reasons that ultimately delay the migration program.
For example, we’ve seen a new security architect join the architecture review board with no briefing or context provided. Until the new member was brought up to speed on the program’s guiding directives, the migration program suffered setbacks.
5. Communication consistency and clarity
Communication breakdowns between members of the delivery team often lead to error and lost time. For example, if a team member changes the scope of an application but fails to alert the right engineer, the risk increases for potential mistakes such as failing over the wrong virtual machine and causing an unintended business outage.
More likely, though, an engineer will waste time building and preparing for the migration of a server that was ruled out of scope. These types of things need to be communicated beforehand to avoid asking “how long does a server migration take?” after a plan has been created.
These types of situations inevitably will occur. However, if they happen too often the consequences can be drastic for a high-velocity migration, where the fast pace demands a slim margin for error. Engineering time lost to remediation work is highly disruptive to a tightly coupled migration workflow.
6. Unified program management tooling
To combat the challenges that a dual Project Management Office (PMO) can present during a critical high-velocity migration, the use of a single shared project management tool can be invaluable.
This became apparent in a migration we performed for an organization that used a single spreadsheet to track a program of 300 applications. The tracker wasn’t widely available for everyone on the delivery team, and it was maintained by one person. Others were discouraged from updating it in case of causing breaking changes. Something as simple as a misspelled server name could have caused the formula applied to be removed from scope.
Fortunately, the same organization happily enforced the use of Microsoft Teams for all migration communications and SharePoint to enable better collaboration on design documents, migration runbooks, and more.
7. Application portfolio assessments are not the be-all-end-all
At Cloudreach, we use Cloudamize, our in-house cloud assessment, and management platform, to perform an automated deep dive into a customer’s application portfolio and identify as many dependencies as possible.
While this provides an invaluable snapshot of the portfolio, in reality, organizations almost always have unique and personalized applications. No tool would be capable of itemizing each and every dependency (let alone determine the appropriate tactical approach!).
In these cases, care and diligence is required to manually review and collate information and build an application profile. This process can vary. Often, if no solution design documentation is available, it requires contacting the application owner to determine the profile of their application.
Because this is a time-consuming approach, it’s important (when possible) to call out these instances and manage expectations accordingly.
This is a particular challenge during high-velocity migrations, where migrating x number of applications per sprint is an executively measured outcome.
In these scenarios, we work to help customers understand the three vectors of value: Good, Fast and Cheap.
The rule of thumb is that, if you want something good and fast, then it cannot be cheap. Conversely. if you want something cheap and fast, then it cannot be good.
In (engineering) practice, high-velocity migrations often pan out in one of two ways:
- Delivered at high velocity (fast) with minimal cost (cheap) and will incur tech debt (not good)
- Delivered at high velocity (fast) with minimal tech debt (good) and will incur increased cost (not cheap)
Most tech leaders understand this and attempt to strike a balance between the two. While well-intentioned, taking a balanced approach can cascade unforeseen issues throughout the delivery program.
A balanced approach makes it difficult for decision-makers to understand where the lines are drawn. For example, if a complex application needs to be re-built as cloud-native (low tech-debt, high cost) instead of a lift & shift (high tech-debt, low cost), the decision will need to be escalated and reviewed (more time wasted).
This is where a well-designed migration framework can simplify such decision points and help create a more seamless flow – a major tenet of high-velocity migrations.
8. Dependency mapping mythbusting
I mentioned earlier that a key part of an application assessment (automated or manual) is mapping out the dependencies of a particular application. In my experience, dependencies can vary widely from a simple file share to remote cron jobs to SSIS packages or even connections to and from a third party.
Each type requires a different tactical approach during a migration.
Just because an automated cloud assessment has picked up a few dependencies doesn’t mean the job is done. Sometimes, as an architect, I need to re-design entire components of the target architecture to make it work. Other times, we can simply ”add” it to the design and scope.
Ultimately, identifying the dependencies is the first step, but how we address them can end up making or breaking the migration – from both a technical and business delivery perspective.
For example, intricate and complex applications with inadequate documentation or understanding from application owners can end up tumbling down difficult migration paths full of design pivots and troubleshooting calls largely due to dependencies being undisclosed or, even worse, identified half-way through a migration.
Licensing, like death and taxes, is something that we all have to deal with. In a high-velocity migration, it is critical to ensure that licensing loose ends are all tied up. If not, they will inevitably come back to tangle your project. Specific actions to take include:
- Review current licensing arrangements to confirm that they are fit for migration to the appropriate cloud provider. For example, some enterprises have personalized licensing agreements with their software vendor that might not easily translate to the cloud.
- Review current software versions to ensure they are compatible with the appropriate cloud provider. For example, Oracle’s Real Application Cluster is not supported on any public cloud platform except their own Oracle Cloud. Enterprises running this legacy database platform have been forced to pivot the migration design, causing delays and incurring increased costs.
- When possible, engage your licensing specialist as early as possible to map out compatibility and potential costs or better yet, potential savings.
10. Apply CI/CD principles to the migration program itself
As the migration program chugs along, be sure to review how it’s progressing. Look at the current processes and tooling that support all aspects of project delivery \ to ensure they still fit the purpose.
Invaluable insights will surface through constant review with and solicitation of feedback from key players in project delivery. The migration framework should be a living document. It needs to be fed those actionable insights.
Implementing changes to streamline and simplify the process will best position your high-velocity migration project for success.
Accelerated cloud migration may seem like a challenge (and it is!). These best practices and lessons learned should help support and speed your migration efforts. With the right people and processes – and a trusted partner – your organization can reap the benefits sooner than you think.
Cloudreach experts have completed 150 migration projects over the past 10 years. We help complex enterprises navigate their first steps into the public cloud — and then continuously improve and optimize once there.
Still not convinced that it’s time to move to the cloud? Read our ebook: Is it time to break up with your data center?