Applications

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:

Ownership is tracked through the Application’s owner Team relationship rather than a field on the Application itself.

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. Unlike Requirements or Initiatives, they don’t move through a multi-stage review workflow. They do carry a simple status (active, deprecated, archived) so you can mark a system as no longer relevant without deleting its history, but otherwise 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, Requirements group under Features — functional areas that represent distinct parts of the system. Features provide the middle tier of the hierarchy:

Application → Feature → Requirement

Features are not authored by hand. Catalio’s scan detects candidate features as it analyzes the Application, and a domain expert confirms or dismisses each one on the Explore Features stage. Requirements group only under a confirmed Feature. A Feature might represent an entire module (e.g., “Accounts Payable”), a workflow (e.g., “Invoice Approval”), or a user-facing capability area.

Each Feature records how it originated. Scans write scan provenance. The manual value does not mean a user filled out a creation form: there is no standalone Feature creation form in the UI. It marks seeded or migrated legacy rows instead.

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

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