The Settings page is where you view the Project’s settings and configuration files, as well as perform tasks such as scanning the vault file, scanning the source organization for repositories, and deleting the Project.

The key parts of the Dashboard page are described in detail below.

Check Vault

The Check Vault button performs a test on your Project’s vault file, config/vault.age, to confirm that it contains the necessary data, namely:

• The personal access token for the Azure DevOps organization,

• The personal access token for the GitHub organization

When you click the Check Vault button, you’ll see this message...

...and when the process is complete, the results — information about the personal access tokens — will be displayed on the page’s Vault section (see below for details).

The Scan Sources button starts the process of scanning the Azure DevOps organization for repositories.

When you click the Scan Sources button, you’ll see this message...

...and when the process is complete, the results will be visible in a couple of places:

• In the Dashboard page’s Trends section, under Repositories Discovered. If this is the first time you scanned sources, this value will now contain the number of repositories Warp found in the Azure DevOps organization. If this is not time, this value will be updated to reflect any repositories that have been added since the last scan.

• In the project’s Migration HQ repository, where any repositories discovered since the last scan (or, if this is the first scan, all the repositories Warp was able to find) will be assigned an issue and appear as open issues on the Issues page.

The Configuration section shows information about the Project’s configuration files. It displays the following information:

• Warp.yml. The name of the project’s configuration file. You can view and edit this file in GitHub by clicking the button on the right side of this section.

• The partial hash of the Project’s vault file. This is the first 7 characters of the SHA hash of the Project’s vault file, config/vault.age, which contains the encrypted personal access tokens for the Project’s Azure DevOps and GitHub organizations. You can view this file in GitHub by clicking the partial hash.

• The button. Displays a reminder that you can edit warp.yml

The Destination section shows the GitHub organization where this Project’s repositories are to be migrated. It displays the following for the organization:

• The organization name. In the example above, it’s Hypotheticorp5678.

• The button. Displays a reminder that repositories from your sources will be migrated to this GitHub organization.

• The button. Click this to open a new browser to the organization’s Migration HQ repository.

The Vault section contains a list of the contents of the vault — the file containing the following personal access tokens that Warp uses to access the source and destination organizations in order to perform migrations.

Each item in this list represents a personal access token and contains the following:

• The name of the token’s platform. In the example above, the first token is for Azure DevOps and the second one is for GitHub.

• The organization for which the token was issued. In the example above, the first token is for the joey-ado-testing organization in Azure DevOps, and the second is for the Hypotheticorp5678 organization in GitHub.

• The unique identifier for the token.

The Danger Zone contains a single control: the Delete Project button, which deletes the Project.

As a safety precaution, clicking the Delete Project button causes this dialog box to appear:

Clicking the Confirm button will permanently delete the project. Use this feature with caution!

To facilitate the rewiring of Azure Pipelines, Warp automatically manages the sharing of for the .

Before rewiring Azure Pipelines, the service connection ID of the Azure Pipelines GitHub App must be configured in your Project's .

After configuring the service connection ID, Warp will automatically share the App's service connection with any Team Project where it is not already present.

When Azure Pipelines service connections are shared, Warp normalizes the name for your convenience to ensure it matches the name of your destination GitHub organization.

When a migration fails, use the Diagnose Migration skill to classify the root cause and post a structured remediation plan as a comment on the issue so your team knows exactly what went wrong and what to do next.

Migration failures can be opaque. A comment on a backlog issue might say "migration failed" and link to a runner log with hundreds of lines. The agent cuts through that noise by reading the evidence and surfacing only what matters.

How to Use It

1. Open the backlog issue in Migration HQ for the repository whose migration has failed.

2. Assign the issue to the Packfiles Warp agent with the instructions: "Diagnose the migration failure."

The agent categorizes the failure and posts a diagnosis comment directly on the issue.

The agent posts a comment on the issue with:

• Root cause — a single sentence stating what went wrong

• Remediation steps — a numbered list of specific actions to resolve the issue, including any Warp Vault changes, slash commands, or source system changes needed

• Retry instruction — the exact comment to post on the issue to retry the migration once remediation is complete

For most failure categories, the retry instruction is simply /migrate.

Description

Rewires an Azure DevOps Pipeline

View in Knowledge Base

Examples

With Named Arguments:

/rewire-pipeline --id <id> [--again]

With Positional Arguments:

/rewire-pipeline <id> [--again]

Arguments

--id (Required)

• The ID of the pipeline to rewire. This ID is shown in the Azure Pipelines table under the "Inventory" section of the Backlog Entry.

Value:

• Must be an integer number.

• The requested pipeline ID must match an ID shown in the Azure Pipelines table under the "Inventory" section of the Backlog Entry.

• When provided, the rewiring step will be performed again even if the pipeline has been rewired previously.

Value:

• None (boolean flag).

• Not required.

Rewires all Azure Pipelines associated with this repository.

• When provided, the rewiring step will be performed again for all pipelines, even if they have been rewired previously.

Value:

• None (boolean flag).

This document provides an overview of Warp's capabilities for migrating data from Azure DevOps Services to GitHub products.

Warp does not provide a migration path for Azure DevOps Server, only Azure DevOps Services. To migrate from Azure DevOps Server, you'll need to migrate to Azure DevOps Services first.

Repository Data

Warp includes built in support for data migrated by GitHub Enterprise Importer, including:

• Repository contents and Git history,

• Pull requests, including

  • User history,

  • Work item links, and

  • Attachments

• Branch policies

  • User-scoped branch policies and cross-repository branch policies are not included.

For specific information about the limitations on the types and size of data that can be migrated, refer to the page in this section.

Warp is capable of "rewiring" Azure Pipelines associated with repositories in your source Azure DevOps environment. Rewiring modifies the pipeline to associate it with the migrated copy of your repository in GitHub, rather than the original repository in Azure DevOps.

Rewiring enables a flexible path to GitHub adoption, enabling further migration processes (for instance, re-creating your existing pipelines with GitHub Actions) to proceed incrementally. Your team can enjoy the experience of hosting their code and development process on GitHub, while retaining the flexibility to continue using their existing pipelines until they're ready to replace them with Actions.

To facilitate the pipeline rewiring process, Warp will for the Azure Pipelines GitHub App.

