Prompt file imported from RobertoBorges/GHCP-ColdFusion-to-Java (.github/prompts/Phase0-ApplicationDiscovery.prompt.md). Copyright stays with the author.

Phase 0: ColdFusion Application Discovery & Understanding

Objective

Thoroughly analyze and document ColdFusion (CFML) application(s) to understand what the application does, its components, business logic, and behavior. This phase creates the foundation for the migration to Java / Spring Boot.

Goal: Before we can migrate, we must fully understand the existing ColdFusion application.

Context

This prompt works with ColdFusion (CFML) repositories (single or multi-repo). The analysis produces comprehensive documentation about:

• What the application does (features, user journeys)
• How it's structured (components, architecture)
• Business logic location and flow
• All dependencies and integrations

Workflow

graph TD
    A[Start] --> B{Single or Multi-Repo?}
    B -->|Single| C[Analyze ColdFusion Application]
    B -->|Multi| D[Read codebase-repos.md]
    D --> E[Clone repositories]
    E --> F[Generate codebase-analysis.md]
    F --> G[Analyze next repository]
    G --> H[Generate reports/repo-X-discovery.md]
    H --> I{More repos?}
    I -->|Yes| G
    I -->|No| J[Consolidate findings]
    C --> K[Generate Application-Discovery-Report.md]
    J --> K
    K --> L[End - Ready for Phase 1]
    
    style A fill:#90EE90
    style L fill:#90EE90
    style K fill:#FFD700

Step 1: ColdFusion Engine & Framework Detection

First, identify what type of ColdFusion application we're dealing with:

1.1 Detect the CFML Engine

Use file_search and grep_search to identify the engine:

1.2 Detect the CFML Framework

1.3 Detect Application Type

Step 2: Component Discovery

2.1 Request Handlers & Routes

For vanilla .cfm (page-based):

file_search: **/*.cfm
grep_search: "<cfswitch|<cfif structKeyExists\\(url|form"
grep_search: "fuseaction|event=|action="

For ColdBox:

file_search: handlers/**/*.cfc
file_search: config/Router.cfc, config/Coldbox.cfc

For FW/1:

file_search: controllers/**/*.cfc

Document each handler / page:

2.2 Components / Models (Data Layer)

For CF-ORM (persistent="true"):

file_search: **/*.cfc
grep_search: "persistent\\s*=\\s*\"true\"|<cfproperty"
grep_search: "fieldtype=\"one-to-many\"|fieldtype=\"many-to-one\""

For DataMgr:

file_search: **/DataMgr/**/*.cfc
grep_search: "createObject\\(\"component\",\\s*\"DataMgr|getRecords\\(|saveRecord\\("

For raw <cfquery> data access:

grep_search: "<cfquery|queryExecute\\(|<cfstoredproc"

Document each model / component:

2.3 Services & Business Logic

This is CRITICAL for migration - identify where business logic lives:

file_search: **/*Service.cfc, **/services/**/*.cfc
file_search: **/cfcs/**/*.cfc, **/com/**/*.cfc, models/**/*.cfc
grep_search: "createObject\\(\"component\"|new .+\\(\\)|application\\.[a-zA-Z]+\\s*="
grep_search: "<cffunction|function .+\\("

Note: In many CFML apps, singleton service CFCs are instantiated in Application.cfc (onApplicationStart) and stored in the application scope (e.g., application.userService).

Document each service:

2.4 Views & UI Components

For .cfm views + custom tags:

file_search: **/*.cfm
grep_search: "<cfoutput|<cfif|<cfloop|<cfinclude"
file_search: **/tags/**/*.cfm, **/customtags/**/*.cfm
grep_search: "<cf_|<cfmodule|<cfsavecontent|<cfimport"

For layouts / includes:

grep_search: "<cfinclude template=|layout|header.cfm|footer.cfm"

Document UI structure:

2.5 Request Lifecycle & Filters

