# Migrating from Octopus Deploy

Source: https://www.jawsdeploy.net/guides/migrating-from-octopus-deploy

The mental model maps closely. The differences are mostly in scope, pricing, and the size of the install.

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

- **Project**: Same concept. One project = one deployable unit, owns its process and variables.
- **Environment**: Same. Dev, Staging, Production - scope for variables and step targeting.
- **Lifecycle**: Same. Ordered phases that releases must walk through.
- **Release**: Same. Immutable snapshot of packages, variables, and process.
- **Tentacle / Agent**: Octopus Tentacle ≈ Jaws Deploy Agent. Outbound connection to the control plane.
- **Tags / Roles**: Octopus roles map onto Jaws Deploy tags. Same scoping mechanic.

## 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.

> **// Pricing model - The pricing shape is different - per-machine target rather than per-deployment-target-instance.**
> 
> For most teams this works out cheaper, especially with many small services on a shared set of machines. The pricing page has the current numbers; reach out if you're sizing a multi-hundred-target install.

## 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.