Cookie settings

We use cookies

Necessary cookies keep the website working and store your choice. With your consent, we can also use functional cookies to remember the theme preference and analytics cookies to measure website usage.

You can accept optional cookies all at once, reject them, or choose individual categories. You can change your consent later; details are available in the Cookies Policy.

LaraDep Documentation

You are reading Common

Migration between managed and self-hosted

How to plan and execute mode migration safely: what to verify, what to extract between operating modes, and what to do after migration.

Mode migration

Moving between managed and self-hosted is more than toggling a setting; it is a controlled process migration. This page defines a standard that prevents chaos and supports repeatability.

Who should use this

It is suitable for teams that already run LaraDep in one mode and now need a mode change due to governance, cost, security, or required control level.

Before you start

  • Your current onboarding and operational process is documented,
  • your team understands both modes at documentation level (managed/self-hosted, first-run, runbook),
  • you have a clear decision maker for go/no-go.

Migration process (high level)

  1. Validate reason: why switching mode matters (costs, controls, compliance, team capacity).
  2. Map current state: workspaces, templates, roles, deployment history, critical applications.
  3. Prepare target process: configure onboarding, preflight checks, and runbook for the target mode.
  4. Pilot migration: choose one pilot environment, verify rollback options, and run first deployment.
  5. Finalize transition: transfer critical variables, confirm access policy, and publish updated operating standard.

Migration checklist

  • Is the mode change approved by a written decision?
  • Are new credential workflows and access patterns prepared?
  • Is onboarding configured and communicated?
  • Have risks and rollback steps been defined?
  • Has runbook and change evidence been updated after migration?

Common mistakes

  • Skipping a target-mode onboarding step.
  • Running migration on production without pilot first.
  • Missing role owners for launch and incident ownership.
  • Not updating runbook and workspace role rules after the migration.

Next steps

Cross-track links

To return to the original mode, repeat a controlled transition with documented onboarding and preflight checks in managed or self-hosted.

Next step: Review the concrete flow in managed getting started or self-hosted installation.

Subscribe to our Newsletter

Stay updated with our latest news and articles by subscribing to our newsletter.

Esc Close