Managed-to-self-hosted transition plan

Transition to self-hosted

Before changing modes, treat this as a project, not an ad-hoc switch. The goal is to preserve operational rhythm while gaining infrastructure control.

Page purpose

• Define a controlled plan that avoids downtime and accountability gaps during transition.
• Move decision ownership, access model and run standards before the actual switch.

Assumptions

• The current managed process is already stable (workspace model, run history, access flow).
• Transition intent is approved by product/infrastructure owner.
• A pilot scope and rollout communication plan exist.

Transition sequence

1. Clarify ownership — what moves to self-hosted responsibilities and who signs each change.
2. Inventory current state — servers, templates, run history, critical environments.
3. Prepare target runbook with self-hosted checks and response steps.
4. Run pilot on low-impact target and verify rollback path.
5. Execute cutover window with documented communication and rollback fallback.

Transition checklist

• Is the transition decision documented and approved?
• Are owners and approvers assigned for each pilot run?
• Are new access and secret handling flows prepared and tested?
• Is rollback plan clear and tested with evidence?

Common mistakes

• Underestimating process changes needed in target mode.
• Not preparing roles before moving credentials and ownership.
• Skipping pilot and attempting full cutover on first production environment.

Next steps

• After transition, open self-hosted mode landing page and validate the new entry flow.
• Reinforce governance in self-hosted governance.
• Set the recurring flow in self-hosted operations.
• For full process depth, keep mode migration guide updated.

Next step: Complete self-hosted onboarding checklist before your first production run.