Legacy Project → current entities

This page summarises product model changes around legacy Projects and the current Application → Environment → Service model. It complements Migrate from legacy Projects to Applications, which covers what to do in the UI and during operator-led bulk migration.

Legacy Project → current entities

Project as the main bucket for services → Application: The Application is the product boundary: name, default Environment, settings.

Project “server” / hosting target → Environment compute: Compute (Worker Node or managed compute) attaches to an Environment, not loosely to a grab bag of services.

Services on a project → Services under an Environment: Same runnable units (app, database, docker, …), but scoped to an Environment after migration.

Implicit or informal stages → Named Environments: Use explicit Environments (for example production, staging) instead of overloading one project.

Navigation and primary hub

• New default: Work flows through Applications in the sidebar and URLs.
• Legacy Projects hub remains reachable for unmigrated work; access may require the legacy dashboard query or bookmark; see the migration task guide.
• Expect team members to see different menus depending on whether they live in Applications or still open the legacy Projects list.

Migration semantics (what the server records)

• An Application is created or updated, with migratedFromProjectId linking back to the source project when a new app is created.
• Shared compute: If another Environment in your tenant already uses the same compute binding, migration may reuse that Environment instead of creating a parallel one.
• The legacy Project gets migratedToEnvironment, is soft-deleted, and disappears from the default legacy listing.
• Services gain environment (and tenant scoping as required). Internal project references may remain until a follow-up normalisation migration runs on the database; see docs/normalize-service-ownership-migration.md in the repo for operators.

URLs and redirects

• Legacy /project/[projectId] paths redirect to the Application that absorbed the project, not necessarily to a specific Service page.
• Update runbooks and bookmarks that assumed stable legacy project/service paths.

Mixed state during rollout

• New Applications and legacy Projects can coexist in the same Organisation.
• Do not assume every teammate sees the same entry point: align on Application URLs for new work and document how to reach the legacy Projects hub when needed.

See also

• Legacy Projects vs Applications: short comparison table.
• What changed in dFlow: overview and links.
• Applications, Environments, Services: current definitions.
• Databases overview: database Services live under an Environment like other Service types.