Skip to content
Slipwaydocs

Migration guides

Migrating a delivery system is mostly about concepts, not syntax. These guides map the nouns you already know to Slipway’s, show a worked conversion for each, and suggest a safe order of operations.

From Guide Typical effort
GitHub Actions Migrate from GitHub Actions Low: closest syntax, can run side by side
GitLab CI Migrate from GitLab CI Low to medium
Jenkins Migrate from Jenkins Medium to high: Groovy and plugins need rethinking
Octopus Deploy Migrate from Octopus Medium: the model maps directly, steps need conversion
Harness Migrate from Harness Medium

A safe general approach

Section titled “A safe general approach”
  1. Inventory. List pipelines, schedules, secrets, environments, approval rules and the integrations in use. Prune what is dead before you move it.
  2. Run side by side. Connect Slipway to the same repositories. Slipway discovers .slipway/*.yaml and ignores your existing CI files, so both can run on the same commits.
  3. Start with CI. Convert build and test pipelines first and compare results on real commits.
  4. Model deployments. Create services, environments, protection rules and lifecycles. Deploy a non-production environment with Slipway while production still uses the old path.
  5. Move secrets properly. Prefer OIDC federation or external references to copying long-lived secrets. Secrets in Slipway are write-only, so keep the source of truth in your secret manager.
  6. Cut over per service. Move production deployments service by service. Keep the old pipeline disabled but available for rollback for a release or two.
  7. Decommission. Remove old credentials, webhooks and runners.

Validate as you go

Section titled “Validate as you go”
Terminal window
slipway validate                      # schema and semantic checks, offline
slipway run trigger ci --branch main --watch

Use the pipeline reference for every key, and the expressions guide for conditions.

Things that do not map one to one

Section titled “Things that do not map one to one”
  • Marketplace actions, plugins and orbs. Replace with registry steps, docker:// image steps or plain run commands. GitHub Actions can run through the compatibility shim when it ships (phase 2).
  • Imperative scripting in the pipeline definition (Groovy, dynamic pipelines). Slipway pipelines are declarative YAML plus CEL. Move logic into scripts the steps call, or into matrices and conditions.
  • Per-target licensing assumptions. Slipway has none; revisit any workarounds you built to limit target counts.