Classify customer workloads into DR protection classes (Tier 0–4), capture the dependencies that form a service, and derive Veeam Recovery Orchestrator runbook groups — in one offline HTML file.
Community project — not an official Veeam product. This tool is a working aid created by a Veeam Technical Account Manager and shared in the spirit of open source. It is not created by Veeam R&D, not validated by Veeam QA and not covered by Veeam Support. Results are a structured basis for discussion and are validated together with the customer — without warranty.
DR concept workshops tend to start from scratch: the inventory arrives as a raw RVTools export, classification happens ad hoc in throwaway spreadsheets, and dependency knowledge stays in people's heads. This tool standardizes that path — import, classify, validate, hand over — so a consistent, customer-ready DR classification and a runbook proposal exist at the end of the workshop, not weeks later.
- Download
DR_Workload_Classification.htmlfrom the latest release (or fromdist/in this repository). - Open it in a current browser (Chrome, Edge, Firefox). No installation, no internet.
- Drop an RVTools export onto tab ① — try
Examples/RVTools/RVTools_export_TESTDATA_210_VMs.xlsx. - Rate the workloads, enter dependencies, look at tab ② and ③, export to Excel.
To explore without importing, load Examples/Progress_JSONs/DR_Assessment_Progress_TEST_C_203_VMs.json:
203 pre-classified workloads with dependencies, ready for the runbook tab.
Tab ① New assessment. Import an inventory — validated sources are RVTools (vInfo) and the
Veeam ONE report VMs Configuration (vSphere and Hyper-V, exported as Excel); CMDB/ServiceNow lists
and CSV work through the generic column mapping. Several sources can be imported one after another
with a duplicate dialog. Hierarchical reports are handled: header repeats, cluster/host subtotals and
section headers are skipped, the cluster/host is inherited as location, Veeam replicas are excluded
by default, as are templates, SRM placeholders and vSphere system VMs (vCLS, Supervisor control plane). Then rate each workload on three criteria (1–5):
| Criterion | Weight |
|---|---|
| Business Impact (BI) | 45 % |
| Regulatory (Reg) | 35 % |
| Data Sensitivity (DS) | 20 % |
Score = BI × 0.45 + Reg × 0.35 + DS × 0.20. Recovery Complexity (RK) is captured as well but is documentation only — hard to restore does not mean critical. Flags: Foundational (AD/DNS/PKI-type systems everything depends on → always Tier 0), Out of scope, Depends on foundation, Validated by customer. Actual RPO/RTO in hours produce gap findings against the class targets. Dependencies are entered as names or list numbers; "Required by" fills itself. An optional rule-based prequalification wizard proposes ratings from naming patterns (SQL, Oracle, SAP, Exchange, AD/DNS, file, print, VDI …) — proposals only, applied after confirmation and marked until validated.
Tab ② View classification. KPIs, distribution chart, sortable register and the dependency network with findings: weakest-link RTO risks (a system depends on something in a lower class), circular dependencies, RPO/RTO gaps. Print view for a PDF hand-out.
Tab ③ Runbook planning (VRO). Dependency-connected groups as orchestration-plan candidates with a topological start order, editable group names, a service owner per group, a foundation block that always starts first, and warnings when protection classes are mixed inside a group. Includes field guidance on how foundation systems are handled in a DR event versus in a DataLab test.
Validation. Before hand-over, upload a source file again: it is read exactly like on import and compared only with the workloads that came from it — missing or extra workloads and deviating size/OS/cluster values are reported, deliberately deleted workloads and filtered rows appear as notes, and missing ones can be imported with one click. Every file validated in the session stays one click away in the coverage line, always re-checked against the current list.
Export. A formatted Excel workbook (Instructions, Class-Matrix, Workload-Register, Dashboard, Runbook-Plan) that round-trips back into the tool, plus a progress file (JSON) for resuming later.
| Class | Score | Target RPO | Target RTO |
|---|---|---|---|
| Tier 0 – Foundation | Foundational flag | ≈ 0 (continuous) | < 30 min |
| Tier 1 – Platinum | ≥ 4.3 | < 15 min | < 1 h |
| Tier 2 – Gold | ≥ 3.5 | < 1 h | < 4 h |
| Tier 3 – Silver | ≥ 2.5 | < 4 h | < 24 h |
| Tier 4 – Bronze | below | < 24 h | < 72 h / best effort |
Weighted multi-criteria scoring is established BIA practice; ISO 22301/22317, BSI 200-4, NIST SP 800-34, BCI GPG and DORA/NIS2 require criticality classes with RTO/RPO targets but prescribe no formula. The defaults are a starting point — the binding calibration belongs to the customer. Weights stay fixed; thresholds, target RPO/RTO and display names are editable in the options panel. "Tier" here means workload protection classes and is unrelated to Uptime Institute data-center tiers.
Everything runs locally in the browser. No server, no telemetry, no AI at runtime, no data retrieval from the internet. All libraries are embedded. Inventories and assessments never leave the machine; the only outbound actions are documentation links and the "Report issue" button, which opens a prefilled issue form on GitHub in your browser. Files you load are treated as untrusted input and type-checked. Details in SECURITY.md.
| Path | Content |
|---|---|
dist/DR_Workload_Classification.html |
The tool. One file, ~1.9 MB, bilingual EN/DE (English default). Generated — do not edit |
src/ |
The application source: page shell with the markup (index.html), styles.css, and the JavaScript in 16 files in load order (app/) |
vendor/ |
The four embedded libraries, unmodified, with version, license and checksum (vendor/README.md) |
tools/build.mjs |
Builds dist/ from src/, vendor/ and the export template. Node, no dependencies |
Examples/RVTools/ |
Synthetic RVTools exports with 210 / 2,000 / 5,000 VMs |
Examples/VeeamONE/ |
Anonymized real Veeam ONE VMs Configuration reports (vSphere, Hyper-V) and a synthetic report |
Examples/CMDB_CSV/ |
Synthetic ServiceNow-style and German semicolon CSV lists |
Examples/Progress_JSONs/ |
Pre-classified datasets (203 / 1,450 / 1,993 workloads) and one with a newer tool version to try the version guard |
Examples/Manual_Workbook/ |
Filled examples of the manual-entry workbook |
Outputs/ |
The customer manual-entry workbook (for engagements without RVTools) and the export template |
CHANGELOG.md |
Release history; the current release is also shown in the tool's About dialog |
ARCHITECTURE.md |
Structure of the single file: script blocks, data flow, stable keys, how to verify a change |
docs/screenshots/ |
The screenshots used in this README |
The tool ships as one HTML file so that it runs offline from a USB stick, but it is developed as ordinary source files. What you download is assembled from them by a short script without dependencies:
node tools/build.mjs # writes dist/DR_Workload_Classification.html
node tools/build.mjs --check # verifies that dist/ is exactly the build output of the sources
The build only concatenates files and base64-encodes the Excel export template; it does not minify or
transform the application code. A GitHub Action runs the check on every push, and the file attached to a
release is built by GitHub from the tagged sources. The application code is in src/app/; everything in
vendor/ is third-party.
Tested with synthetic inventories up to 5,000 workloads. Tables are paginated; the dependency graph protects itself above 1,500 workloads (unconnected nodes are dropped) and switches to a static layout above 600 nodes (a selector forces animated or static). For very large environments, split the survey into waves, for example per site or cluster.
Dark mode is available from the ⚙ menu. The tier palette is the Okabe-Ito set, chosen to stay distinguishable for the common forms of colour-vision deficiency, so there is no separate colorblind mode.
Dark mode: assessment table
Issues and pull requests are welcome — see CONTRIBUTING.md; ARCHITECTURE.md is the map of the source file. Field feedback on the methodology is as valuable as code. Commits are signed off (DCO).
MIT — see LICENSE. Embedded libraries: SheetJS Community Edition (Apache-2.0), Chart.js (MIT), D3.js (ISC), fflate (MIT); their license texts are in vendor/licenses/.
Klaus Wittenberg, Technical Account Management (Professional Services), Veeam Software.
The idea and the methodology come from DR concept workshops with customers. The design was worked out in dialogue with Claude (Anthropic), Claude wrote the code, and every round was tested in real workshops before it went in. The tool itself contains no AI functionality and never calls any service — see Data and privacy.