I'm documenting a full move from VBR v13 on Windows to the v13.1 Software Appliance, run for real in my Pure Storage lab before any of it gets called a production map. Part 2 of the series just went up, and it's the architecture conversation, so I wanted to share the highlights here where the architecture arguments actually happen.

The premise: the worst time to make design decisions is mid-migration. The appliance model changes enough old defaults that the target deserves a fresh sheet of paper, not a copy of what your Windows server had. Here's what ended up on my sheet.

The backup server is now an appliance you don't log into. The VSA gives you a hardened, Veeam-managed Linux base with no OS access, and after years of preaching simplicity I find that liberating rather than scary. An OS I can't touch is an OS I can't break, and one an attacker finds much less interesting. The old placement rules still apply though: keep the control plane out of the blast radius of what it protects.

Proxies are VIAs now. The Infrastructure Appliance means no more hand-built Linux proxies. Same locked-down JeOS base as the server, deployed as a role. I size for concurrency (roughly 1 vCPU and 2 GB RAM per concurrent task) and run one in the lab, two in the production map, because one proxy is a single point of slow.

The repo layout is where the real decisions live. I ended up drawing two valid shapes. Map one is the classic: hardened repository as the immutable primary, object storage as the offsite copy tier, and the hardened repo on physical iron, because a virtualized one can be deleted by a hypervisor admin no matter what the filesystem says. Map two, which my lab actually runs, goes object-first: the VIA proxy writes straight to an S3 object repository with Object Lock, plus a copy job to a second bucket elsewhere. Same 3-2-1 skeleton, different immutability engine. Pick by what storage you own.

One gotcha worth underlining: if you go object-first, the bucket must be created with versioning and Object Lock enabled from day one. That is not a setting you bolt on later.

And one design decision people may disagree with: I kept my Windows 13.0 deployment running alongside, on purpose. Some features still live in the Windows console client, it's my parachute, and it's the eventual migration source. Two environments, each earning its place. Happy to debate that one in the comments.

The full post has the two architecture diagrams, the sizing numbers, the platform constraint that decided my build order, and why I deliberately skipped clustering: Moving to v13.1, Part 2: Architecting the Server, Proxies, and Repos

Part 1 (the two maps side by side) is here: Moving to v13.1, Part 1: Sketching the Move

Next up in the series: building 13.0.x on this design, then layering the security framework (SSO, MFA, and the storage side of identity) before anything earns production trust. If you've made this move already, I'd genuinely like to hear where your architecture landed differently.