Hybrid Multi-Cloud Go-to-Market: Migrate First, Modernise Second

I was a Consulting Solutions Architect at a global technology solutions integrator, working as the in-region VMware ambassador and as the technical and commercial bridge between our teams and VMware's. This was before the Broadcom acquisition, when VMware's hybrid cloud portfolio was still sold as a coherent whole.

The immediate problem sat inside a large UK-headquartered bank. They were migrating virtual machines to public cloud, some rehosted and some refactored, and it was slow and clunky. They also had a hard constraint that changed the shape of the problem entirely: they had to evacuate data centres, on a timeline that was not negotiable.

Those two facts do not sit well together. Refactoring applications for cloud-native targets is the right long-term answer and it is slow, because every application needs assessment, rework and testing. A data centre exit deadline does not care about that. The bank was trying to do the hard version of migration against a clock that only rewarded the fast version.

Underneath it sat a second problem. Cloud-native services were being run by separate teams with their own tooling, their own standards and their own relationships with the hyperscalers. There was no unified view, which meant no consistent security posture, no consistent operating model, and no single place where a decision about the estate could be made. That is a common enterprise position and a difficult one to help with, because a proposal requiring those teams to be reorganised before anything starts is a proposal nobody buys.

The reframe the whole thing rests on. The bank had bound migration and modernisation together. Every application moving to cloud was also being modernised on the way, which is why it was slow and why the exit deadline looked unachievable. The framework's central proposition was that these are two different programmes with two different clocks, and trying to run them as one is what produces a migration that never finishes. Move first, into a target that accepts the estate as it is. Modernise afterwards, application by application, on a timeline set by business value rather than a lease expiry.

That is only credible if the landing target genuinely accepts the estate unchanged, which is exactly what Azure VMware Solution and VMware Cloud on AWS did. Same hypervisor, same management tooling, same operational model the bank already ran. The virtual machines did not need to change and the operations teams did not need retraining. HCX is what made it more than a slide: live migration with no downtime, with layer 2 network extension so addresses did not have to change, meaning applications could move without a change window. On an estate where scheduling downtime across business units is harder than the technical work, that removes the constraint that usually sets the pace. A migration that can actually hit a data centre exit date is worth paying for at a different scale than one that might.

The discovery layer, which made it defensible. None of that is sellable as an assertion, so the framework was built around evidence from the customer's own estate. vRealize Network Insight discovers virtual machines and containers on the network, maps the flows between them, and shows the dependency graph as it actually is rather than as the architecture documents claim. In a bank with years of accumulated estate, those two are rarely the same. That output produces application groupings from real traffic rather than a CMDB nobody trusts, migration waves that avoid splitting a chatty application across a WAN link, and the disposition decision per application on evidence rather than opinion. Leading with discovery also changes the sales conversation, because you arrive with findings about their estate rather than a product pitch, and the findings create the urgency.

Four landing zones, not a binary. Azure VMware Solution, VMware Cloud on AWS, on-premises vSphere and Cloud Foundation, and cloud-native services, with the criteria for choosing between them. Retaining workloads is a legitimate outcome, not a failure to migrate, and in a regulated bank it is always a bigger share of the estate than the cloud strategy slide wants to admit. A framework that cannot say 'this stays where it is' loses the trust of the people who actually know the estate. Presenting all four made the decision a portfolio allocation rather than all-or-nothing, which is where most enterprise cloud programmes stall.

Kubernetes, and a distinction that mattered commercially. The Tanzu Kubernetes offering aligned to upstream rather than a heavily modified distribution. For a bank that matters because it protects against the platform constraining what application teams can adopt, and it keeps the skills they hire for transferable. Development teams have long memories about platforms that promised Kubernetes and delivered something they had to work around. Multi-cluster management covered the clusters the fragmented cloud-native teams already had running, and service mesh handled connectivity and policy between services across environments. The container layer was positioned as the modernise half, deliberately sequenced so it never competed with the migration for budget or attention.

Consistency as the risk argument. NSX carried more of the commercial case than it usually gets credit for. Consistent network and security policy across on-premises, Azure and AWS is what makes a multi-cloud estate governable. Without it every environment has its own security model and the risk function has to assess each separately, which is slow and never finishes. Micro-segmentation applied consistently is also one of the few things that meaningfully answers a regulator's question about lateral movement. vSAN kept the on-premises and cloud targets operationally similar rather than requiring different storage operations in each.

The centre of excellence. Separate teams running cloud-native services independently is a governance problem, not a tooling one, and it shows up as inconsistent security, duplicated spend and decisions nobody can make. The framework proposed a centre of excellence with a common foundation underneath, on the argument that a shared platform gives separate teams something concrete to standardise on rather than asking them to agree on abstract principles. Crucially it was positioned as forming around the migration rather than as a prerequisite to it, because a reorganisation that must happen before any value is delivered does not get approved.

Built as a joint go-to-market, not a solution design. Working with VMware's partner manager and account directors shaped what it had to be. It needed a business view for the people funding it and a technical view for the architects who had to believe it was real, because in a bank you need both agreeing before anything moves. It also had to be usable by people who were not me, which is the difference between a good engagement and a go-to-market asset. Roles were split deliberately between integrator and vendor so both sides knew what they were bringing rather than duplicating each other in front of the customer.

• The joint go-to-market framework itself, built with VMware's partner manager and account directors, carrying a commercial argument and a technical one for the same proposition
• Migrate-then-modernise positioning, separating a data centre exit programme from an application modernisation programme that had been bound together and was stalling both
• The vRealize Network Insight discovery work itself, turning real network flow and dependency data into application groupings, migration waves and a disposition call for each one
• Disposition model across rehost, replatform, rearchitect, retire and retain, with the criteria for choosing between them
• Target landing zone comparison across Azure VMware Solution, VMware Cloud on AWS, on-premises vSphere and Cloud Foundation, and cloud-native services, framed as portfolio allocation rather than a binary cloud decision
• The HCX migration mechanics: live migration and layer 2 extension, which between them remove the downtime window and the re-addressing work that normally paces a move
• Container and modernisation layer positioned as the second phase, using upstream-aligned Kubernetes, multi-cluster management and service mesh
• Consistent network and security policy argument built on NSX micro-segmentation across on-premises and both hyperscalers, aimed at the risk and regulatory conversation
• The centre of excellence proposal, written to bring independently run cloud-native teams onto a shared foundation
• Enablement material usable by account directors and architects without reconstructing the reasoning, with roles split explicitly between integrator and vendor

• The commercial tail of this ran across two UK-headquartered banks, covering subscriptions, professional services and ongoing operations under their enterprise licence agreements
• The bank's migration had stalled because it was carrying a modernisation programme on its back. Splitting the two apart is what made a deadline that could not move actually achievable
• Never built as a one-off. It went on to be used at a second bank, then across the wider enterprise base outside financial services entirely
• Both sides responded well to it. Staff and customers worked from the same material, which held a commercial argument and a technical one for the same proposition
• Changed how the conversation opened. Instead of a product pitch, the first thing a customer saw was their own estate data, already turned into a migration plan
• Put forward a centre of excellence to bring cloud-native teams that had been running independently onto one foundation, aimed at the governance gap sitting underneath the tooling choices rather than the tooling itself

I do not know how much of this was used after I left in 2023, or whether it survived the Broadcom acquisition in any form. The product set it was built on has changed substantially since. The reasoning outlasts it: separating migration from modernisation, leading with dependency evidence rather than assertion, treating retain as a legitimate disposition, and letting the operating model form around the programme rather than blocking it.