Skip to main content
Warp’s configuration file, warp.yml, is located in Migration HQ’s config directory. Its default version is almost entirely commented out, with the exception of its version number:
For simple migrations, you probably won’t need to make any changes to warp.yml. However, with migrations that go beyond just moving code repositories from the source to the destination, you’ll find warp.yml useful for specifying additional details. For example, you can configure the visibility of migrated repositories or provide service connection IDs for Azure Pipelines rewiring. For example, if your migration process involves reconfiguring your Azure Pipelines to use GitHub repositories, you’ll need to make changes to the default warp.yml to provide additional required information, such as service connection IDs.

Repository Visibility

By default, Warp creates migrated repositories as private. If your organization uses GitHub Enterprise and you’d like migrated repositories to be visible to all organization members, you can set the target_repo_visibility option to "internal".
The target_repo_visibility field accepts two values:
  • "private" (default) — only users with explicit access can see the repository
  • "internal" — all members of your GitHub organization can see the repository
If the field is omitted or set to "private", Warp uses its default behavior and creates private repositories.
The "internal" visibility option requires a GitHub organization that supports internal repositories, such as GitHub Enterprise Cloud or GitHub Enterprise Server. This setting only affects new repositories created by Warp — it does not change the visibility of repositories that have already been migrated.

Advanced Configuration

Beyond basic setup, warp.yml supports several advanced features that let you customize your migration workflows.

Custom Scripts

Define custom automation scripts in your Migration HQ’s bin/ directory and execute them from issue comments using the /run slash command. Warp supports Bash, PowerShell, Ruby, and Python scripts with configurable arguments and optional Vault access. Learn more about Custom Scripts

Access Policies

Control who can execute slash commands and perform actions on backlog entry issues. Policies use an opt-in security model — when defined, only explicitly approved users and teams can perform the configured actions. Learn more about Access Policies

Custom Tasks

Add reusable checklists and task content to issues based on labels. Custom tasks are automatically injected into or removed from issue descriptions when matching labels are added or removed. Learn more about Custom Tasks