CHAI DART™

Discovery, Assessment & Rationalization Tool
Automated Application Portfolio Intelligence for Enterprise Modernization
Product: CHAI DART™  |  Powered by: CloudHedge R6Ai®  |  Version: 2026 Edition  |  Classification: General Distribution
"Stop Modernizing in the Dark. Start with Truth."

How to Use This Document

If you are a... Start with... Key sections
Cloud Architect evaluating modernization tooling Section 1 (What is CHAI DART) Sections 1, 2, 5, 7
DevOps / Infrastructure Engineer running discovery Section 3 (Discovery) Sections 3, 4, 5
CIO / CDO seeking portfolio rationalization Section 6 (Reports) Sections 1, 6, 7
Application Team Lead planning migration waves Section 5 (Rationalization) Sections 3, 5, 6
Cloud Cost Analyst estimating AWS migration spend Section 6.3 (AWS Cost) Sections 5, 6

1. What is CHAI DART™?

CHAI DART™ (Discovery, Assessment & Rationalization Tool) is CloudHedge's AI-powered application portfolio intelligence platform. It provides automated, agentless discovery and deep assessment of enterprise application estates running on Windows and Linux servers — combining live host analysis, network dependency mapping, and automated rationalization into a single intelligence engine.

The Core Problem DART Solves:
45% of enterprise cloud migrations fail due to inadequate assessment. Traditional approaches rely on manual interviews, spreadsheets, and static code scans — taking weeks per application and producing error-prone, incomplete intelligence. DART replaces this with automated, AI-driven discovery that delivers complete application context in hours, not weeks.

DART answers three fundamental questions every enterprise must answer before modernizing:

  1. What do I have? — A complete, accurate inventory of every application, component, service, and network connection across the estate
  2. How complex is it to migrate? — Automated complexity scoring per application using DART's R6Ai® intelligence engine
  3. What should I do with each application? — Data-driven 6R rationalization recommendations with AWS cost projections

Key Differentiators

Capability Manual Assessment CHAI DART™
Discovery speed 2–3 weeks per app Hours per project (50+ hosts)
Network dependency mapping Manual interviews Automated Netwatch live capture
Complexity scoring Expert opinion, subjective Formula-based, reproducible
6R recommendation Spreadsheet Automated per host/component
AWS cost projection Manual sizing Automated EC2 mapping per region
Graviton readiness Not assessed Built-in Graviton readiness indicator
Reporting Manual PowerPoint DART Report + Practitioner Report, PDF

2. How DART Discovery Works

2.1 Discovery Architecture

DART uses an agentless architecture. No software is permanently installed on the source servers. CHAI connects to each host over the network using standard protocols (SSH for Linux, WinRM for Windows) to collect system state information.

flowchart LR classDef chai fill:#2020a0,color:#fff,stroke:#435ef8 classDef host fill:#435ef8,color:#fff,stroke:#2020a0 classDef output fill:#8d00fc,color:#fff,stroke:#435ef8 classDef callback fill:#ff0bf9,color:#fff,stroke:#8d00fc subgraph CHAI_Server["CHAI Appliance"] direction TB A[DART Engine] B[R6Ai Analysis] C[Report Generator] end subgraph Linux_Hosts["Linux Hosts (SSH :22)"] direction TB L1[WebLogic Server] L2[WebSphere Server] L3[Tomcat / JBoss] L4[General Linux Process] end subgraph Windows_Hosts["Windows Hosts (WinRM :5986)"] direction TB W1[IIS Website] W2[Console Application] W3[Windows Service] end subgraph Outputs["Assessment Outputs"] direction TB O1[DART Report] O2[Practitioner Report] O3[AWS Cost Comparison] O4[Topology Map] end A -->|Phase 1: Static Info| Linux_Hosts A -->|Phase 1: Static Info| Windows_Hosts A -->|Phase 2: Dynamic Probes| L4 A -->|Netwatch: Live Traffic| Linux_Hosts A -->|Netwatch: Live Traffic| Windows_Hosts Linux_Hosts -->|Callback HTTPS :443| A Windows_Hosts -->|Callback HTTPS :443| A B --> A C --> Outputs class A,B,C chai class L1,L2,L3,L4 host class W1,W2,W3 host class O1,O2,O3,O4 output

