Legacy Projects vs Applications

Map legacy Projects to Applications, Environments, and Services; links for mixed legacy/new rollout states.

Written By Zoro

Last updated 26 days ago

dFlow is standardizing on Applications as the primary hub for shipping work.

Legacy Projects remain reachable during migration so existing workloads stay safe. Organisations can be mixed: some resources already live under Applications, others only under the legacy hub, and bookmarks may still use old /project/... paths that redirect to an Application root.

Mental model shift

Legacy Projects mental model

Current model

Project as a grab bag of resources

Application with ordered Environments

Implicit staging

Explicit Environment per stage or region

Mixed service concepts

Typed Services (app, database, docker, …)

What you should do

  1. Prefer creating new work under Applications.

  2. When you move a legacy Project, follow Migrate from legacy Projects to Applications under Migration and Release Notes in the sidebar under Migration and Release Notes (manual wizard, redirects, shared compute, legacy hub access).

  3. Read Product model changes under Migration and Release Notes in the sidebar for how entities and URLs changed on the server.

  4. If navigation differs between teammates, standardise on Application → Environment → Service URLs for anything new; use the legacy Projects hub only for unmigrated work (see the migration guide for how to open it).

See also