If you have installed and connected the to your destination GitHub Organization, Warp can configure this integration for your migrated GitHub repositories with the slash command.

In addition to integrating Azure Boards, Warp is also capable of configuring GitHub's feature with the slash command.

When this integration is enabled, references to Azure Boards work items in issues, pull requests, commit messages, and release descriptions will automatically become clickable hyperlinks to the work item they reference.

Warp supports a variety of utility slash commands for Azure DevOps to automate common tasks like locking or disabling the original repository when a migration has been completed. These are listed in the of our slash command documentation.

Warp additionally supports slash commands for common post-migration tasks such as adding teams in GitHub to a repository with specific permissions. Documentation for these commands can be located in our .

Quickly refreshes the content of a Backlog Entry issue.

• Not required.

Warp is a next-generation solution for organizations seeking to adopt GitHub's products. It's designed by Packfiles to unlock speed, efficiency, and collaboration across the entire journey of migrating their data, development processes, and teams away from their original platform and onto the latest and greatest tools available.

Warp is composed of multiple components that all work together to coordinate your migration to GitHub.

The first component is the Warp GitHub App that can be installed directly from the GitHub Marketplace, with a fully self-service setup and configuration process that takes less time than going to lunch. And because Warp includes a built-in free trial, it's easy for teams to assess Warp's capabilities flexibly, on their own schedule, and with no upfront financial commitments.

The second component is the Warp Control Plane, a web application that communicates with the Warp GitHub App to perform work on your behalf. The control plane also provides reporting tools, migration team member management, and other admin tools.

The third component is the Warp Runner Agent that operates on GitHub runners in your environment either GitHub cloud or self-hosted. Runner Agents have all of the tools needed to perform migration operations on your behalf at your request and are coordinated by the control plane.

The fourth component is the Warp Vault, a desktop application that keeps your credentials encrypted while in the Migration HQ repository. Only the Runner Agent can decrypt your vault.age file at runtime (and only with the your vault master key stowed in ).

The last component is the Migration HQ repository that Warp automatically generates during the Warp installation and configuration process of your migration project. It's here in the Migration HQ repository that you can update the runtime configuration settings for Warp Runner Agents (see the file). Warp will create a (e.g., ADO Organization). From there you can plan, coordinate, and collaborate on your migration to GitHub.

The following diagram shows how these components fit together:

Warp has everything you need to achieve success on your migration journey, including:

• that are seamless, easy to use, mitigate risk, and respect your privacy,

• A fair, flexible, and transparent with no surprises,

• Built in and tools that make work visible, collaborative, and straightforward to plan,

• A that lets your team use the tools they already know and love, and

Changes the name of the destination GitHub repository

• The new name of the destination GitHub repository.

Value:

• A name to use for the GitHub repository. Special characters will be converted to conform to GitHub's requirements.

Overview

To facilitate the secure storage and retrieval of credentials required for migrations, Packfiles has designed a credential management application specifically for Warp known as the Vault, which protects your key material with end-to-end encryption.

When you use Warp, your credentials, along with the key used to encrypt the Vault that contains them, are never known to Packfiles. Your key material is encrypted and maintained exclusively in your GitHub environment, on infrastructure you control, and is never stored or processed on Packfiles' infrastructure or in a form accessible by our staff.

Packfiles expects customers to designate a trusted administrator in their organization with the responsibility of populating and maintaining the Vault's contents. Management of the contents of the Vault occurs on an administrator's local machine via a native application, and internet connectivity is not required or used for this process.

When the individual responsible for maintaining a Vault creates or modifies its contents, encryption is performed on their local machine with a randomly generated Master Key. This key is generated on the local machine of the individual managing the vault, is unique to each Project, and is never shared with Packfiles.

A Vault's contents, and the Master Key used for encryption, are maintained in custody of the customer. Customers are expected to maintain their Master Key in a secure location, such as a password manager, and in their Migration HQ repository's GitHub Actions secrets. Packfiles does not store or manage the Master Key of the Vault at any time.

The encrypted contents of the Vault are stored in a file located in your Migration HQ repository on GitHub. This follows GitHub's for storing large secrets on their platform.

The Vault uses the encryption library to provide its underlying cryptography. A detailed specification outlining the cryptographic primitives used by age is available .

In rare cases, installing Warp through the GitHub Marketplace may appear to succeed, but the app is never actually installed. This happens when the webhook GitHub sends to Packfiles is not delivered, meaning the installation signal is never received.

• GitHub Marketplace shows Warp as purchased or subscribed.

• No Migration HQ repository is created in your organization.

• Warp does not appear under your organization's installed GitHub Apps.

This Quickstart will guide you through the process of migrating repositories to GitHub using Warp. You’ll create a new project, set up your Vault, connect your source and GitHub organizations to Warp, and then migrate a repository to GitHub.

In this Quickstart, you will:

• Install the prerequisites.

• Create and configure a new project to migrate repositories to GitHub.

Disables the source Azure DevOps repository for all users.

• Not required.

Warp requires the Migration HQ repository's default branch to be named main. If your GitHub organization enforces a different default branch name (e.g., master, develop, trunk), the Warp Runner Agent will fail to execute.

• Runner Agent fails immediately after any Warp operation.

Before you can use Warp, you must install on your local computer.

Once you've installed Warp Vault, you can 🙌

Introduction

Packfiles designs security into the core of our products. As part of our mission to create the world's leading platform for enterprise-scale GitHub adoption, we cannot understate the importance of protecting our customers, their data, and the trust they've placed in us.

Packfiles' ultimate goal is to keep our customers safe. We achieve this with a combination of technologies, architectural choices, and best practices that work together to deliver a user experience that is as approachable and transparent as it is maximally secure.

Key security features in Warp, such as customer-owned credential management, private compute, and data privacy can't be disabled or configured improperly by mistake. Because these features are inherently part of Warp's design, customers don't need to perform extensive or complicated configurations to enjoy the benefits of these protections. They're always present and active for Projects of any size.

Our Principles

At Packfiles, we believe security isn't just a feature of our products: it defines them. That's why we always start our design process by thinking about our values and principles.

We believe:

Effective security is designed to be accessible.

World-class security technologies are transparent and easy to use. Great security controls shouldn't require advanced expertise or assumed knowledge on behalf of the customer to be effective. Instead, best practices should be distilled into product design at a fundamental level.