2.2 Two-Phase Discovery Process

DART discovery operates in two phases:

Phase What It Does Windows Linux
Phase 1 Collects static host information: OS, CPU, memory, disk, packages, installed software, running processes, network configuration, environment variables Supported Supported
Phase 2 (X-Ray) Attaches dynamic probes to capture live process-to-process communications, outbound connections, file system writes Not supported Supported

Non-Invasive Discovery (Non-X-Ray): For Java application servers (WebLogic, WebSphere, Tomcat, JBoss), DART performs a single-phase discovery. Outgoing connections are determined directly from the application server configuration (DataSource definitions, JMS modules, etc.), making X-Ray unnecessary.

2.3 Projects and Hosts

DART organizes discovery work into Projects. Each project is a logical grouping of hosts:


3. Windows Host Discovery

DART's Windows discovery is non-intrusive and collects comprehensive system and application state information using WinRM over port 5986.

3.1 What DART Discovers on Windows

flowchart TD classDef chai fill:#2020a0,color:#fff,stroke:#435ef8 classDef win fill:#435ef8,color:#fff,stroke:#2020a0 classDef data fill:#8d00fc,color:#fff,stroke:#435ef8 DART[DART Engine] subgraph System_Info[System Information] S1[CPU / Memory / Disk] S2[Operating System] S3[DNS Servers] S4[Installed Packages] S5[Path Variables] S6[NTP Servers] S7[ODBC Drivers and DSNs] end subgraph Apps[Application Types] A1[IIS Websites] A2[Console Applications] A3[Windows Services] end subgraph IIS_Detail[IIS Detail Collected] I1[App Pool and Auth Type] I2[Network Bindings] I3[Virtual Directories] I4[SSL Certificates] I5[Backing Services] I6[Default Documents] end DART -->|WinRM :5986| System_Info DART -->|WinRM :5986| Apps A1 --> IIS_Detail System_Info -->|Callback HTTPS :443| DART Apps -->|Callback HTTPS :443| DART class DART chai class S1,S2,S3,S4,S5,S6,S7 win class A1,A2,A3 win class I1,I2,I3,I4,I5,I6 data

IIS Website Discovery (Full Support)

Data Point Description
Application Pool Name Pool used by the IIS website
Authentication Type Anonymous, Forms-based, Windows, etc.
Network Bindings All protocols and ports
Virtual Directories Physical paths and drive types
SSL Certificates Issuer, issued-to, validity dates
Backing Services Connection strings used by the site
Default Documents Configured default document list

Console & Windows Service Discovery (Beta)

For both Console Applications and Windows Services, DART collects:
- List of file/folder paths of all dependencies
- All DLL dependencies
- Process ID, memory usage, ports, command line, platform (32/64-bit), subsystem

Process Ignore List

Specific processes can be excluded from Windows discovery using the Process Ignore List, configurable per project or globally in Settings.


4. Linux Host Discovery

DART connects to Linux hosts over SSH (port 22) and supports both general process discovery and specialized non-X-Ray discovery for major Java application servers.

4.1 General Linux Process Discovery

For any Linux process, Phase 1 collects:
- CPU, memory, disk, OS, DNS configuration
- All running processes and their ports
- Environment variables, scheduled jobs, network configuration
- Static host entries, external DNS servers

Phase 2 (X-Ray) additionally captures:
- Live inbound and outbound network connections per process
- Hard-coded network dependencies
- File system writes
- External services consumed

4.2 Java Application Server Discovery (Non-X-Ray)

For the four major Java application servers, DART performs a specialized single-phase discovery that extracts full application configuration — eliminating the need for X-Ray probes:

