Sample Output · Illustrative Data

Cloud Migration Analysis Platform — Sample App-Level Output

One representative application card from the pipeline's per-app report format, showing the Overview, Backlog, Provenance, Technical Details, and Agents tabs. App name, VM identifiers, and site labels below are illustrative — not from a real client engagement.

This page shows the structure and depth of a single per-application recommendation — provenance table, evidence classification, confidence math, action backlog, and agent-level detail. Application, vendor-integration, and site labels are illustrative examples, not a real client's infrastructure.
Sample App — Perinatal Monitoring System
Vendor: Philips · 10 VMs · Criticality: High · HIPAA / HITRUST
RETAIN
40%
Confidence
38%
Data Quality
Disposition: Structurally Retained On-Premises · Current Cost: $65,000/yr · Migration: Not applicable
Overview
Backlog
Provenance
Technical Details
Agents
Recommendation
RETAIN 🔒 STRUCTURAL
SRC-CAP-001 Binding cap · Ceiling: 40% · Threshold: 60%
Secondary: REPURCHASE (blocked — hardware dependency + life-safety pre-check)
Confidence
40%
Disposition is structurally certain; some documentation gaps remain to close.
ROI Summary (Python-computed, not LLM)
Structurally Retained On-Premises
Current Cost: $65,000/yr (continues unchanged)
Migration ROI: Not applicable — this system cannot move to cloud
⚙ Financials computed by provisioning_engine_v3 (Python) — not LLM-generated
Finding
This app is a hardware-integrated obstetric monitoring system with confirmed physical dependencies on bedside CTG fetal heart monitors — it cannot be migrated to cloud without replacing the underlying clinical hardware. The system is classified as life-safety and handles patient PHI, making it a structural retain. Priority actions are confirming the Business Associate Agreement with the vendor and identifying the downstream HL7 interface consumer before any future modernization planning.
In plain terms: this app stays where it is. It is tied to physical hardware or life-safety equipment that cannot move to the cloud. The work here is compliance and lifecycle upkeep, not migration.
This is the list of work needed to move this recommendation forward. The 3 P1 items are the priority — they unlock the recommendation. P2 and P3 items improve confidence and reduce risk but are not blockers. 'Story points' measure effort, not time or cost.
40%
Current
60%
Threshold
55%
Ceiling
34
Story Points
Why This Score
Current confidence is hard-capped at 40 by SRC-CAP-001 (phi_handled=true, baa_confirmed=UNKNOWN), which is the binding constraint — the pre-cap score of 69.0 demonstrates that underlying evidence quality is strong, but no confidence improvement is achievable until the BAA is confirmed and the cap is lifted. All backlog items target cap resolution and ROI variance reduction (currently 45%); confidence deltas are correctly set to 0 because available headroom is zero at the current ceiling.
Proceeding without BAA confirmation leaves a PHI-handling life-safety system in an unresolved HIPAA compliance posture, and without APM telemetry or architecture documentation, any future hardware refresh or SaaS migration planning rests on inferred evidence with 45% ROI variance.
Action Backlog — 6 Items · 34 Story Points · Ceiling: 55%
APP-001-001 Confirm BAA with vendor for cloud-hosted perinatal platform (PHI — SRC-CAP-001 cap resolution)
P1 BAA/Legal
Retrieve or execute a signed Business Associate Agreement (BAA) with the vendor covering the on-premises deployment. phi_handled=true and baa_confirmed=UNKNOWN is the sole trigger for SRC-CAP-001, which hard-caps confidence at 40. Confirming the BAA resolves the cap and is the prerequisite for all subsequent confidence improvement. Engage the health system's compliance officer and the vendor account team.
+15% confidence -0% ROI variance 📋 8 pts
APP-001-002 Deploy 30-Day APM Telemetry Collection on All 10 Perinatal VMs
P1 Telemetry
Deploy APM agent (e.g., Dynatrace, AppDynamics, or Azure Monitor) across all 10 VMs to collect CPU, memory, disk I/O, and network time-series data over a minimum 30-day window. Current telemetry is a single snapshot (snapshot_count=1, apm_telemetry_available=false), triggering SRC-CAP-004 (ceiling 65) and SRC-RS-002 hard rule. Sample VM PERI-RD-02 shows 82% mem_active_pct and requires further investigation.
+0% confidence -0% ROI variance 📋 5 pts
APP-001-003 Retrieve Vendor Contract — ACV, Renewal Date, Support Lifecycle
P1 Procurement
Procurement team must retrieve the current executed contract for the on-premises perinatal platform. Required fields: Annual Contract Value (ACV), renewal/expiration date, SLA terms, vendor support lifecycle for current version, and upgrade path to the cloud-hosted version. Contract intelligence is currently MISSING, contributing a 15% ROI variance penalty.
+0% confidence -0% ROI variance 📋 8 pts
APP-001-004 Identify Downstream HL7/ADT Interface Consumer from Interface VM
P2 Dependency Mapping
The interface VM (PERI-IFACE-01) strongly implies an outbound HL7 or ADT feed, but the downstream consumer is unidentified. This creates an unmapped blast radius for any future modernization or hardware refresh. Engage clinical informatics and the interface engine team to trace the HL7/ADT feed destination and update the dependency catalog.
+0% confidence -0% ROI variance 📋 5 pts
APP-001-005 Produce Architecture Diagram — Multi-Site Topology and Hardware Integration
P2 Architecture
No architecture diagrams exist for this application. The multi-site deployment (DC-East + DC-West), DR failover procedures, and CTG hardware integration topology are currently INFERRED from VM naming patterns only. Engage the vendor account team to obtain the installation guide and produce a current-state architecture diagram covering VM roles and tiers and cross-site replication.
+0% confidence -0% ROI variance 📋 5 pts
APP-001-006 Confirm DR Requirements and Failover RTO/RPO for Life-Safety System
P3 Architecture
DR requirements are currently INFERRED. The multi-site deployment (DC-East + DC-West) implies geographic redundancy, but formal RTO/RPO targets, failover procedures, and clinical downtime tolerances are undocumented. Engage clinical operations and IT leadership to confirm DR requirements — life-safety classification mandates that any DR gap be surfaced as a priority.
+0% confidence -0% ROI variance 📋 3 pts
This tab shows the evidence behind the recommendation. The seven dimensions are scored by quality — CONFIRMED evidence counts fully, INFERRED evidence counts less. The validator table confirms each analysis step passed its checks. Green means the step is sound.
Evidence Classification — 7 Dimensions
Dimension Classification Multiplier Contribution
Telemetry SINGLE 0.50 6.00
Dependency Mapping SINGLE 0.50 5.00
Procurement Contracts MISSING 0.00 0.00
Architecture Diagrams INFERRED 0.25 1.75
Security Compliance INFERRED 0.25 1.25
Business Criticality CONFIRMED 1.00 4.00
Dr Requirements INFERRED 0.25 1.00
Applied Cap: SRC-CAP-001
Validation Reports — Per Agent
Agent Status Provenance Counts Defaults Used Rule Failures
telemetry PASS
SRC:2CUST:10COMP:4DEF:2
None ✓ None
dependency PASS
SRC:6CUST:5COMP:7DEF:2
None ✓ None
procurement PASS
None ✓ None
provisioning PASS_WITH_DEFAULTS
SRC:7CUST:1COMP:9DEF:1
• workload_type defaulted to 'app_server' (indeterminable from source data)
• migration_factor defaulted to 0.2 (migration_complexity not provided)
✓ None
synthesizer PASS
None ✓ None
confidence_advisor PASS
COMP:16
None ✓ None
This section contains the full technical reasoning behind the recommendation: the rules that fired, the decision path, the confidence math, and the open intelligence gaps. It is intended for analysts and engineers. Executive readers can rely on the Overview tab.
Rules Applied
These are the specific governance rules that produced this recommendation.
▸ STRUCTURAL PRE-CHECK
This app was classified RETAIN before any 6R rule was evaluated, because it has hardware integration, latency sensitivity, or a life-safety classification that physically prevents cloud migration.
▸ SRC-CAP-001 (binding)
Confidence is capped at 40 because the app handles PHI and the vendor's Business Associate Agreement is not confirmed. PHI cannot move to a cloud vendor without a confirmed BAA.
▸ SRC-CAP-002
Confidence is capped at 55 because more than half of the seven evidence dimensions are inferred or missing — the conclusion is data-thin.
▸ RULE T2 — Right-Sizing Hard Cap
Right-sizing is limited to a moderate 25% reduction because telemetry is a single snapshot. More aggressive right-sizing needs 30+ days of monitoring data.
Decision Path
The step-by-step trace of how the recommendation was reached, in the system's own terms.
PRE-CHECK EVALUATED: hardware_dependency=true (SOURCED — bedside CTG hardware confirmed via VM notes) life_safety_classification=true, latency_sensitive=true → STRUCTURAL RETAIN (pre-check overrides SaaS availability) SRC-CAP-001: PHI handled + BAA not confirmed → ceiling 40 (ceiling=40) ← BINDING SRC-CAP-002: ≥4 of 7 dimensions INFERRED/MISSING → ceiling 55 (ceiling=55)
Confidence Scoring Breakdown
How the confidence percentage was calculated, dimension by dimension.
Base score: 50 Evidence contributions: Telemetry SINGLE +6.00 Dependency Mapping SINGLE +5.00 Procurement Contracts MISSING +0.00 Architecture Diagrams INFERRED +1.75 Security Compliance INFERRED +1.25 Business Criticality CONFIRMED +4.00 Dr Requirements INFERRED +1.00 Pre-cap score: 69.0 Binding cap applied: SRC-CAP-001 Final confidence: 40%
Intelligence Gaps
Specific things we don't yet know. Each gap is a reason the confidence score is held back.
BAA Status with Vendor — Unconfirmed
phi_handled=true but baa_confirmed=UNKNOWN. HIPAA requires a signed Business Associate Agreement with the vendor for any PHI processing. This is a compliance gap independent of disposition and must be resolved immediately. Triggers SRC-CAP-001, capping confidence at 40.
HL7/ADT Interface Consumer Identity — Unconfirmed
The interface VM (PERI-IFACE-01) strongly implies an outbound HL7 or ADT feed, but the downstream consumer is unidentified. This creates an unmapped blast radius. Any future modernization or hardware refresh planning requires this dependency to be confirmed.
Contract Intelligence — Unavailable
No contract data available for the on-premises deployment. Renewal dates, SLA terms, vendor support lifecycle, and upgrade path to the cloud version are unknown. Procurement team must retrieve current contract.
Architecture Documentation — Absent
No architecture diagrams available. Multi-site deployment topology (DC-East + DC-West), DR failover procedures, and hardware integration architecture are inferred from VM naming patterns only. Required for any future hardware refresh planning.
APM Telemetry — Unavailable
No APM data available. Right-sizing analysis is limited to a single memory snapshot. Sample VM PERI-RD-02 shows 82% mem_active_pct — the only VM approaching pressure thresholds — and warrants investigation to determine if this reflects sustained load or a snapshot artifact.
Technical Detail
A fuller technical explanation of the recommendation and its constraints.
The dependency agent confirmed hardware_dependency=true, latency_sensitive=true, and life_safety_classification=true via SOURCED evidence from VM notes identifying bedside fetal heart monitors (CTG hardware) as upstream physical dependencies. The v4.1 structural pre-check fires unconditionally on this combination, overriding the procurement agent's finding of saas_available=true (a cloud-hosted equivalent product, saas_confidence_inferred=72). The telemetry agent's snapshot_count=1 and apm_telemetry_available=false triggered SRC-RS-002 right-sizing hard rule, and the procurement agent returned baa_confirmed=UNKNOWN, triggering SRC-CAP-001 to cap confidence at 40. REPURCHASE is explicitly refused per v4.1 pre-check refusal rules for hardware-integrated clinical devices.
Secondary Path
The fallback option if the primary recommendation cannot proceed.
Secondary Path — REPURCHASE (blocked — hardware dependency + life-safety pre-check)
The vendor's cloud-hosted perinatal platform is a viable long-term modernization target, but only after a clinical hardware refresh program replaces the bedside CTG monitors with cloud-compatible equivalents. This should be tracked as a future-state initiative in the portfolio roadmap, not an active migration.
Right-Sizing Notes
Why the cloud sizing estimate is set where it is, based on the telemetry available.
Fleet avg mem_active_pct = 24.4% across 10 VMs (all powered on, all Windows Server 2019, no memory pressure). Under Rule T3 alone, 24.4% < 25% would classify as OVERSIZED (SRC-RS-003, 0.40 reduction). However, Rule T2 fires unconditionally because snapshot_count=1 and apm_telemetry_available=false; OVERSIZED and ZOMBIE tiers are forbidden. Tier capped at MODERATE (SRC-RS-002, 0.25 reduction). CPU utilization data is null for all 10 VMs; no CPU-based sizing analysis is possible. Notable outlier: sample VM PERI-RD-02 (DC-West) shows 82.0% mem_active_pct — this VM appears well-utilized or potentially undersized and must be excluded from any right-sizing action pending further telemetry. Application is a clinical fetal heart monitoring system; life_safety_classification is UNKNOWN (catalog field null — TRI-STATE rule applied, not inferred). Any right-sizing action must be validated with the vendor and clinical/biomedical stakeholders before implementation. Recommend 30+ day APM collection to enable definitive tier assignment.
This tab shows the raw output of each analysis agent — the specialized components that examine telemetry, dependencies, contracts, and cost. It is the most detailed and most technical view. Most readers will find the Overview and Backlog tabs sufficient.
Telemetry Agent
Utilization Profilemoderate
Snapshot Count1
APM AvailableFalse
Hard Rule TriggeredTrue
Right-Sizing Opp.True
Agent Confidence48%
Telemetry — VM Counts
Powered Off VMs0
Flagged VMs0
Mem Active % (avg)24.4%
Data WindowSingle snapshot
Dependency Agent
Epic IntegrationFalse
PHI HandledTrue
Hardware DependencyTrue
Latency SensitiveTrue
Blast Radiuscritical
Migration RiskHIGH
Conf (Inferred)82%
Conf (Confirmed)61%
Verificationsingle_source
ComplianceHIPAA / HITRUST
Upstream (2)
Bedside Fetal Heart Monitors (CTG Hardware): confirmed: VM notes — PERI-VM-01, PERI-VM-02 ('Fetal Heart Monitor — Primary Campus')
Hospital Network Infrastructure (LAN/VLAN — DC-East, DC-West): confirmed: datacenter inventory — ['DC-West', 'DC-East']; multi-site deployment implies cross-site replication
Downstream (2)
Unknown HL7/ADT Interface Consumer (inferred from PERI-IFACE-01): inferred: VM notes — interface VM name pattern strongly implies HL7 or ADT outbound feed
EMR System (candidate — not confirmed): inferred: industry pattern — perinatal monitoring platforms commonly integrate with an EMR via HL7 ADT/ORU feeds in large hospital systems
Procurement Agent
SaaS VendorPhilips
SaaS ProductCloud-hosted perinatal platform
Repurchase ViableINSUFFICIENT_EVIDENCE
BAA ConfirmedUNKNOWN
SaaS Confidence
Inferred Score72%
Confirmed Score0%
Verificationsingle_source
Provisioning Agent (Python engine — not LLM)
Current VMs10
Recommended VMs10
Right-Sizing0% reduction
Current TCO/yr$65,000
Projected Cloud TCO$52,000
Migration One-Time$10,400
Dual-Running Cost$39,000
N/A — RETAIN
Year-1 Net
N/A — RETAIN
Steady-State
N/A — RETAIN
3-Year
Migration cost figures are not computed for structurally retained applications.
AWS TargetAmazon EC2
Azure TargetAzure Virtual Machines
Cost Modeldefault_multipliers
DEF: workload_type = 'app_server' (workload_type indeterminable)
DEF: migration_factor = 0.2 (migration_complexity not provided)
DEF: cost_model_basis = 'default_multipliers' (no customer cloud quote provided; using registry defaults)