SoftwareOne’s Gordon Davey on Building a Business-Led Cloud Migration Strategy

Cloud migration can move workloads quickly and still leave a business with the wrong architecture, unexpected costs or little measurable value. Gordon Davey, SoftwareOne’s global practice director for Azure cloud services, argues that the deciding factor is whether technology choices serve clear business outcomes. That means defining the reasons for migration before choosing platforms or deciding how to move applications.

Davey has worked in IT for 25 years, including more than 15 years focused on cloud technologies. He joined SoftwareOne in 2020 and has held global roles across cloud services, product development and shared platforms. His advice centers on a practical sequence: identify the business goals, assess workloads and current use, then match each application and platform to the value the organization expects.

Make the reason for migration a decision tool

A cloud program may have several objectives, but Davey says they should all connect to the organization’s business goals. Those objectives provide a reference point for prioritizing work and evaluating later decisions: does a proposed change help achieve the outcomes that justified the program?

Once leaders state those goals, they can organize the work into streams and set priorities. The discipline matters because migration choices can look attractive from a technical perspective while contributing little to the business. A method that moves applications with less effort, for example, may not be the one that improves customer value, supports growth or addresses the organization’s actual needs.

Davey frames migration as part of scaling the business, rather than as a data-center replacement exercise. IT leaders need to balance technical preferences with the outcomes the organization wants. That shift changes the questions teams ask: instead of focusing only on where an application can run, they must establish what it enables and why the business needs it.

A useful business case starts with a close understanding of the organization and its customers. Executives and technology leaders should define how technology contributes to customer value, describe the expected benefits, set measurable goals and establish a regular way to evaluate new technology. That ongoing review can help teams adopt useful tools without allowing existing plans to stagnate.

With those foundations in place, Davey says, the business case becomes a matter of connecting operational knowledge to the choices that add up to a sound strategy. A successful migration should sharpen the organization’s understanding of what it does and why—not simply change the location where its systems run.

Align teams before moving workloads

Disjointed attitudes and strategies are a common source of difficulty. Migration touches different departments, and those groups may have different expectations for cloud services. A plan developed without understanding those needs can leave teams working toward conflicting aims or treating the transition as a narrow infrastructure project.

Davey recommends aligning the effort with broader business goals across departments, learning what each group needs from cloud services and adjusting the plan to account for those requirements. Cost is part of that picture. Organizations that underestimate the financial nuances, or overlook how cloud changes affect different parts of their operations, can misunderstand what the transition will require.

Strategy also needs clear standards. Davey advises organizations to set measurable goals, establish governance and standards that do not depend on one vendor, and decide where standard products fit alongside more tailored approaches. Teams should keep evaluating new developments and test whether they support the strategy, while avoiding an excessive commitment to any single solution.

That combination gives teams room to adapt while preserving a common framework. Without it, local technology decisions can accumulate without a clear link to business priorities. A cloud strategy is most useful when it makes those priorities visible in day-to-day decisions about workloads, services and spending.

Assess enough to make sound choices

Before migration, organizations need a clear picture of how applications currently run, which technologies they rely on and what barriers stand in the way of cloud adoption. Assessment and advisory work can help build that picture, including how systems are used today and where an application might benefit from a different operating model.

There is a balance to strike. An assessment that spends too long analyzing information with little practical return can delay decisions. But rushing past discovery and planning can lead to poor workload choices or an architecture that needs costly correction later. Davey’s approach is to combine automation with enough business and technology context to make the findings useful.

The resulting migration plan sets a foundation for future cloud use. A fragmented or hurried transition may leave underlying architecture problems in place, creating the need for expensive rework. A measured plan helps teams understand which applications should move first, what treatment each needs and how the work relates to the intended outcomes.

Modernize selectively, and rehost where it fits

There is no single migration path that suits every application. Davey recommends using the assessment to identify which workloads are strong candidates for modernization and which stand to gain the most business value from a cloud-native design. Those applications can receive focused modernization effort and budget.

Other workloads may be better candidates for rehosting. That approach can fit applications whose needs do not justify a larger redesign. The point is to choose the treatment based on each application’s characteristics and expected value, rather than applying the same method across the portfolio.

This distinction gives organizations a way to direct limited modernization resources toward the workloads where change is most likely to matter. It also keeps migration from becoming a blanket technical exercise: application decisions remain connected to the business case.

Multi-cloud needs a reason beyond vendor choice

Davey says multi-cloud strategies are becoming more common, with some organizations seeking to avoid dependence on a single provider. Using several platforms can appear to offer flexibility, but it also brings added complexity in deployment and interoperability. For him, vendor independence alone is a weak reason to adopt multiple clouds; the expected value should drive the decision.

Different platforms may suit different organizations, and teams should assess them individually for financial and user experience considerations. The choice should follow workload requirements and business goals, with the added operational demands of running across platforms accounted for from the start.

Davey uses “poly-cloud” to describe a more deliberate version of this approach. He began using the term while working in an organization adopting cloud technologies, to prompt teams to consider what they wanted each platform to do. The distinction is subtle: some people use “multi-cloud” to mean the same thing. But the broader label can sometimes be treated as permission to put any workload on any provider.

That interpretation can lead to cloud sprawl, rising costs, shadow IT and security exposure. A poly-cloud plan assigns particular platforms to workload types and sets an agreed framework for security and governance. Teams can still use different clouds where they make sense, but platform choices remain tied to a shared strategy.

Generative AI adds pressure to cloud readiness

Interest in generative AI has strengthened the case for proactive cloud planning, Davey says. Organizations looking to bring these tools into everyday workflows need infrastructure that can support their requirements. AI may help reduce time spent on repetitive tasks, lower costs and improve customer experience, but realizing those benefits depends in part on suitable cloud architecture.

Data readiness is another part of the equation. To get full value from generative AI, organizations need data that is structured, organized and accessible. Davey sees cloud services as an enabler of that work, rather than a distraction from it. The increased focus on AI has, in his view, renewed attention to cloud as a foundation for emerging technology.

For technology leaders, the practical takeaway is to connect AI plans to the same assessment and business goals that should guide migration. Cloud adoption alone does not guarantee useful outcomes, and adding platforms without workload rules can create new management problems. The strongest plans begin with the value the organization wants, then assign applications and cloud services accordingly.

That principle applies whether a team is rehosting a workload, modernizing it or selecting among cloud providers. Clear goals, a grounded assessment and intentional governance give each decision a reason—and give the migration a better chance of producing lasting business value.