Rather than forcing customers to learn and apply a complicated set of security settings or configuration, we believe that the product itself should be their guide, and it should work in a way that guarantees their success.

In other words, "secure by design" is better than "secure by default", or even "secure with a bit of extra configuration". Opinionated, secure defaults that work transparently on behalf of customers raise the bar for everyone.

Customers shouldn't have to pay a premium for great security. Rather than segmenting our customers into security haves and have-nots, we believe the most critical security protections should come standard across all of our products, in a polished form that adheres to our accessibility principle.

At Packfiles, we've known from the start that an excellent security architecture is the first and most important thing to get right. That's why we take a long-term view of our security technology and architectural choices.

A strong security foundation is essential to enabling core experiences, developing innovative new features, and creating great experiences for our users. When a system is carefully designed with security as a core primitive, those properties and guarantees extend seamlessly throughout.

Our unique perspective on security isn't just about building great products like Warp. We hope to push the industry forward in designing great solutions that respect customers' right to security and privacy. Because executing on those principles while maintaining a high level of polish and usability isn't just possible, it's something that customers can and should expect.

We're committed to helping protect our customers with leading security and privacy technologies, comprehensive security and compliance programs, and a dedicated security team that supports all Packfiles products.

Packfiles understands that our own security posture is critical in protecting our customers. That's why we maintain strict controls across our workplace, development processes, and infrastructure. To ensure these controls are effective, we regularly engage with third-party security firms to perform thorough, comprehensive audits and security testing.

The Packfiles security team can be contacted at .

This document provides an overview of Warp's capabilities for migrating data from Bitbucket Server to GitHub products.

Warp includes built in support for data migrated by GitHub Enterprise Importer, including:

• Repository contents and Git history,

• Pull requests, including

  • Comments,

  • Pull request reviews,

  • Pull request review comments (both at the file and line level)

  • Required reviewers, and

  • Attachments

For specific information about the limitations on the types and size of data that can be migrated, refer to the page in this section.

Warp supports a variety of utility slash commands for common post-migration tasks such as adding teams in GitHub to a repository with specific permissions. Documentation for these commands can be located in our .

The Warp CLI gives you access to certain features of Warp directly from your terminal. In particular, it allows you to work with the credentials you've stored in Warp Vault from the command line.

Before you can use Warp CLI, you must have the GitHub CLI installed on your machine.

Install the GitHub CLI

First, see if the GitHub CLI is installed on your computer.

Open your terminal application (on Windows, it’s Windows PowerShell or Command Prompt; on macOS and Linux, the default terminal is named Terminal).

Enter the following command:

gh --version

If the GitHub CLI is installed, you’ll see a message showing its version number and the URL for its release notes. Here’s an example:

gh version 2.63.1 (2024-12-03)
https://github.com/cli/cli/releases/tag/v2.63.1

If you see an error message instead, you’ll need to install the GitHub CLI. Go to the GitHub CLI page and follow the instructions there.

Install the Warp CLI Extension

Once you’ve confirmed that the GitHub CLI is installed on your computer, enter the following command to install the Warp command-line extension:

gh extension install packfiles/gh-warp

Confirm that the Warp command-line extension is installed by running the following command in a terminal window:

You should see this response:

Description

Adds a given team to the migrated repository in GitHub with the specified permissions.

View in Knowledge Base

Examples

With Named Arguments:

/add-team --team-name <team-name> --permission <permission>

With Positional Arguments:

/add-team <team-name> <permission> 

Arguments

--team-name (Required)

• The slug of the team to add to the repository. Must be the name of a team in this GitHub organization.

Value:

--permission (Optional)

• The permission to grant the team on the migrated repository. We accept the following permissions to be set: pull, triage, push, maintain, admin. You can also specify a custom repository role name, if this organization has defined any. If no permission is specified, the team's permission attribute will be used to determine what permission to grant the team on the migrated repository.

Value:

• Must be one of the following: pull, triage, push, maintain, admin.

• The user who invokes this command must be a GitHub organization administrator.

Packfiles takes the security of our products and protection of our customers extremely seriously.

To prevent tampering, all Warp Vault releases are cryptographically signed using industry-standard techniques. To verify the authenticity and integrity of your Warp Vault download, we recommend following the steps below for your host operating system.

Jump to instructions for:

When you run a migration, Warp uses GitHub's migration APIs to move repository data from your source platform to GitHub. This page covers the reasons a migration can fail and how to resolve them.

• Migration action fails in the Actions tab of Migration HQ.

• Warp posts an error comment on the repository's issue in Migration HQ.

• The issue comment includes a Troubleshoot section with a link to runner logs.

The Bitbucket Server credential type stores the credentials and configuration associated with the Bitbucket Server instance from which you're migrating data with Warp.

To configure a Bitbucket Server credential, you'll need:

• A Username and Password for a Bitbucket Server account with Admin or Super Admin permissions,

• At least one storage bucket, and

• SFTP or SMB access to the Bitbucket Server instance.

The Migration HQ repository — the HQ is short for “headquarters” — is Warp’s primary user interface. When you create a Project, Warp generates a Migration HQ repository for that project; it’s the “control panel” that you use to manage the migration process.

You will use the page of Migration HQ most often. Warp uses this page for the list of migrations. For each repository that Warp finds in the sources you provide (e.g. Azure DevOps), it creates an issue representing that repository. Each issue acts as the user interface for managing the migration of its repository. You enter Warp commands in the issue’s Comments section, including the command to migrate the issue from the source to GitHub.

You also might these Migration HQ pages on occasion:

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:

# Welcome to your Warp configuration file!

# To learn more about the use and purpose of this file,
# refer to our documentation at https://pack.fm/about-warp-yml

version: "1.0"

####
# Repository Visibility
####
# Controls the visibility of repositories created by Warp during migration.
#
# Options:
#   - "private" (default): Repositories are only visible to users with explicit access
#   - "internal": Repositories are visible to all members of your GitHub organization
#
# Note: This setting only affects NEW repositories created by Warp. It does not
# modify the visibility of existing repositories.
#
# Uncomment target_repo_visibility and set to "internal" to make migrated repositories visible to
# your entire GitHub enterprise organization:
#
# target_repo_visibility: "internal"

