An Ona Automation that analyzes repos, dependencies, and tooling across hundreds of repositories in minutes.
Before you move a single repository, you need to understand what you have. Here's how an Ona Automation can analyze hundreds of repos and produce a migration-ready inventory in minutes.
Every large-scale git hosting migration starts with the same questions. What's in all these repositories? How do they depend on each other? What could go wrong? And who actually knows how this stuff works?
Organizations migrate git hosting platforms for good reasons: consolidation after acquisitions, moving from self-hosted to cloud, switching providers for better tooling or pricing. The technical act of moving a git repository is straightforward. The hard part is everything you need to know before you start moving things.
A typical enterprise has hundreds or thousands of repositories. Each one has a runtime stack, build tools, CI/CD configuration, and dependencies on other repos. Some dependencies are obvious, declared in package manifests or go.mod files. Others are implicit, buried in CI pipeline definitions, Terraform modules, git submodules, or references to the git hosting domain scattered across config files.
Understanding this landscape manually is brutal. Someone has to open each repository, read the code, trace the dependencies, figure out who maintains the tooling, and write it all down. For 50 repositories, that's a week. For 500, it's a quarter. Most teams either skip the analysis and discover problems mid-migration, or spend so long on discovery that the migration loses momentum before it starts.
Ona Automations run both imperative code and agentic prompts across hundreds or thousands of repositories at once. Each run executes inside a secure, isolated environment with full access to the repo, so the agent can read files, inspect git history, and apply judgment to what it finds.
We built an automation that produces a structured migration inventory covering every repository in an organization.
The automation runs against every repository in a target organization and collects five categories of information per repo.
Description. A summary of what the repository actually does. Across hundreds of repos, many have no README or an outdated one. The agent reads the code and produces a concise summary.
Stack. Languages, frameworks, and runtime dependencies. Knowing whether a repo is Go, Python, or Node matters for planning migration batches and identifying which teams need to be involved.
Tools. Build tools, CI/CD systems, and related infrastructure: Makefiles, Docker configs, GitHub Actions or GitLab CI pipelines, linting setups, deployment scripts.
Toolsmiths. The people who actually maintain the build and CI/CD configuration, identified by inspecting git history. Not who has access, but who wrote the relevant code. When tool configuration needs to change during a migration, these are the people who know how to ship those changes safely.
Dependencies. Relationships between repositories in the organization. The agent finds these by inspecting git submodules, CI file references, Terraform modules, Go module definitions, and anything else referencing the git hosting domain. Critically, the agent applies judgment to filter out noise like example URLs in docs or commented-out references, surfacing only the dependencies that actually matter.
The automation is defined in YAML and imported into Ona, making it easy to maintain and iterate on. For each repo, the agent spins up in an isolated environment, reads the codebase, inspects git history, and populates the report columns.
The output is a structured report: one row per repository, five columns. It can be viewed directly in Ona or exported as CSV for spreadsheet analysis and stakeholder sharing.
The tabular report is useful for understanding individual repositories, but migration planning requires seeing the dependency graph. The CSV export can be fed into a visualization tool that renders cross-repo relationships as a network graph.
Every edge shows which file contains the dependency, so a reviewer can judge whether a given relationship is relevant for the migration. A reference in a README is very different from a hard dependency in a CI pipeline.
We validated the automation against two real-world organizations: GitLab's CI sample projects (~60 repos with varied stacks and cross-repo CI dependencies) and the Golang GitHub organization (~60 well-maintained repos with heavier use of cross-repo dependencies).
In both cases, the automation reliably surfaced dependency relationships, identified tooling and stacks, and produced a complete inventory in minutes rather than the days or weeks a manual analysis would require. The Golang organization was particularly illustrative: the dependency graph clearly showed the central role of the core Go repository and which repos depend on it directly, exactly the kind of insight that drives migration sequencing decisions.
Start small. Run the automation against 10–20 repositories you know well. Compare the output to your own understanding to build confidence and identify gaps.
Iterate. The YAML definition is easy to modify. If your migration requires additional information — specific config files that need to change, repos using a particular CI feature, unusual setups to flag — add them as new report columns.
Scale. Once the automation collects what you need, run it against everything. The output becomes your source of truth for migration planning: which repos to batch, what order to migrate them, who to involve, and where the dragons hide.
Use the dependency graph for sequencing. Repos with no inbound dependencies migrate first. Repos that many others depend on need careful coordination. The visualization makes this sequencing obvious in a way a spreadsheet alone does not.
Migration planning goes from a weeks-long manual discovery process to a structured analysis that runs in minutes. Platform leads get a complete inventory: what every repo does, what it's built with, how it connects to other repos, and who to talk to when something needs to change.
This automation is available in the Ona Template Library. Run it on a few repos, tune it to your needs, and build the migration plan that would have taken your team weeks in an afternoon.
This website uses cookies to enhance the user experience. Read our cookie policy for more info.