Teams migrating from Octopus Deploy find the mental model familiar. Projects, environments, lifecycles, releases, channels, targets, tags, variables - the vocabulary maps almost one-to-one. The work of a migration is mostly mechanical: moving definitions across, retiring integrations, and re-pointing CI.
What maps cleanly
Most of it.
Octopus -> Jaws Deploy mapping
What changes shape
A few things are deliberately smaller or different. Workspaces replace Octopus Spaces with a similar model but lighter access controls. Step templates are simpler - less metadata, fewer parameter types. Variable sets as separate first-class objects are absent; the variable scoping mechanism in Jaws Deploy is direct and replaces most of what variable sets were used for.
A practical migration path
The shortest path that's worked for several teams: pick one Octopus project, recreate it manually in Jaws Deploy (the platform is small enough that the recreate-by-hand version is often faster than tooling an import), run both in parallel for a release cycle, point CI at the new project, retire the Octopus project. Repeat. Do not try to migrate everything in one weekend - the parallel-run discipline is what catches the deployment-process subtleties that aren't visible in a structured export.