####
# Azure Pipelines Rewiring
####
# To configure the service connection ID of the Azure Pipelines GitHub App,
# which is used to rewire Azure Pipelines to point at GitHub, apply the
# configuration below.

# azure_devops:
#   global: # For a global default
#     azure_pipelines_github_app_service_connection_id: <your Azure Pipelines GitHub App Service Connection ID>
#   my-org-name: # You can also supply organization-specific defaults
#     azure_pipelines_github_app_service_connection_id: <your Azure Pipelines GitHub App Service Connection ID>

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.

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

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.

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.

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.

The Issues page of Migration HQ is the list of the Project’s migrations. For each repository that Warp finds in the sources you provide (e.g. Azure DevOps), it creates an issue representing that repository:

Viewing Open Issues

When you open Migration HQ’s Issues page, you will see the open issues list, which GitHub displays by default. Items in the open issues list correspond to repositories that have not yet been migrated:

To view an open issue, click its name. You will be taken to its issue page, which will display its details, and which you can use to issue commands, including the command to start a migration.

You can filter Migration HQ issues in the same ways you would in a standard GitHub repository: by open/closed status, author, label, and so on.

Viewing Closed Issues

Items in the closed issues list correspond to repositories that have either been migrated or ignored:

To view an closed issue, click its name. You will be taken to its issue page, which will display its details, including information about the migration.

There are two ways to close an open issue in Migration HQ:

1. Automatically. After a successful migration of a repository to GitHub, Warp changes the status of its corresponding issue to Closed. The issue will move from the open issues list to the closed issues list, and the Closed indicator will appear below the title of its page:\
2. Manually. You can close one or more issues manually by checking their boxes in the open issues list and selecting either Completed or Not Planned from the Mark as menu:\

   You can also manually close an issue on its own page — see for details. By closing an issue manually, you are choosing to

• It moves the issue to the closed issues list.

• Warp will ignore any slash commands (commands that you issue to Warp) entered into the issue’s comments and it will not update the issue’s content.

If you decided that you need to re-migrate a repository, you can do so by re-opening its issue. You can re-open one or more issues by checking their boxes in the closed issues list and selecting Open from the Mark as menu:

Re-opening an issue has these effects:

• It moves the issue to the open issues list.

• Warp will once again pay attention to slash commands entered into the issue’s comments and will update the issue’s content as its status changes.

The Packfiles GitHub Copilot Agent is an AI agent built into the Packfiles Warp app that helps you plan, execute, and troubleshoot migrations without leaving GitHub.

Instead of consulting documentation, manually reviewing repository inventories, or reading runner logs to decode a failure, you can work directly with the agent in the places where migration work already happens: the Migration HQ Agents tab, a backlog issue, or a pull request.

Before using the Packfiles GitHub Copilot Agent, ensure that:

• Your Migration HQ repository has been initialized by Warp and a source scan has completed successfully, so that backlog issues have been created for your repositories

Organizations are increasingly concerned about the collection, storage, and processing of their data, and Packfiles is no exception.

Just as Packfiles maintains strong core values around security, we do the same with data privacy. Packfiles strives to ensure customers are protected by comprehensively minimizing our exposure to privileged information or administrative access to the greatest extent possible. That's why we've taken steps to ensure our products respect your organization's right to privacy and transparency in how your data is processed.

The design of Warp's and techniques guarantee that any processing of your private data (source code, commit history, credentials, and so on) occurs in an environment you own and on infrastructure you control. Combined with our strong commitments and controls around privacy and data residency, we aim to categorically mitigate risks associated with the storage and processing of your organization's information.

All infrastructure and persistent storage related to Warp's Control Plane is hosted in the eu-west-1 region of Amazon Web Services. This AWS region is geographically located in Dublin, Ireland.

The Warp Control Plane maintains an inventory of repositories and associated resources discovered in your environment to provide you with migration services. This index is used exclusively to render migration services to customers. It includes only information about the existence and location of resources in your environment, but does not store their contents.

Warp Vault is Warp's end-to-end encrypted credential management solution. It's a native application that transparently handles encryption and storage for you, with a friendly interface that makes it easy to securely configure, test, validate, and manage the credentials associated with your Warp installation.

You'll set up Warp Vault as part of the Warp installation process. For more details, refer to .

To install or update Warp Vault on your local machine, review the instructions provided in .

For detailed information about how Warp Vault keeps your credentials safe and secure, review the page in the section.

The Azure Blob Storage credential type stores the Connection String associated with an Azure Blob Storage bucket.

To configure an Azure Blob Storage credential, you will need to provide an Azure Blob Storage Connection String. For more information about generating these, refer to the Azure documentation.

Slash commands in this section are supported for Azure DevOps repositories.

To learn more about Warp's support for Azure DevOps, refer our documentation in the migrations section.

Description

Makes the source Azure DevOps repository read-only for all users.

View in Knowledge Base

Example

/lock-ado-repo

Authorization

• Not required.

Access policies let you control who can run Warp commands in your Migration HQ repository. You configure them in the policies section of your warp.yml file.

How Policies Work

Warp uses an opt-in security model. By default — when no policies are defined — all organization members have full access to run any command. Once you define a policy, Warp switches to a restrictive mode where only the users and teams you specify are allowed to act.

This means:

• No policies defined: All organization members can run all commands.

• Policies defined: Only explicitly approved users and teams can run commands that match a policy.

There are two types of policies: issue policies and slash command policies. You can use them independently or together.

Issue policies control who can run slash commands on Backlog Issues based on the issue's labels. Define them under policies.issues in your warp.yml.

1. When a user runs a command on an issue, Warp checks the issue's labels against your configured policies.

2. If any labels match, only the users and teams listed in matching policies can run the command.

3. If no labels match any issue policy, then no access is granted to that issue by issue policies; the command can still run only if a matching slash command policy explicitly allows it.

Each issue policy has:

• A unique identifier — an internal reference name for the policy.

• labels (optional) — a list of issue labels that trigger this policy. If omitted, the policy applies globally to all issues.

• teams (optional) — GitHub team slugs granted access.

When multiple policies match an issue (through overlapping labels or a global policy), their allowed users and teams are combined — a user permitted by any matching policy is allowed.

