Virtualization transition
Start by finding a supported destination for each workload. Then define the data transfer, runtime deployment, validation, and operating responsibilities that make the transition practical.
First, establish fit
Spark™ and CloudSpawn™ serve different operating patterns. The selected platform and configuration define runtime, storage, capacity, resilience, and expansion options.
A replacement-host path for qualified VMware-hosted workloads that fit a single-node operating environment. The design selects a supported target hypervisor, typically KVM, and defines runtime, SAN connection, network, capacity, resilience, and upgrade requirements.
Review Spark™A destination for coordinated multi-resource infrastructure, elastic capacity, and stateful cluster growth. When paired with Storm™, the Storm™ cluster-management platform manages supported cluster resources and dependencies within the CloudSpawn™ tenant boundary.
Review CloudSpawn™From inventory to cutover
Once a destination is qualified, connect each migration stage to the decisions needed to carry it out.
Identify a supported destination before planning the move.
Record source products and versions, guest operating systems, virtual disks, application data, dependencies, identity, networks, availability, and recovery needs for each workload group. Qualify the applicable platform, target hypervisor, runtime, hardware, and operating boundary.
Move workload data into the NetThunder-managed SAN selected for the target.
Define the supported export or transfer method, target volumes, storage connection, coexistence window, encryption and access requirements, integrity checks, failure handling, and recovery path.
Run supported virtual machines and containers on the same qualified target hardware.
Specify the supported hypervisor, virtual-machine format, container runtime, guest support, SAN connection, networks, identity, capacity, isolation, and operating responsibilities.
Test the target against agreed acceptance criteria before approving cutover.
Check application behavior, data integrity, connectivity, performance, recovery, security, monitoring, and operating handoff. Define downtime, rollback, and source-retirement criteria for the selected workload group.
Acceptance checkpoint
Each workload needs a supported runtime, qualified hardware and storage path, defined migration method, and testable acceptance criteria. Source versions, guest support, conversion, downtime, coexistence, rollback, licensing, and support remain specific to the selected workload group.
VMware and Broadcom identify the source estate only; no endorsement is implied.
After cutover
The environment definition continues beyond migration. Plan supported additions, replacements, and upgrades with approval gates, maintenance windows, and validation appropriate to each change.
Add qualified SAN capacity as data and workload requirements grow, while storage relationships remain part of the managed environment.
Add or replace supported compute, storage, and network resources across qualified vendors and generations as requirements change.
NetThunder retains required state and dependencies, then reconciles affected resources through supported lifecycle changes.
Architecture review
Start with a high-level, non-sensitive inventory of workloads, data, capacity, availability, and growth goals. Use the review to evaluate supported targets and the decisions required for transition.