flowchart TD classDef chai fill:#2020a0,color:#fff,stroke:#435ef8 classDef server fill:#435ef8,color:#fff,stroke:#2020a0 classDef config fill:#8d00fc,color:#fff,stroke:#435ef8 DART[DART Engine] DART --> WL[Oracle WebLogic\n12.1.3 / 12.2.1.4] DART --> WS[IBM WebSphere\n8.x / 9.x] DART --> TC[Apache Tomcat\n7 / 8 / 9 / 10] DART --> JB[JBoss EAP 6.1] WL --> WL1[Admin Server\nManaged Servers\nClusters] WL --> WL2[Data Sources\nJMS Modules\nShared Libraries\nCertificates] WS --> WS1[Deployment Manager\nApp Servers\nNode Agents] WS --> WS2[Data Sources\nJMS Config\nShared Libraries\nJNDI Realms] TC --> TC1[Virtual Hosts\nClusters\nApplication Pools] TC --> TC2[JNDI Data Sources\nCertificates\nJMS / Logging\nRealms / Valves] JB --> JB1[Domain Controller\nApplication Servers] JB --> JB2[Data Sources\nShared Libraries\nCertificates] class DART chai class WL,WS,TC,JB server class WL1,WL2,WS1,WS2,TC1,TC2,JB1,JB2 config

Supported Java Application Server Objects

Object WebLogic WebSphere Tomcat JBoss
Shared Application Libraries Discover Discover Discover Discover
Server Certificates Discover Discover Discover Discover
Data Sources Discover Discover Discover Discover
JMS Modules Discover Discover Discover Discover
JNDI Realms Discover Discover Discover
Cluster Configuration Discover Discover Discover Discover

5. Network Intelligence

5.1 Netwatch — Live Network Dependency Capture

Netwatch is DART's network monitoring capability. It captures all inbound and outbound network connections made to/from each host over a configurable monitoring duration — providing ground-truth evidence of actual application communication patterns.

Netwatch is critical for migration wave planning: it reveals hidden dependencies that no static scan or interview can uncover.

flowchart LR classDef chai fill:#2020a0,color:#fff,stroke:#435ef8 classDef host fill:#435ef8,color:#fff,stroke:#2020a0 classDef output fill:#8d00fc,color:#fff,stroke:#435ef8 subgraph Project["Project Hosts"] direction TB H1[Host A\nWeb Server] H2[Host B\nApp Server] H3[Host C\nDatabase] end NW[Netwatch Monitor] subgraph CSV_Fields["Netwatch CSV Output"] direction TB F1[Project / Host Alias / Host IP] F2[Direction: Inbound / Outbound] F3[Port Number] F4[Process ID & Process Name] F5[Connected Host IP] F6[IOPS & Throughput Metrics] end SG[Machine Grouping\nSuggestions] Project --> NW NW --> CSV_Fields NW --> SG class NW chai class H1,H2,H3 host class F1,F2,F3,F4,F5,F6,SG output

How Netwatch Works:
1. Start Netwatch on selected hosts from the project's Discover view
2. Set monitoring duration; optionally clear previous Netwatch data
3. Netwatch runs in the background — status: waiting → in progress → completed
4. Download results as CSV from the project home page (NetWatch Data)
5. DART automatically identifies IPs shared across projects and suggests logical machine groupings

Netwatch CSV Fields: Project_Wave_Name, Host_Alias, Host_IP, Direction, Port, ProcessID, ProcessName, Connected_Host_IP

5.2 Topology Viewer

DART's Topology view visualizes the connections between all discovered hosts and their processes.

Two Topology Views:

View Shows Use Case
Host View All hosts in the project and their process connections Infrastructure-level dependency map
Application View Processes grouped by defined Applications Application-level communication map

Both views support:
- Filtering by host or application
- Customizable layouts
- Double-click on any process, host, or application node for detailed information


6. Rationalization & Assessment

After discovery, DART's Rationalize module applies intelligence to generate actionable migration recommendations.

6.1 The 6R Framework — Host Classification

Every discovered host is classified using the industry-standard 6R migration framework:

flowchart TD classDef chai fill:#2020a0,color:#fff,stroke:#435ef8 classDef r6 fill:#435ef8,color:#fff,stroke:#2020a0 classDef note fill:#f1f2f2,color:#414042,stroke:#a7a9ac HOST[Discovered Host] HOST --> REINVEST[Reinvest\nStrategic — invest further\nto maintain currency] HOST --> RETAIN[Retain\nNo cloud migration\nfunctions adequately] HOST --> RETIRE[Retire\nDecommission or\nconsolidate] REINVEST --> REHOST[Rehost\nLift and shift to cloud\nno modifications] REINVEST --> REPLATFORM[Replatform\nMigrate with component\nreplacements] REINVEST --> REFACTOR[Refactor\nSubstantial overhaul for\ncloud-native adaptation] class HOST chai class REINVEST,RETAIN,RETIRE,REHOST,REPLATFORM,REFACTOR r6
Classification Definition CloudHedge Capability
Reinvest Strategic apps warranting investment to modernize Sub-classified as Rehost, Replatform, or Refactor
Rehost Lift-and-shift to cloud, no modifications Migrate large-scale legacy apps to meet timeline objectives
Replatform Move largely unchanged, replace certain components Windows-to-Linux migration; leaner cloud options
Refactor Substantial overhaul for cloud-native Transition to microservices architecture with CHAI Flow™
Retain No cloud migration On-premises compliance, performance, or investment constraints
Retire Decommission Redundant or consolidatable applications

Classification values are set per host and feed directly into DART report generation.

6.2 Application Complexity Scoring

DART calculates a containerization complexity score for every discovered process. This is a formula-based, reproducible score — not a subjective expert estimate.

Complexity Score Range:

Score Complexity
0 – 25 Low
26 – 35 Medium
36 and above High

Complexity is calculated from:

For Linux X-Ray processes:
- 32-bit process or library detected?
- Hard-coded network dependencies?
- Additional packages required?
- Process user (root vs. service account)?
- Special file permissions or special files detected?
- Hard-coded /etc/hosts entries?
- External DNS servers?
- External services consumed?
- File system writes detected?

For Windows IIS websites:
- Windows features required?
- Additional IIS modules required?
- WebAppPool creation required?
- SSL certificates required?
- Group Managed Service Accounts (gMSAs) required?
- File system writes detected?
- External services consumed?

For Java App Servers (Non-X-Ray — WebSphere, WebLogic, Tomcat):
- External Active Directory integration?
- Database integration (DB2, etc.)?
- Message Queue integration?
- SSL certificates required?

6.3 AWS Cost Comparison

DART calculates the estimated monthly cost of hosting all discovered hosts in an AWS region of your choice.

Cost Calculation Components:
- Compute: EC2 instance selection based on discovered CPU/memory/OS specs
- Storage: EBS/storage based on discovered disk usage
- Network: Data transfer costs
- Business Support: AWS support tier
- VDI: Windows Desktop OS virtualization costs

Features:
- Automatic EC2 instance type mapping per AWS region
- Override instance types to model different cost scenarios
- Compare costs across multiple AWS regions
- Pre- and post-Broadcom VMware cost comparison for savings calculation
- 1-year and 3-year NURI (No Upfront Reserved Instance) options

Prerequisites: Project's Target Cloud must be set to AWS with a preferred region configured.

6.4 AWS Graviton Readiness Assessment

Included by default in every DART project. For each discovered host and component, DART shows:
- Graviton Readiness Indicator (compatible / not compatible)
- Graviton-compatible EC2 instance type recommendations
- Readiness by Application Component Types, Technology Types, and Complexity Levels


7. DART Reports & Dashboards

DART generates two types of reports, available as downloadable PDFs.

7.1 DART Report (CXO / Executive)

The DART Report is the project landing page itself — a live, interactive executive summary automatically generated from discovery data.

flowchart TD classDef section fill:#2020a0,color:#fff,stroke:#435ef8 classDef item fill:#435ef8,color:#fff,stroke:#2020a0 DART_REPORT[DART Report] DART_REPORT --> S1[High Level Summary\nHost count, OS types,\ncomponent count] DART_REPORT --> S2[Cost Savings Opportunity\nProjected savings\nfrom cloud migration] DART_REPORT --> S3[Host Compliance\nOS license expiry timeline\nExpired / 1yr / 2yr / 3yr / 3yr+] DART_REPORT --> S4[Component Report\nComplexity distribution\nTech stack\nComponent types] DART_REPORT --> S5[Database Distribution\nIdentified databases\nManaged service recommendations] DART_REPORT --> S6[Topology\nInteractive connection\nvisualization] DART_REPORT --> S7[Applications\nDefined app groupings\nRationalization details] DART_REPORT --> S8[Components & Hosts\nPer-component and\nper-host detail tables] DART_REPORT --> S9[AWS Graviton\nGraviton readiness\nby type and complexity] class DART_REPORT section class S1,S2,S3,S4,S5,S6,S7,S8,S9 item