Restrict commands on issues labeled with a specific Azure DevOps (ADO) team to only members of the corresponding GitHub team:

In this example, only members of the catball-inc-team GitHub team and the users chaserx and johndoe can run commands on issues that have the ado:team:catball-inc label.

Create a policy without labels to grant access across all issues, regardless of their labels:

This gives the release-engineering and dev-ops teams, along with admin-user, access to run commands on every issue.

You can define both label-specific and global policies. When an issue is evaluated, Warp combines the allowed users and teams from all matching policies — including any global policy — to determine access.

For an issue labeled ado:team:platform, both the release-engineering team (from the global policy) and the platform-engineering team and team-lead user (from the label-specific policy) are allowed.

Slash command policies control access to specific commands across all issues. Define them under policies.slash_commands in your warp.yml.

Important: When you define any slash command policy, Warp denies access to all commands by default. Only the commands you explicitly configure are available.

Each slash command policy is keyed by the command name (starting with /) and specifies which teams and users can run it.

Only members of release-engineering and the user chaserx can run /migrate. All other slash commands are denied because a slash command policy is defined.

Each command has its own access list. Commands not listed here are unavailable when any slash command policy is defined.

When both issue policies and slash command policies are defined, Warp evaluates them in order:

1. Issue policies are evaluated first based on the issue's labels.

2. Slash command policies are evaluated second based on the command name.

3. Access is granted if either policy allows the user.

This means a user who is permitted by an issue policy can run a command even if they are not listed in the slash command policy for that command, and vice versa.

• Policy identifiers must be unique. Each issue policy needs a distinct key (e.g., onboarding, global_access). Duplicate keys will cause one to overwrite the other.

• Team slugs and usernames are case-sensitive. Make sure they exactly match the GitHub team slug and username. For example, Release-Engineering is not the same as release-engineering.

Here is a full warp.yml demonstrating both issue and slash command policies:

Overview

Custom tasks let you define reusable checklists in warp.yml that Warp automatically injects into issue descriptions. Tasks can target specific issues by label, or appear on every issue in your project.

Custom tasks are configured in your project's warp.yml file. For general information about warp.yml, see Warp.yml.

Configuration

Each custom task is defined under the custom_tasks block in warp.yml. A task entry requires:

• A unique identifier (the YAML key) — used internally to reference the task

• title — the display heading that appears in the issue body

• body — the task content, supporting full Markdown including checklists

• labels (optional) — an array of label names that control when this task appears

When a task includes a labels array, it only appears on issues that have at least one of those labels assigned. Label matching is case-insensitive.

In this example, the checklist appears when either the migration or kickoff label is added to an issue.

Tasks defined without a labels key appear on every issue in the project. These are useful for checklists that apply universally, such as compliance or security reviews.

Warp automatically manages custom task content in issue descriptions:

1. Adding a label — When you add a label to an issue that matches a custom task's labels configuration, Warp updates the issue body to include the matching task content.

2. Removing a label — When you remove a label, Warp removes the corresponding task content from the issue body.

Custom tasks appear in the issue body under a Tasks From Your Organization heading, with each task rendered as a subsection using its title as the heading and its body content displayed verbatim (including any Markdown checklists).

Important: Warp manages the issue body automatically. If you manually edit the issue description, your changes may be overwritten the next time labels are added to or removed from that issue. This ensures that custom task content stays synchronized with the issue's labels.

You can define multiple tasks with different label triggers. This example combines label-specific and global tasks:

This section covers common issues you may encounter while using Warp and how to resolve them.

Quick Reference

Inventory scans can fail when the credentials in your vault are expired, have insufficient permissions, or when the vault file is outdated. A GitHub outage can also prevent scans from running.

For detailed causes and resolution steps, see .

Migrations can fail for many of the same reasons as inventory scans — expired or under-scoped credentials, outdated vault files, and GitHub outages. Additionally, repository size limitations and invalid destination repository names can cause migration failures.

For detailed causes and resolution steps, see .

Warp requires the Migration HQ repository's default branch to be named main. Organizations with a different default branch naming policy will experience runner failures until the branch is renamed.

For the resolution steps, see .

In rare cases, installing Warp through the GitHub Marketplace may appear to succeed but the app is never installed. A direct installation link is available as a workaround.

For the resolution steps, see .

Description

Configures an integration between Azure Boards and the destination GitHub repository.

View in Knowledge Base

Example

/integrate-boards

Authorization

• Not required.

Each of the credential providers listed in this section can be configured using Warp Vault:

• Amazon S3 Storage,

• Azure Blob Storage,

• Azure DevOps Services,

• ,

The Dashboard page provides a high-level overview of the Project’s size and progress. It also provides a link to the Project’s Migration HQ repository.

The key parts of the Dashboard page are described in detail below.

The Migration HQ button takes you to the Migration HQ repository for this Project. This repository acts as the control panel for the migration process.

The Trends section provides the following quantitative information about your Project:

Packfiles was founded by a team of passionate experts with a unique perspective on developer technologies. We've helped countless organizations around the world adopt efficient development practices, streamline their processes, and get the most out of the best tools available, particularly GitHub.

You may wonder why Warp exclusively supports GitHub products as the destination for migrated data. The answer is simple: First, we believe GitHub's offerings are best in class, bar none. And second, we have a long history of working within, around, and across GitHub's business. Our team's collective experience represents longtime users of the platform, former GitHub employees, world-class services partners, and vendors of developer tools that integrate with GitHub.

This section covers the key concepts of our approach to GitHub adoption that we've applied successfully for organizations around the world and across industries. You'll understand the principles, design philosophy, and rationale that have influenced the design of Warp, and how they work together to create an experience that empowers your organization to efficiently and effectively tackle the challenge of GitHub adoption.

We believe that:

Warp currently supports migrating data from and .

Warp currently supports migration to the following GitHub products:

Support for these additional sources will arrive this year:

Warp automatically generates four labels for each issue it creates, which specify:

1. The repository’s source organization. In the examples above, the source organization is joey-ado-testing in Azure DevOps.

2. The repository’s source team. In the examples above, the source team is first project in Azure DevOps.

Although we strive to increase the fidelity and richness of Warp's migration capabilities, there are some limitations to the types of data that can be migrated under certain conditions.

