The Swing Migration Protocol.
How 912 modernizes production server infrastructure without big-bang cutover. Three phases, full rollback at every step, production stays online throughout. Built from fulfilled virtualization work for a Kenyan dairy co-operative — published so infrastructure architects can audit their own migration plans against a real protocol.
- Three-phase migration protocol (Stage → Cutover → Migrate back)
- Real resource-model worked example (SYSPRO + Ordering DB + Domain Controller cluster)
- ZFS, VirtIO, and ARC cache rationale
- The risk-reduction principles behind the protocol
Score your own migration readiness.
This is ungated on purpose. Use it directly in the browser, then turn the result into an internal action plan.
The Protocol
Three phases. Production stays online.
The protocol is structured so every phase is reversible until the final go-live signal. No big-bang cutover, no irreversible operations until the new infrastructure has been validated under live load.
Stage
Deploy the swing server. Replicate production VMs. Boot critical systems in parallel.
- Provision a secondary "swing" server class-matched to production capacity.
- Live-replicate production VMs onto the swing server while the primary stays online.
- Boot critical ERP / SQL systems on the swing server for integrity verification.
- Validate the swing-server stack under production-equivalent load before any cutover decision.
- Production stays online throughout — no user-facing impact yet.
Cutover
Shift operations to the swing server. Wipe and modernize the primary.
- Failover production workloads from the primary to the swing server.
- Zero-fill and wipe the primary server's storage.
- Install the Enterprise KVM / Proxmox hypervisor on the primary.
- Configure ZFS storage pools with ARC cache and bit-rot detection.
- Install hardware upgrades — memory expansion, enterprise SSDs for DB VMs, SAS for less critical workloads.
- Apply Windows Server installation, encryption, and security baseline configuration to host.
Migrate back
Move VMs back to the modernized primary. Configure backup and replication.
- Migrate VMs back from the swing server to the modernized primary.
- Inject VirtIO para-virtualization drivers for near-bare-metal guest performance.
- Test ERP / SQL / Domain Controller / file-server applications under production load.
- Configure VM replication policies between hosts.
- Wire backup-manager integration and define retention.
- Document mount-point-based rapid DR procedures.
Worked Example
Real resource-model from a production cluster.
How we size a typical mid-sized manufacturing virtualization cluster. The exact figures come from a real 912 engagement — yours will differ, but the discipline (DB-first sizing, host headroom reserved, tier-matched storage) carries.
| Workload | Resource Spec |
|---|---|
| SYSPRO DB (primary ERP) | 8 vCPU / 64 GB RAM / Enterprise SSD |
| Ordering DB | 6 vCPU / 48 GB RAM / Enterprise SSD |
| SYSPRO Application Server | 4 vCPU / 24 GB RAM / Enterprise SSD |
| Domain Controller | 2 vCPU / 8 GB RAM / SAS |
| Canteen App Server | 2 vCPU / 8 GB RAM / Enterprise SSD |
| Backup Manager VM | 2 vCPU / 8 GB RAM / Enterprise SSD |
| Proxmox host headroom | 96 GB RAM reserved (~30% buffer) |
| Total cluster sizing | 24 vCPU / 256 GB RAM |
Why This Protocol Works
The principles behind the protocol.
The protocol is structured around three deliberate engineering choices. Each one trades complexity for risk reduction — the trade we make every time.
Storage and memory first, CPU last
Most ERP slowdowns are storage or memory bottlenecks. Processor upgrades on bottlenecked storage are wasted budget. We profile the actual bottleneck during discovery and size the new hardware accordingly.
Never run virtualization at saturation
Hypervisors running at full capacity create long-term instability that only surfaces during peak load. We reserve ~25–30% of host RAM and CPU as headroom and document the capacity runway so growth doesn't blindside operations.
ZFS catches what NTFS and ext4 miss
Silent bit rot on standard file systems is undetectable until it corrupts critical records. ZFS's 256-bit checksumming detects and repairs corruption automatically — essential for SAP, SYSPRO, and SQL Server workloads where data trust is non-negotiable.
Related
Want 912 to run the migration for you?
The protocol is published so your team can audit their own plans. If you'd rather have us design, deploy, and validate the modernization end-to-end — including 6 months of post-deployment support — the engagement model is on the Server Virtualization service brief.