7.2 Practitioner Report

The Practitioner Report is the detailed technical report for the IT teams responsible for executing the modernization. It is available per Application, per Component, or per Host.

Sections:

Section Contents
Executive Summary Editable workshop notes and summary
Host Distribution Breakdown by OS (Linux, Windows)
Complexity Distribution All applications with calculated complexity scores
Technology Stack Application components by technology
Topology Network dependency map
Application Information Per-application details and rationalization
Host Information OS, IP, CPU cores, memory, CPU family, DNS, storage

Accessing Practitioner Reports:
- From the Rationalize tab → Hosts tab → View Practitioner Report
- From the Rationalize tab → Applications list → View Practitioner Report
- From the project landing page → Applications, Components, or Hosts sections

7.3 Report Comparison

Feature DART Report Practitioner Report
Audience CIO, CDO, Migration Lead DevOps Engineers, App Owners, Migration Teams
Scope Full portfolio / project Per application, component, or host
Complexity detail Distribution view Per-process scoring breakdown
Host detail Summary table Full OS, CPU, memory, storage, DNS
Editable content No Yes (Executive Summary)
Graviton readiness Yes Yes
Download PDF PDF

8. DART Assessment Workflow

The complete end-to-end DART workflow from project setup to report generation:

flowchart TD classDef phase fill:#2020a0,color:#fff,stroke:#435ef8 classDef step fill:#435ef8,color:#fff,stroke:#2020a0 classDef output fill:#8d00fc,color:#fff,stroke:#435ef8 subgraph Phase1["Phase 1 — Setup"] direction TB P1[Create Project\nSet target cloud + region\nEnable Graviton Assessment] P2[Add Hosts\nLinux via SSH\nWindows via WinRM\nor CSV bulk upload] P3[Configure Vault\nSSH keys, WinRM credentials\nAWS cloud credentials] end subgraph Phase2["Phase 2 — Discover"] direction TB P4[Check Connectivity\nVerify network reachability] P5[Check Prerequisites\nValidate host config\nFetch IIS app list] P6[Run Discovery\nPhase 1 static data collection\nPhase 2 X-Ray for Linux processes] P7[Run Netwatch\nCapture live network traffic\nfor dependency mapping] end subgraph Phase3["Phase 3 — Rationalize"] direction TB P8[Review Topology\nHost view + Application view] P9[Define Applications\nGroup related processes\ninto logical applications] P10[Classify Hosts\nAssign 6R classification\nper host] P11[AWS Cost Comparison\nGenerate cost projections\nfor target AWS region] end subgraph Phase4["Phase 4 — Report"] direction TB P12[Review DART Report\nExecutive portfolio summary] P13[Generate Practitioner Reports\nPer application / component / host] P14[Export CSV Data\nHosts, components, Netwatch\nbulk data download] end Phase1 --> Phase2 --> Phase3 --> Phase4 class P1,P2,P3 step class P4,P5,P6,P7 step class P8,P9,P10,P11 step class P12,P13,P14 output

9. Supported Technology Stack

Application Servers & Middleware

Technology Discovery Support Discovery Type
Oracle WebLogic 12.1.3, 12.2.1.4 Full Non-X-Ray (single phase)
IBM WebSphere 8.x, 9.x Full Non-X-Ray (single phase)
Apache Tomcat 7, 8, 9, 10 Full Non-X-Ray (single phase)
JBoss EAP 6.1 Full Non-X-Ray (single phase)
IIS (Windows) Full Windows discovery
General Linux processes Full Phase 1 + Phase 2 (X-Ray)
Console Applications (Windows) Beta Phase 1
Windows Services Beta Phase 1