Currently, the following data is not migrated from Bitbucket Server.

• Personal repositories owned by individual users,

• Branch permissions,

Warp transforms GitHub migration from a tedious, error-prone, manual process on the command line into a smooth, automated, straightforward experience managed within GitHub.

Warp is a rapidly evolving product, with constant updates and improvements. As a result, you’ll find that its documentation is constantly being updated as well.

Here’s a quick guide If you’re new to Warp, we think you’ll find these sections helpful:

• — A more detailed description of Warp, what it does, and its key features.

• — A complete step-by-step guide to performing a migration using Warp, from installing the local application on your computer to confirming that your migration was successful. If you have a free trial of Warp , you’ll definitely want to check out the Quickstart.

{
   "data" : {
      "created_at" : "0001-01-01T00:00:00Z",
      "destination_type" : "ghec | ghec_emu | ghec_dr",
      "expiration_days" : 0,
      "ghec_dr_domain" : "",
      "organization_slug" : "",
      "pat" : "",
      "updated_at" : "0001-01-01T00:00:00Z",
      "uuid" : "d469e3f3-1937-4a1c-8fc2-2237a4efdf13"
   },
   "type" : "GitHubDestination",
   "uuid" : "d469e3f3-1937-4a1c-8fc2-2237a4efdf13"
}

Example Query

gh warp vault get '(type:GitHubDestination).pat'

When you use Warp to invoke any process that operates on your source environment, it's carried out by the Warp Runner Agent. The Warp Runner Agent is the "muscle" of our migration platform, and it's the only component of Warp responsible for invoking migration tools and connecting to your source environment.

The Warp Runner Agent executes exclusively in your environment, on infrastructure you own and control. Although Packfiles is responsible for developing, packaging, and distributing the software that constitutes the Agent, the Agent itself is never executed on our infrastructure. This reduces potential attack surface considerably, providing an exceptional level of isolation and ensuring that Packfiles and its staff cannot directly access your source environment, your credentials, or otherwise impact the confidentiality or integrity of the data you're migrating.

Lifecycle & Technical Description

The Runner Agent communicates with Warp's Control Plane to exchange status information and coordinate its work while minimizing the exposure of data about your environment.

Processes carried out by the Warp Runner Agent follow a set lifecycle:

• When a job is scheduled on behalf of a Warp customer, the Control Plane dispatches a GitHub Actions workflow maintained in the customer's Migration HQ repository.

• GitHub Actions executes the workflow, which calls Packfiles' action and supplies the following inputs:

  • An ephemeral API token for the Warp Control Plane, whose permissions are restricted specifically to that job,

  • A checked-out clone of the Migration HQ repository's Git contents, and

  • The Credential Vault master key, which is maintained in the Migration HQ repository's GitHub Actions secrets.

• The runner-agent action retrieves the Warp Runner Agent container image from Packfiles' container registry, and initializes it with the data mentioned in the previous step.

• The Warp Runner Agent container is started, and the Agent is initialized by a supervisor process. This process exchanges metadata about the container's environment and retrieves information about the job to be performed via authenticated requests to Warp's Control Plane API.

• The Agent carries out the requested job, and reports status information to the Control Plane over the course of that job's lifecycle.

• Upon completion of the job, the Warp Runner Agent reports its status to the Control Plane, and uploads its logs and artifacts to GitHub Actions Artifacts.

  • As an additional layer of security, all logs and artifacts produced by the Agent are scanned by a scrubber process to prevent the by its subprocesses.

• The ephemeral API token for the job is revoked upon successful completion of the job.

  • As a failsafe measure, the token is purged if the supervisor process crashes, or when the token's lifespan reaches its limit.

Description

Executes a custom script defined in your project's warp.yml configuration file. Scripts run on a GitHub Actions runner agent and results are posted as a comment on the issue.

View in Knowledge Base

Examples

Basic (no arguments):

/run notify_team

With Arguments:

/run update_wiki --script_args wiki_page=migrations status=in_progress owner=chaserx

With Boolean Flags:

/run cleanup --script_args target=logs dry_run

Arguments

script_id (Required)

• The identifier of the script to run, as defined in your project's warp.yml configuration under the scripts: key.

Value:

• Must match a script identifier configured in warp.yml.

• Arguments to pass to the script. Provide space-separated key=value pairs after the --script_args flag. Boolean flags (without a value) are set to "true".

Value:

• Space-separated key=value pairs.

• Arguments must match those defined in the script's arguments configuration in warp.yml. Unknown arguments are rejected.

• Required arguments (as configured in warp.yml) must be provided.

• When script policies are configured in warp.yml under policies.scripts, only the listed users and teams can execute the script.

• When no script policies are defined, all members of the repository’s organization can run all scripts.

See for configuration details.

Packfiles' Partner Network represents a globally distributed, distinguished cohort of skilled service providers who have vetted expertise with Warp and GitHub migrations. Their depth of experience supporting organizations through the process of adopting GitHub platforms is invaluable for those seeking expert guidance and hands-on support.

If you're considering expert support as part of your migration plan, or would like to explore your options, contact our team here or at hello@packfiles.io.

The Capacity page displays your Project’s capacity — the number of migrations that have been allocated to your Project — and related statistics. Each migration costs one unit of capacity. You can also purchase more capacity for the Project account on this page.

The key parts of the Capacity page are described in detail below.

The Billing Portal button takes you to the Warp Billing Portal, where you can do the following:

• View and manage your payment methods.

The Amazon S3 Storage credential type stores the AWS credentials associated with an Amazon S3 bucket.

To configure an Amazon S3 Storage credential, you will need to provide:

• The S3 bucket name,

• An AWS Access Key,

• An AWS Secret Key, and

An inventory scan is how Warp discovers repositories in your source platform. When you run a scan, Warp's Runner Agent connects to your source (Azure DevOps, Bitbucket Server, etc.) using the credentials stored in your vault and retrieves a list of repositories. This page covers the reasons an inventory scan can fail and how to resolve them.

• Scan action fails in the Actions tab of Migration HQ.

• Scan completes but no repositories appear in the Issues tab.

• Error messages in runner logs referencing authentication or authorization.

Warp organizes migrations into Projects. In Warp, a Project is an object for managing a migration engagement — that is, an event where you will be migrating repositories to GitHub. Projects allow you to view and manage a set of migrations as a distinct operation with its own team, timeline, and budget.