CFML applications typically implement cross-cutting concerns in Application.cfc lifecycle methods (or Application.cfm for legacy apps), plus custom tags and interceptors.

file_search: **/Application.cfc, **/Application.cfm
grep_search: "onApplicationStart|onSessionStart|onRequestStart|onRequest|onRequestEnd|onError|onMissingTemplate"
grep_search: "<cflogin|<cfloginuser|isUserInRole|<cfapplication"

Document lifecycle / filters:

2.6 Database Schema & Migrations

CFML has no single standard migration tool. Schema may come from hand-written .sql, DataMgr auto-schema, or CommandBox cfmigrations.

file_search: **/*.sql, **/migrations/**/*.cfc
grep_search: "CREATE TABLE|ALTER TABLE"
grep_search: "cfmigrations|migrate up|dbCreateTable|dbCreateColumns"

Document database structure:

2.7 Background Jobs & Scheduled Tasks

grep_search: "<cfschedule|<cfthread|createObject\\(\"java\",\\s*\"java.lang.Thread"
grep_search: "scheduledtasks|neo-cron|cronjob"
file_search: **/scheduled/**/*.cfm, **/tasks/**/*.cfm

Document jobs:

2.8 Dependencies & Built-in Tags

CFML dependencies come from built-in tags/functions, createObject("java",...) interop (often via JavaLoader), CommandBox/ForgeBox modules (box.json), and bundled .jar/CFC libraries.

