In Catalio, an Application is the software system you are analyzing, modernizing, or documenting. It is the root organizational concept around which all discovery work is structured — your features, journeys, user stories, and change proposals all tie back to a specific Application.
An Application may be a legacy system you are seeking to understand or replace, a competitor product you are studying, or a greenfield target system you are designing. Think of it as the “north star” reference that keeps all captured knowledge anchored to a specific piece of software.
Why Applications Are Central
Without an Application as the organizing concept, captured knowledge tends to scatter. Requirements float freely, journeys belong to no coherent system, and features are hard to scope. By naming and describing the Application first, you give every downstream artifact a home.
Catalio’s data model flows top-down from Application:
Application
├── Application Versions
├── Features (functional areas)
│ └── Requirements
│ ├── Use Cases
│ └── Test Cases
└── Journeys (captured via Application Version)
└── Journey Steps
Key Fields
When you create or edit an Application, you can record:
| Field | Purpose |
|---|---|
| name | Human-readable name of the software system |
| description | Free-text context: what the system does, who uses it |
| app_type | Classification: service, application, website, library, data_pipeline, or other |
| tech_stack | Technologies and frameworks in use |
| vendor | Vendor or supplier name (for packaged software) |
| ownership_team | Internal team that owns or manages the system |
| modernization_strategy | Intended approach: lift-and-shift, re-platform, rewrite, retire, etc. |
The app_type field classifies what kind of software the Application represents. Use application for user-facing systems, service for backend APIs and daemons, website for content-driven sites, library for shared code packages, data_pipeline for ETL/analytics systems, and other when nothing else fits. Combined with the modernization_strategy field, this classification helps portfolio-level reporting on modernization scope and approach.
Application Lifecycle
Applications are long-lived entities in Catalio — they do not follow a lifecycle like Requirements or Initiatives. They persist as reference points throughout your engagement. You create them once, then progressively enrich them as discovery work proceeds.
You can have multiple Applications in a single organization. A common pattern for enterprise legacy modernization:
- One Application per major legacy system being assessed
- One Application per target replacement system
- Optional competitor Applications for benchmarking
Versioning
Applications can have multiple Application Versions — discrete snapshots representing specific releases, environments, or states of the system. Journeys are always captured against a specific version, which enables rigorous before/after comparison.
Example:
Application: "Oracle EBS Finance Module"
Version: "12.2.9" (legacy baseline)
Version: "Target Design v1" (modernization target)
Features: Organizing Requirements by Functional Area
Within an Application, you organize Requirements into Features — functional groupings that represent distinct areas of the system. Features provide the middle tier of the hierarchy:
Application → Feature → Requirement
A Feature might represent an entire module (e.g., “Accounts Payable”), a workflow (e.g., “Invoice Approval”), or a user-facing capability area. Requirements within a Feature are expected to be tightly related.
Journeys: Capturing Real User Behavior
Journeys in Catalio are always captured in the context of an Application Version. This allows you to:
- Document exactly how users interact with a specific release of the system
- Identify friction points that motivate modernization
- Compare baseline (legacy) journeys against target (new system) journeys
See Journeys for detailed guidance on capturing and analyzing user journeys.
Change Proposals
As AI analysis, document extraction, and stakeholder discovery proceed, Catalio generates Change Proposals scoped to an Application. These proposals suggest new requirements, feature updates, or scope connections — all anchored to the Application for context.
Best Practices
Start with the Application.
Before capturing requirements, journeys, or personas, create the Application record. Even a minimal entry (name + description + app_type) is enough to anchor everything else.
Use descriptive names.
“Oracle EBS Finance” is more useful than “Legacy System” — you may have multiple legacy systems in scope simultaneously.
Reflect real organizational language.
Use the name and vocabulary your stakeholders actually use. If they call it “the Oracle system,” name it that, not “ERP Platform v12.”
Capture modernization strategy early.
Recording the intended modernization strategy (rewrite, re-platform, retire) aligns discovery work with delivery intent from the start.
Keep one Application per discrete system.
Avoid bundling multiple systems into one Application record. Separate Applications allow clean journey comparisons and precise scoping.
Relationships at a Glance
| Related Concept | Relationship |
|---|---|
| Application Version | An Application has many Versions |
| Feature | Features group Requirements within an Application |
| Journey | Journeys are captured against an Application Version |
| Change Proposal | Proposals are scoped to an Application |
| Initiative | Initiatives can include an Application in their scope |
| Component | Components can be mapped to Applications via repository sync |
Next Steps
With an Application created, your next steps are:
- Create Application Versions — Define the releases or states you are analyzing
- Define Features — Organize the functional areas of the Application
- Capture Journeys — Record how users interact with the Application
- Add Requirements — Specify what the Application must do or what its replacement must do
Pro Tip: If you are starting a legacy modernization engagement, create both the legacy Application and the target Application on day one. Linking journeys to specific versions of each gives you the comparison data you need to demonstrate ROI.
Support
Questions about Applications?
- Documentation: Continue reading about Versions and Features
- In-App Help: The AI assistant can help you create and structure Applications
- Email: support@catalio.ai
- Community: Share modernization patterns with other Catalio users