Clarity is built for three transformation patterns. Each one runs through the same six stages; what changes is the sources, the engines and the targets.
Licensing restructures, product retirements and the move to VCF 9 have made the VMware exit real. Clarity gives it the structured discovery, dependency mapping, orchestration and governance a large-scale exit demands.
A European clearing bank ran roughly 9,400 virtual machines* on VMware across two owned data centres and one colocation site. The Broadcom licensing change put a hard date on a renewal the bank had no intention of signing, and the board asked for an exit plan that would not put clearing services at risk. The programme had eighteen months* from mandate to renewal date.
Nobody could say with confidence what ran on which host. Three discovery tools were deployed, each owned by a different team, and the CMDB had drifted so far that infrastructure and application teams could not agree on the number of production servers. Every previous wave plan had collapsed into a dependency argument.
Discovery ingested all three tools, the CMDB and the team spreadsheets into one inventory with the source recorded against every asset; around eleven per cent of records* were duplicates or decommissioned hosts. Dependency mapping exposed links between the clearing platform and older reporting servers that no design document showed.
Move groups and waves were built from that map, runbooks generated per wave and driven through the migration engines, and risks, decisions and approvals logged against the workloads they affected, so the regulator evidence pack came from delivery data rather than being reconstructed afterwards.
The estate left VMware three weeks ahead of the renewal date*, with no unplanned outage on a clearing system. Two waves were rolled back and rescheduled inside their windows. Planning effort per wave fell by roughly sixty per cent* between the first and tenth event as the runbook pattern was reused rather than rebuilt.
Execute an AWS or Azure migration safely, at scale and within the timeline, with discovery, dependency mapping, orchestration and governance integrated natively with the cloud services you are moving to.
A national healthcare provider running patient administration, imaging and a large analytics estate held around 3,100 workloads* across two ageing data centres, one on a lease that would not be renewed. The target was AWS, with a landing zone already built but almost unused. The programme had eleven months* to lease expiry.
Imaging and patient administration cannot be taken down for a long window, and a decade of incremental change had left the systems around them poorly documented. A previous lift-and-shift attempt was stopped after a test migration broke an interface into the pathology system that nobody knew existed.
Discovery consolidated the existing scans, the service catalogue and the imaging vendor's inventory into one estate view, with each workload profiled for size, utilisation, operating system, data classification and clinical criticality. Every asset was given a disposition and roughly a fifth of the estate* was marked retire or retain, removing work before it started.
Dependency mapping found the pathology interface and a set of scheduled jobs crossing what the architecture showed as separate domains, and move groups were rebuilt around them. Runbooks were integrated with AWS Application Migration Service so replication, test launch and cutover ran from the same plan as the manual clinical validation steps, with a named validator and rehearsed rollback for every clinical system.
The data centre was vacated inside the lease deadline, with zero rollbacks on clinical systems and cutover windows averaging under four hours* against a planned six.
Most estates are hybrid: on-premises data centres, private cloud and public cloud accounts accumulated over years. Clarity manages transformation across all of them in one platform, including what stays where it is.
An engineering business with seventeen plants across Europe and Asia ran roughly 5,600 workloads* split between a central data centre, small server rooms at each plant, and unmanaged cloud accounts opened by individual business units. Production control systems had to stay close to the shop floor, so the target was a governed hybrid estate, not a full cloud migration. The programme ran for fourteen months*.
The estate had never been looked at as one thing. Plant IT, central IT and the business unit cloud owners each held part of the picture, and the dependencies that mattered most crossed between them: an MES instance on a plant floor talking to a central ERP, with a reporting layer that had quietly moved to a cloud account nobody in central IT could name.
Discovery pulled all three sides into a single inventory, including cloud accounts found through billing data. Dependency mapping ran across the plant, central and cloud boundary and identified the latency-sensitive links that decided what could not move.
Move groups were defined with the hybrid position built in: some consolidated plant rooms into regional hubs, some moved central workloads to cloud, some were scoped to stay in place with a documented interim network path. Execution ran across local teams in three time zones from one plan, with risks and decisions reviewed centrally each week to stop local fixes drifting from the target model.
Fourteen plant server rooms were consolidated into three regional hubs*, unmanaged cloud accounts fell from twenty-three to four*, and no production line lost a scheduled shift to a migration event. The estate model built during the programme is still the source used to plan the ongoing refresh cycle.
