How to Use This Document

1. What is CHAI Flow™?

CHAI Flow™ is CloudHedge's end-to-end agentic application modernization platform. It combines automated discovery and deep assessment with AI-driven containerization and Kubernetes deployment — delivering a single, continuous workflow from bare-metal legacy servers to production cloud-native workloads.

CHAI Flow™ is organized into three integrated phases:

Key Differentiators

2. DART — Discovery Architecture

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.

2.2 Two-Phase Discovery Process

DART discovery operates in two phases:

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:

• Up to 50 hosts per project (Linux and Windows mixed)
• Hosts added by registering credentials (SSH key or password for Linux; WinRM credentials for Windows)
• Hosts can also be added via CSV bulk upload or offline discovery utility
• Projects replaced the legacy "Wave" concept in DART 2.x

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

IIS Website Discovery (Full Support)

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:

Supported Java Application Server Objects

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.

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:

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:

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:

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.

7.2 Practitioner Report

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

Sections:

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

8. Transform — Containerization

Transform is CHAI Flow's automated containerization engine. It takes the process artifacts collected during DART discovery — binaries, dependencies, ports, configuration — and builds production-ready Docker container images without manual Dockerfile authoring.

8.1 What is Transform

Transform builds a Docker container image from all artifacts collected during the discover phase: process binaries, process dependencies, and process port bindings. The entire process is agentless.

Transform operates in two phases:

8.2 Build Box

The Build Box is the intermediate host that runs the Docker daemon and builds container images from process information.

Build Box Operating System Support:
- Linux (SSH connection, port 22)
- Windows (for Windows container builds)

Prerequisites: The Build Box must satisfy platform-specific prerequisites (available in CHAI settings) before a Transform job can start. This is a mandatory step.

Base Image: Each Transform job uses a base Docker image (from Docker Hub or a custom source) as the foundation into which process information is inserted to create the final application container.

8.3 Application Transformation Studio

The Application Transformation Studio is CHAI Flow's one-stop interface for managing the full containerization workflow. It preserves all historical discovery data as an immutable record and allows users to create editable copies for customization.

Key Principle: Original discovery data is immutable. All customization work is performed on named copies (profiles), preserving the source-of-truth.

Studio Features

Profile Management Workflow

8.4 Containerizing Linux Processes

CHAI Flow containerizes any discovered Linux process directly from the Transform view.

Workflow:
1. Select the project and click Transform in the left menu
2. Click Containerize next to the desired process
3. Click Create Copy to create an editable profile
4. Customize via tabs: Edit Dockerfile, File Selection, Container Config
5. Click Validate and Build — select the Build Box and configure registry
6. Click Build Container Image to trigger the build
7. Monitor progress in the Logs tab
8. Verify the image in the configured registry upon completion

Registry Configuration per Type:

8.5 Containerizing Windows Processes

CHAI Flow supports containerization of the three Windows application types discovered by DART:

IIS Merge Feature: Multiple IIS websites can be merged into a single container image — enabling consolidation of related web applications without architectural changes.

Console and Service Applications: Working directories are captured from Program Files locations; additional files can be included or excluded during the Transform configuration step.

Windows Build Workflow:
1. Navigate to Transform → select Windows process → click Containerize
2. Create a profile copy
3. Click Validate and Build
4. Add Windows Build Box credentials
5. Select registry type and provide registry configuration
6. Run pre-checks
7. Click Build Container Image

8.6 Replatforming Java Application Servers

Transform's most powerful capability: taking Windows-hosted Java application servers and replatforming them to Linux container images — eliminating the Windows runtime dependency entirely.

Replatform Base Images:

Replatform Workflow (all Java servers follow the same pattern):
1. Click on the project → Transform → select the Java app server process → Containerize
2. Click Create Copy to create a customizable profile
3. Use the three customization tabs:
- Edit Dockerfile: Review and optionally modify the auto-generated Dockerfile. Base image is selected automatically based on the discovered server version
- File Selection: Bundle additional files into the container image
- Container Config: Review and complete all ConfigMaps. Parameters requiring user input are marked <change-me>. SSL keystore configuration is included where certificates were discovered
4. Click Validate and Build → select the Linux Build Box → configure registry
5. Click Build Container Image
6. Monitor logs; verify image in registry on completion

9. Cruise — Kubernetes Deployment

Cruise (internally referenced as Cruize) is CHAI Flow's self-service Kubernetes deployment engine. It takes container images produced by Transform and deploys them as production workloads on any CNCF-compliant Kubernetes cluster — with no manual YAML authoring required.

9.1 What is Cruise

Cruise is a self-service platform for on-demand application deployments on any CNCF-compliant Kubernetes cluster. It bridges the gap between container images (produced by Transform) and running production workloads — using Application Blueprints as the portable deployment specification.

Cruise Core Concepts:

9.2 Application Blueprints

An Application Blueprint describes all application components, their container images, and runtime configuration. Blueprints are created automatically when a Transform profile is finalized, or manually through the Cruise UI.

Blueprint Creation Methods:

Blueprint Name Requirements:
- Alphanumeric characters and hyphens only
- Must start and end with alphanumeric character
- Maximum 25 characters, unique within the project

Blueprint Version Lifecycle:
1. Create blueprint (v0 by default)
2. Create copies for parallel development or hotfixes
3. Promote a version to final; deploy to target cluster
4. Create next version as the application evolves (max 10 revisions)

Blueprint Operations:

9.3 Cluster Management — Bring Your Own Cluster

Cruise supports importing any of the following Kubernetes distributions:

Add Cluster Workflow:

Cluster validation confirms:
- Kubernetes version
- Node count and health
- Available namespaces
- Persistent volumes
- Ingress controllers

9.4 Creating Workloads

A Workload is a running application on a Kubernetes cluster — the result of deploying an Application Blueprint to a target cluster.

Workload Creation — Three-Step Process:

Environment Options: Development, Stage, QA, Production

Namespace Override: If the blueprint's defined namespace does not exist on the target cluster, Cruise allows a namespace override at deployment time.

9.5 Viewing and Managing Workloads

Cruise provides two views for workload visibility:

Both views provide unified visibility across environments, clusters, and blueprint versions — enabling platform teams to see the full deployment landscape from a single screen.

10. End-to-End CHAI Flow Workflow

The complete CHAI Flow modernization journey from first discovery to production Kubernetes workload:

11. Supported Technology Stack

Application Servers and Middleware

Operating Systems

Kubernetes Cluster Platforms

Container Registries

Connection Protocols

12. Business Outcomes

CHAI Flow™ delivers end-to-end modernization outcomes — from discovery through to production Kubernetes deployment:

What Organizations Get from CHAI Flow

Appendix A — CHAI Flow vs Traditional Modernization

Appendix B — Key CHAI Flow Concepts Glossary