Projects are one of Warp’s ways to make migrations more manageable:

• If you have a small collection of repositories to migrate, you might choose to perform their migrations in a single engagement and use a single project.

• If you are performing migrations for multiple clients, you might choose to use one project for each client.

Here are some tips and tricks on how to use, navigate, and contribute to this knowledge base effectively.

The search bar at the top right of the page allows you to search this knowledge base's content. Additionally, this search function supports natural language. Queries provided in natural language will present a summary answer with cross-references to knowledge base articles.

Every page in this knowledge base is stored in a . Individual pages have a dedicated link to their source content on GitHub, so it's easy to propose changes.

We're proud to offer comprehensive support options as a first-class feature of Warp, with flexible choices for a variety of needs and use cases.

Packfiles' represents a globally distributed, distinguished cohort of skilled service providers who have vetted expertise with Warp and GitHub migrations. Their depth of experience supporting organizations through the process of adopting GitHub platforms is invaluable for those seeking expert guidance and hands-on support.

For support inquiries related to Warp itself, the Packfiles team is here to help. Warp's product support channels can be accessed via the Support tab of your Project.

We're always looking for ways to improve your experience with Warp. Thoughts, kudos, frustrations, and feature requests are always welcome, and can be shared with the Packfiles team via and throughout Warp.

This knowledge base is an authoritative, comprehensive resource for everything Packfiles and Warp provides. We strive to write and maintain high-quality documentation, and the

Before we talk about Warpspaces, let’s review GitHub Codespaces. A Codespace is a fully configured development environment that runs in the cloud, accessible via a web browser or VS Code, and hosted by GitHub. Every Codespace comes with common tools such as git, Python, Node.js, and other programming languages pre-installed. Codespaces can also be customized with other packages.

Warpspaces are Codespaces that have been customized with useful tools for performing migrations, including:

• GitHub’s CLI tools

• GitHub’s migration tools

Every new Migration Project in Warp starts in our Free Trial, which gives you a free, no-strings-attached 14-day opportunity to migrate up to 25 repositories with Warp.

No matter the size or scale of your overall Migration Project, you are not required to make a purchase or provide billing information to use Warp's Free Trial.

When your Project is in the Free Trial, the following limits apply:

• Your trial lasts 14 days from the date of installation,

• We'll create a maximum of 25 Issues, and

Although we strive to increase the fidelity and richness of Warp's migration capabilities, there are some limitations to the types of data that can be migrated under certain conditions.

• No single Git commit can exceed 2 gigabytes in size.

• Git references may not exceed 255 bytes in size.

• No single file in the source repository can exceed 400 megabytes

Under the hood, Warp Vault stores credentials in a versioned schema format, so they're easy to work with in scripts.

When you configure credentials in Warp Vault's graphical interface, they're stored as JSON in an encrypted container. To access these credentials in scripts, you can use Warp Vault's Query Interface to locate and extract properties of you credentials based on their schema.

This section provides schema references for each of Warp Vault's supported credential types to help you write VaultQL queries to extract any properties you might need in scripts or other parts of your workflow.

Description

Summons documentation for any available slash command.

View in Knowledge Base

Examples

With Named Arguments:

With Positional Arguments:

Arguments

--command-name (Optional)

• The name of a command you'd like to display documentation for.

Value:

• The name of a slash command, with or without the leading /.

Authorization

• Not required.

{
   "data" : {
      "created_at" : "0001-01-01T00:00:00Z",
      "credentials" : {
         "password" : "",
         "username" : ""
      },
      "disable_ssl_verification" : false,
      "host_configuration" : {
         "archive_download_host" : "",
         "shared_home_directory" : "",
         "smb_domain" : "",
         "smb_password" : "",
         "smb_username" : "",
         "ssh_key" : "",
         "ssh_port" : 0,
         "ssh_username" : ""
      },
      "host_platform" : "",
      "storage_configuration" : {
         "migration_storage_provider_uuid" : "",
         "migration_storage_type" : ""
      },
      "updated_at" : "0001-01-01T00:00:00Z",
      "url" : "",
      "uuid" : "d27cb06d-0a7d-4ffa-8d9a-85ec646ecd35"
   },
   "type" : "BitbucketServer",
   "uuid" : "d27cb06d-0a7d-4ffa-8d9a-85ec646ecd35"
}

Example Query

gh warp vault get '(type:BitbucketServer).credentials.password'

At Packfiles, we're passionate about treating our customers with care and respect. Our values define everything from the core experience and overall design of Warp, to our clear and intentional approach to billing and licensing.

We've designed Warp to provide our customers with an unprecedented level of transparency and control over their migration process. To achieve this, we've created a simple and flexible volume pricing model that puts customers in control. We refer to this model as Capacity.

About Capacity

Capacity is Warp's unit of account for successful distinct migrations.

Capacity is recorded in your Project's Meter. When you use Warp to migrate a repository from your Source environments to your destination on GitHub, you'll consume units of Capacity that are debited against your Project's Meter.

Your Project's Meter is credited with a free trial allotment of Capacity when it's first created. Additional Capacity is credited any time you purchase one or more Boxes.

Capacity purchased on behalf of your Project is available for consumption immediately after your payment is processed. Purchased Capacity associated with your Project does not expire.

Capacity is sold in prepackaged bundles known as Boxes. Boxes provide you with flexibility and control over licensing for your Project, giving you the option to commit to adopting Warp in incremental phases, or fully up front.

You can purchase Boxes from the Capacity page of your Project at any time.

Boxes are available in the following sizes:

Custom pricing is available for organizations planning very large migrations. To explore large-scale pricing options, .

Your Project's Meter is only debited for the repositories you choose to migrate, and you will only be billed for the first successful, distinct migration.

If you migrate the same repository successfully multiple times, you'll only be billed for the first successful migration. Similarly, if you attempt to migrate a repository but are unsuccessful, you will only be billed once for the first time the migration succeeds.

The Validate Configuration skill reads your config/warp.yml, validates it against Warp's configuration schema, and posts a structured findings report so you can merge configuration changes with confidence.