Operating Systems — Host Support

OS Version Discovery Support
Red Hat Enterprise Linux 7.x, 8.x Phase 1 + Phase 2
Ubuntu 16+ Phase 1 + Phase 2
Windows Server 2012 R2 and above Phase 1 (non-intrusive)
Windows Server 2016 Phase 1 (non-intrusive)

Connection Protocols

Host OS Protocol Default Port
Linux SSH (key-based or password) 22
Windows WinRM (Basic or Kerberos) 5986
CHAI → OmniDeq HTTPS 443

10. Business Outcomes

CHAI DART™ delivers measurable, documented outcomes at the project level:

600% faster than manual assessment approaches  |  45% reduction in migration failure risk  |  Hours to full portfolio intelligence vs. weeks of manual work

What Organizations Get from DART

Deliverable Description
Complete host inventory Every Windows and Linux host with OS, CPU, memory, disk, installed packages
Application dependency map Live Netwatch capture of all network connections — inbound, outbound, ports, processes
Application complexity scores Automated High/Medium/Low scoring per process, based on 10+ containerization factors
Technology stack report Distribution of app servers, databases, OS types across the portfolio
OS license expiry timeline Which hosts are running end-of-life or near-expiry OS versions, with 5-band timeline
6R rationalization Per-host cloud migration strategy: Rehost, Replatform, Refactor, Retain, Retire
AWS cost projection Monthly cost estimate for hosting the entire discovered portfolio in target AWS region
Graviton readiness Per-component and per-host Graviton compatibility assessment
DART Report (PDF) Executive-ready portfolio summary for CIO/CDO stakeholders
Practitioner Report (PDF) Detailed per-app technical report for migration execution teams

Appendix A — DART vs. Traditional Assessment

Dimension Traditional / Manual CHAI DART™
Data collection Interviews, questionnaires, spreadsheets Agentless automated discovery via SSH / WinRM
Discovery time 2–3 weeks per application Hours for a 50-host project
Network dependencies Self-reported, often incomplete Netwatch live capture — ground truth
Complexity assessment Subjective expert estimate Formula-based R6Ai® scoring — reproducible
OS lifecycle awareness Manual research per application Automatic detection with 5-band expiry timeline
AWS cost projection Manual EC2 sizing spreadsheet Automated per-host EC2 mapping per region
Report quality Variable, manual effort Consistent, auto-generated DART + Practitioner PDFs
Graviton assessment Not typically included Built-in Graviton readiness per host/component
Scalability Bottlenecked by analyst capacity Parallel discovery across all hosts simultaneously

Appendix B — Key DART Concepts Glossary

Term Definition
Project A logical grouping of up to 50 hosts for discovery and assessment (formerly "Wave" in pre-2.x versions)
Host A physical or virtual machine (Linux or Windows) added to a DART project for discovery
Phase 1 Static discovery — collects OS, hardware, installed packages, and process list
Phase 2 (X-Ray) Dynamic discovery — attaches probes to capture live network connections and file system activity (Linux only)
Non-X-Ray Discovery Single-phase discovery for Java app servers (WebLogic, WebSphere, Tomcat, JBoss) — reads config files instead of probes
Netwatch Network monitoring feature that captures all inbound/outbound connections over a configurable time window
Topology Visual map of connections between all hosts and processes in a project
Application A user-defined grouping of processes belonging to the same logical application (e.g., Web + App + DB tiers)
6R Classification Per-host migration strategy: Reinvest (Rehost / Replatform / Refactor), Retain, or Retire
Complexity Score Numerical score (0–High, 26–Medium, 36+–High) reflecting containerization effort per process
DART Report Auto-generated executive portfolio report (the project landing page)
Practitioner Report Detailed technical report per application, component, or host for migration teams
Vault CHAI's secure credential store — holds SSH keys, WinRM credentials, cloud access keys
Graviton Readiness AWS Graviton ARM-based processor compatibility assessment per host/component
AWS Cost Comparison Automated EC2 instance mapping and monthly cost projection for a target AWS region