read_file: box.json (if CommandBox/ForgeBox is used)
file_search: **/*.jar, **/javaloader/**, **/lib/**
grep_search: "<cfmail|<cffile|<cfhttp|<cfdocument|<cfpdf|<cfspreadsheet|<cfimage|<cfftp|<cfldap"
grep_search: "createObject\\(\"java\"|JavaLoader"

Document key dependencies:

Step 3: Business Logic Analysis

3.1 Feature Inventory

Create a complete list of what the application does:

User-Facing Features:

Admin Features:

3.2 User Journeys

Document the main user flows:

graph LR
    A[User] --> B[Login]
    B --> C[Dashboard]
    C --> D[Browse Products]
    D --> E[Add to Cart]
    E --> F[Checkout]
    F --> G[Payment]
    G --> H[Order Confirmation]

3.3 Business Rules Location

CRITICAL: Document where each business rule is implemented:

Step 4: Integration & Dependencies

4.1 External APIs

grep_search: "<cfhttp|createObject\\(\"java\",\\s*\"java.net|WebService|<cfinvoke webservice"

Document external integrations:

4.2 Database Connections

grep_search: "<cfquery datasource=|queryExecute\\(.+datasource|this.datasource"
read_file: Application.cfc / settings.ini.cfm (datasource config) or CF Administrator datasources

Document database usage:

Note: The datasource is typically defined in the CF Administrator, in Application.cfc (this.datasources), or in a config file such as settings.ini.cfm.

4.3 File Storage

grep_search: "<cffile|<cfdirectory|fileWrite\\(|fileRead\\(|expandPath\\("

4.4 Threads / Async Processing

grep_search: "<cfthread|thread action=|<cfschedule"
grep_search: "createObject\\(\"java\",\\s*\"java.util.concurrent"

Step 5: Configuration & Environment

5.1 Configuration Sources

CFML apps configure themselves via Application.cfc (this.* settings), config files (settings.ini.cfm, settings.local.cfm), and the CF Administrator.

read_file: Application.cfc, config/settings.ini.cfm, config/settings.local.cfm
grep_search: "this\\.|application\\.settings|getProfileString\\(|<cfconfig"

Document all configuration values:

5.2 Configuration Files

Step 6: Generate Discovery Report

Create reports/Application-Discovery-Report.md with the following structure:

# Application Discovery Report

**Application Name**: [Name]
**Analysis Date**: [Date]
**CFML Engine**: [Adobe ColdFusion / Lucee / Railo — version]
**Framework**: [Framework + Version, or vanilla Application.cfc/.cfm]
**Application Type**: [Web App/API/Admin Panel/etc.]

## Executive Summary

[2-3 paragraphs describing what this application does, who uses it, and its core purpose]

## Application Architecture

### Architecture Diagram

[Mermaid diagram showing components and their relationships]

### Technology Stack

| Layer | Technology |
|-------|------------|
| Frontend | .cfm + `<cfoutput>` / custom tags + Bootstrap |
| Backend | Adobe ColdFusion 2021 / Lucee 5 (CFML) |
| Database | MySQL 8.0 |
| Cache | Redis / `<cfcache>` |
| Async | `<cfthread>` / `<cfschedule>` |

## Component Inventory

### Handlers / Pages ([Count])
[Table of all request handlers and .cfm pages]

### Models / Components ([Count])
[Table of all models/CFCs with relationships]

### Services ([Count])
[Table of all services with business logic]

### Views ([Count])
[Table of all views/.cfm templates]

> This page/view list and the User Journeys below seed the **visual baseline** capture in Phase 2
> (a screenshot of each page). Note which pages need a record id/param or a specific role to render.

### Lifecycle & Filters ([Count])
[Table of Application.cfc hooks and cross-cutting logic]

### Jobs & Scheduled Tasks ([Count])
[Table of background processes]

## Feature Inventory

### User Features
[Complete list with components]

### Admin Features
[Complete list with components]

## Business Logic Map

[Table mapping business rules to files and functions]

## External Integrations

[Table of all external APIs and services]

## Database Schema

### Entity Relationship Diagram

[Mermaid ER diagram]

### Tables Summary
[Table list with key columns and relationships]

## Environment & Configuration

[Configuration sources and settings]

## Complexity Assessment

| Area | Complexity | Notes |
|------|------------|-------|
| Handlers / Pages | Medium | 15 .cfm pages, standard CRUD |
| Business Logic | High | Complex discount and pricing rules |
| UI | Medium | 45 .cfm templates + custom tags |
| Integrations | Low | 2 external APIs |

## Ready for Phase 1

This application is now documented and ready for technical assessment.

**Next Step**: Run `/phase1-technicalassessment` to gather migration preferences and create the technical assessment report.

Multi-Repository Support

For solutions with multiple repositories, repeat the analysis for each repo and create:

1. Individual reports: reports/[repo-name]-discovery.md
2. Consolidated summary: reports/Application-Discovery-Summary.md

Multi-Repo Workflow

1. Read codebase-repos.md with repository URLs
2. Clone all repositories to repos/ folder
3. Create codebase-analysis.md as task tracker
4. Analyze ONE repository at a time (avoid context overflow)
5. Generate individual discovery report for each
6. Consolidate into summary with cross-repo dependencies

Rules & Constraints

Analysis Rules

• Analyze ONE repository at a time to avoid context overflow
• Read 2000 lines at a time for sufficient context
• Use semantic_search for cross-file pattern discovery
• Document ALL components - don't skip any
• Watch for mixed tag + <cfscript> styles within the same CFC/page

Documentation Rules

• Create reports in reports/ folder
• Use Mermaid diagrams for visualizations
• Make reports human-readable with clear formatting
• Include file paths for all documented components

Business Logic Priority

• CRITICAL: Identify all business logic locations
• Document business rules with file paths and function/method names
• This information is essential for Phase 2 (Migration Planning)

Do NOT

• Do NOT start migration planning in this phase
• Do NOT assess technical risks yet (Phase 1)
• Do NOT make recommendations yet
• Focus ONLY on understanding and documenting

Deliverables

At the end of Phase 0, you should have:

1. ✅ reports/Application-Discovery-Report.md - Complete application understanding
2. ✅ All components documented with file paths
3. ✅ Business logic mapped to specific files and functions
4. ✅ Feature inventory with component relationships
5. ✅ Architecture diagrams (Mermaid)
6. ✅ Database schema documented

Next Step: Proceed to /phase1-technicalassessment to gather user preferences and create the technical assessment.