Warp's configuration file supports a range of settings: repository visibility, Azure Pipelines rewiring, access policies, custom task checklists, and scripts. As configurations grow more complex, it becomes easy to introduce errors that only surface at runtime. The agent catches those issues before they do.

How to Use It

1. Open a pull request that modifies config/warp.yml.

2. Post a comment on the pull request mentioning the Packfiles Warp agent and ask it to "validate the configuration."

"@packfiles-warp Can you validate the config changes in this PR?"

The agent reads the current contents of config/warp.yml from the pull request's branch, validates it, and posts a review comment on the pull request with its findings.

Each finding in the report is assigned one of three severity levels:

• ✅ Valid — the configuration is correct and there are no concerns

• ⚠️ Warning — the configuration is syntactically valid, but has implications worth reviewing before merging

• ❌ Error — the configuration is incorrect or will prevent Warp from working as intended; must be fixed before merging

Beyond schema validation, the agent flags configuration changes that could have security implications.

These are surfaced as warnings rather than errors, since they may be intentional. The report explains the implication so you can make an informed decision before merging.

• — Full configuration reference

• — How to configure slash command and issue policies

• — How to define label-triggered checklists

• — How to register and run automation scripts

The Team page is a list of the members of the Team — the people authorized to have access to the project.

The key parts of the Dashboard page are described in detail below.

The Add Members button starts the process of adding one or more people to the Team.

Clicking the Add Members button opens this dialog:

To invite people to join your Team, you must provide the following information for each person:

The Azure DevOps credential type stores the Personal Access Token and configuration associated with the Azure DevOps Organization(s) from which you're migrating data with Warp.

To configure an Azure DevOps credential, you'll need:

• A Personal Access Token (Global or Single Organization),

• Your Organization Slug (if you're not using a Global token), and

• The number of days until your token expires (from the day of issue)

Description

Configures Autolink References in the destination GitHub repository so that references to Azure Boards work items become clickable hyperlinks.

View in Knowledge Base

Example

Authorization

• Not required.

Code Examples

TypeScript

JavaScript

Ruby

Go

Rust

Objective

At last, it’s time to migrate a repository to GitHub! You’ll do this entirely in Migration HQ.

At the end of this section, you will have a repository that has been migrated from its source and into your GitHub organization.

Select a Repository to Migrate

After scanning your source for repositories, you navigated to Migration HQ’s Issues page, where you saw the open issues list:

Each item in the open issues list represents a repository to be migrated. After migrating a repository, Warp automatically closes its issue, which moves it to the closed issues list.

Let’s migrate a repository! For this example, we’ll migrate TailwindTraders-Website, whose issue is at the top of the open issues list pictured above.

🛠️ In your open issues list, click on the issue for the repository you want to migrate.

The page for the issue will appear:

🛠️ Scroll to the comments section at the bottom of the issue page:

You issue commands to Warp in comments by using slash commands — commands that begin with the slash (/) character. One of these commands is /migrate, which tells Warp to migrate the repository represented by this issue.

🛠️ Enter the slash command /migrate into the comment box and click the Comment button.

A couple of seconds later, Warp will confirm that it received the command. The comments section will look like this:

Warp — which will have the user name packfiles-warp — always provides a response to your commands as a follow-up comment. In the example above, it’s notifying you that the migration process has begun.

It typically takes a few minutes to perform a migration. Let’s use this time to watch the migration’s progress.

🛠️ Switch to Migration HQ’s Actions page by clicking the Actions tab:

You’ll see a new Warp Runner Agent running the workflow that performs the migration:

🛠️ Click on the Runner Agent to get a closer look at what it’s doing.

You’ll see the Runner Agent’s page:

Let’s get an even closer look at what the Runner Agent is doing.

🛠️ Click on the job that the Runner Agent is running — it’s any of the objects onscreen labeled Packfiles Warp Runner Agent that has a spinning yellow icon beside it:

You’ll go to a page where you can see the log files that the job is generating in real time:

A couple of minutes later, the migration will be complete. You’ll know this has happened when the Runner Agent’s icon changes from spinning and yellow to a static green checkmark:

🛠️ Click the Actions tab to return to the top level of the Actions page.

You’ll see that the Runner Agent completed its tasks:

With the Runner Agent’s tasks complete, your repository has been migrated! Let’s look at its issue.

🛠️ Click the Issues tab to view the Issues page.

You’ll see something like this:

Notice that:

• There’s one less item in the open issues list, and

• There one new item in the formerly empty closed issues list.

🛠️ Click the Closed tab to view the closed issues list.

You’ll see the issue for the newly migrated repository:

🛠️ Click the issue to view its details:

You’ll see that the issue has been updated:

🛠️ Scroll to the comments section at the bottom of the page.

You’ll see a new comment from Warp, followed by a new notification:

The comment informs you that the migration was successful and provides a link to the newly migrated repository.

The notification below the comment informs you that Warp automatically closed this issue.

🛠️ Confirm that the migration was successful by clicking the link in the comment. In this example, the link is the text Tailwind-Traders.TailwindTraders-Website.

Here’s what the example migrated repository looks like:

Download Warp Vault

Warp Vault is available to download at vault.packfiles.io for a variety of operating systems and CPU architectures:

• Windows (Intel/AMD x64, MSIX)

• macOS (Universal, DMG)

• Linux (Intel/AMD x64, ZIP)

Install Warp Vault With a Package Manager

Homebrew (macOS)

Packfiles provides a Homebrew tap for macOS users. This allows Warp Vault to be easily installed and updated alongside the other packages managed by Homebrew on your system.

Warp Vault can be updated by downloading the latest release from , or via your package manager (if applicable).

Warp Vault checks for updates on launch. When new versions are available, an indicator will appear to inform you of the latest version.

Much has been said about "Zero-Trust" security architecture, but in practice, few vendors are able to truly deliver on that vision. Doing so requires a deep commitment to protecting the security and confidentiality of customer data, along with the drive and technical skill needed to solve the host of engineering challenges that make it possible to deliver scalable, resilient systems with these properties.

When we originally set out to design Warp, we were met with the following security challenges:

• Most migration tools, including first-party tools published by GitHub, require a combination of many highly privileged credentials to perform their work.

• Any individual operating migration tools, whether for their own use or on behalf of another organization, is required to have the privileged credentials mentioned previously to carry out migration tasks.