Vendor migrations in London —
VMware, Cisco, on-prem to cloud, done safely.
Servnet runs parallel-run vendor migrations for London businesses staring down VMware Broadcom price changes, Cisco hardware end-of-life, on-prem to cloud lift-and-shift or platform consolidation. Discovery → pilot → migration wave → decommission, with the old platform left running until the new one passes every acceptance test. London cutovers happen on Friday-night windows so Monday open is clean.
Why London is at the front of every current migration cycle
London concentrates the firms most affected by the migration triggers currently in play across the IT estate — VMware's Broadcom-era pricing, Cisco / Catalyst end-of-life, FCA pressure on operational resilience and the public sector's Crown Hosting / Azure consolidation programme.
VMware → Nutanix / vSAN / Azure Stack HCI
Broadcom's VMware licence re-pricing has made the platform cost-prohibitive for many City firms. We run VMware → Nutanix AHV (most common in regulated estates), VMware → vSAN ESA (when the firm stays on the VMware stack) and VMware → Azure Stack HCI (for Microsoft-centric public sector).
Cisco → Fortinet for City branch + perimeter
London multi-site firms running ageing Cisco Catalyst / Meraki / ASA / Firepower are consolidating onto Fortinet single-pane (FortiGate + FortiSwitch + FortiAP) — typically driven by SD-WAN refresh and TCO pressure.
On-prem → AWS / Azure UK regions
Tech City fintechs and London-headquartered firms lift-and-shifting from City data centres to AWS eu-west-2 (London) or Azure UK-South — FCA-aware migrations with the regulator-mandated outsourcing materiality and exit-plan documentation.
Microsoft 365 + cloud-VOIP migrations
Exchange-on-prem → Microsoft 365, on-prem PBX → Teams Voice or 8×8 / RingCentral — typical second-wave migration for City mid-market after the core infrastructure modernisation.
What a Servnet London migration delivers
Discovery + bill-of-quantities
A complete picture of the current estate — every VM, every switch, every firewall rule, every dependency — converted into a migration bill-of-quantities you can defend at a CFO/CTO review.
Target architecture design
Reference architecture for the destination platform — Nutanix cluster sizing, vSAN ESA storage tier, AWS landing zone, FortiGate topology. Includes capacity planning, HA design, resilience tier, network integration.
Pilot environment
Non-production pilot built on the new platform — typically two weeks of soak testing with the customer's own workload patterns, performance benchmarks, failure-mode validation before sign-off to the production migration wave.
Wave-based migration with parallel-run
Production workloads migrated in waves — low-criticality first, then business-as-usual, then trading-floor / customer-facing systems. Old platform stays live throughout so any wave can roll back without customer impact.
Friday-night cutover windows
For City and Canary Wharf customers, cutover happens Friday 18:00 onwards with engineers on-site through the weekend. Soak test through Sunday, post-mortem on Monday morning, support warm for two weeks.
Old-platform decommission + ITAD
Once the new platform has run clean for the agreed soak period, we decommission the legacy estate — chain-of-custody, NCSC-aligned wipe, certified disposal, residual value credit. Closes the loop for SECR + audit.
London migration engagements we run
- ▸City firms off VMware to NutanixFCA-authorised firms in EC2/EC3 with 100–500 VMs moving from vSphere to Nutanix AHV — typically 8–14 weeks discovery-to-decom, with the regulated workload migrated last under change-board sign-off.
- ▸Canary Wharf banks Cisco → FortinetE14 multi-site banks consolidating Cisco ASA + Meraki branch onto FortiGate + FortiSwitch — typically driven by an SD-WAN refresh trigger.
- ▸Tech City fintechs on-prem → AWSShoreditch / EC2A scale-ups moving Series-B-era City data-centre footprint to AWS eu-west-2 — with the FCA outsourcing-materiality memo prepared as part of the engagement.
- ▸NHS London trusts to Crown Hosting / AzureLondon NHS trusts migrating off ageing on-prem to Crown Hosting Data Centres or Azure UK-South — DSP Toolkit + HSCN alignment retained throughout.
- ▸Westminster departments to GovWiFi / CloudCentral government departments and ALBs migrating off on-prem Exchange and legacy on-prem networking onto Microsoft 365 GCC and Crown Hosting / Azure Government.
- ▸Law firms — on-prem PMS to cloudWC2, EC4 law firms migrating practice-management (3E, Elite, Aderant) from on-prem to vendor cloud or AWS-hosted — coordinated with the firm's outsourcing-policy committee.
How a London migration runs week-by-week
Weeks 1–2 — discovery + estate map
Automated discovery (RVTools / vRealize / Lansweeper / native APIs) + interviews with application owners. Produces the migration bill-of-quantities and risk register.
Weeks 3–4 — target design + pilot build
Target architecture signed off by customer architecture board. Pilot environment built in parallel — typically a 3-node cluster, target SAN, target network — and workloads from one non-critical application landed.
Weeks 5–8 — wave migrations
Production workloads migrated in 4–6 waves, each wave validated for performance, integration and security posture before next wave begins. Customer change board signs off each wave.
Weeks 9–10 — soak + decom
New platform runs clean for the agreed soak period (typically 2–4 weeks) with old platform on standby. Once signed off, decommission begins — chain-of-custody, wipe, dispose, certify.
London vendor migrations — common questions
We're a City firm with 200 VMs on vSphere — Broadcom pricing has tripled. What's the right move?
For most City firms with that footprint the right answer is either Nutanix AHV (regulated estate, predictable per-node pricing, AHV is included) or vSAN ESA (if you're staying VMware but want to lose the dedicated SAN). We do both. We'll model the 3-year TCO for both, including the migration cost — typical Nutanix payback is 14–22 months on a 200-VM estate.
Can you migrate without taking down our trading floor?
Yes — that's the whole point of the parallel-run model. We build the new platform alongside the old, migrate the trading-floor systems last, validate every market data feed and order management system against the new platform during pre-open hours, and only cut over once the customer's trading-tech team has signed off. Old platform stays warm for 2 weeks as a rollback option.
How do you handle the FCA outsourcing materiality memo for a cloud migration?
For FCA-authorised customers we produce the technical-input side of the outsourcing materiality assessment — which Important Business Services touch the migrated platform, what the resilience profile of the destination cloud region is, and the exit plan if the cloud provider becomes unavailable or commercially unviable. Your compliance team or external counsel writes the final memo; we provide the technical evidence.
Can you do a Cisco → Fortinet network migration with no downtime?
In most cases yes — we install Fortinet in parallel, migrate sites one at a time over evening windows with rollback ready, and decommission Cisco only after all sites have stabilised. For some core / data-centre switching, a brief weekend window is unavoidable but we plan for sub-2-hour outage.
How long does a 200-VM VMware → Nutanix migration typically take?
Discovery → final-VM-on-new-platform is typically 10–14 weeks for a 200-VM estate, depending on application dependencies and change-board cadence. The actual migration work is shorter (4–6 weeks) — the rest is discovery, design and soak.
We're a Tech City scale-up looking to leave our City data-centre footprint for AWS — can you do it?
Yes — that's a frequent engagement for Shoreditch / EC2A scale-ups. We do the AWS landing-zone design (multi-account, SSO, guardrails, networking), the application-by-application migration (lift-and-shift, refactor, re-architect — application-dependent), and the City data-centre exit. Typical timeline 3–6 months end-to-end.
Other services we deliver in London
Facing a VMware bill, Cisco EOL or cloud migration in London?
Send us the platform, the trigger and the timeline. We'll come back with a discovery scope and a TCO model on the new platform.