Build a Real Inventory Before You Scope Your Atlassian to GitLab Migration

Most engineering leaders know how many repos are in their Atlassian footprint, but not a lot else. While that’s a reasonable place to start, it’s also the easiest part of the migration.

What stalls an Atlassian-to-GitLab migration is everything wrapped around the code. The Jira issues and their comment threads, workflows that gate them, automation rules, and custom fields that piled up over time. Those are the things that really dictate how a migration will go.

That’s why your first step should be to build a real inventory before scoping anything. Whether you’re moving because Atlassian Data Center is being sunset, because you want better AI capabilities, or because you’re tired of paying for tool sprawl, the inventory is where you start.

What to count, and why each number matters

A useful inventory should tell you how many that actually matter. Here are some items and why they are important:

There’s not a lot of code mentioned in this list. Most of it is about process because that is the biggest change migrating from Atlassian to GitLab, and what will slow you down if you don’t plan accordingly.

The two numbers that matter most

If you only have time to pull two numbers this week, make them total comment volume and automation rule count. Both need custom engineering work, and both are routinely underestimated.

Comment volume. GitLab’s built-in Jira importer brings over titles, descriptions, and labels. Comments don’t come with it. If your teams need comment history with the original authors and timestamps, that means a scripted migration against the GitLab API. On GitLab.com, comment creation is rate-limited to 60 per minute, which caps a scripted migration at roughly 86,000 comments a day. A Jira instance with a few million comments is a multi-week job. For larger comment volumes, the Jira2Lab tool is likely a better choice than the built-in importer. More on that in a later post, or see the link to our guide at the bottom of this post.

Automation rules. GitLab has no equivalent to Jira’s no-code automation builder. Every rule you keep becomes a CI/CD job, a webhook receiver you build and host, an API script, or a rule you decide to stop having. Count the disabled rules too as they tend to be the ones nobody remembers until something stops happening.

The good news is that a real count usually makes the job smaller. You’ll likely find dormant projects can be archived, custom fields populated on a fraction of a percent of issues that can be deleted, and a surprising amount of automation rules turn out to be unused.

Get the numbers before you talk timelines

A proper inventory becomes the input to every decision that follows for the migration. Things like what GitLab will and won’t replace, how much fidelity each Jira project needs, which custom fields survive, how workflows and automation get rebuilt, and how many seats you actually need to buy. Having real numbers makes all of those decisions easier.

With your counts in order, you can better assess a realistic timeline. Don’t let a migration date be set based off a guess!

Download the full guide

Building the inventory is step one of ten. Ten Things to Address Before You Migrate from Atlassian to GitLab covers the rest, including what to expect from the Jira importer, how to fit your custom fields into GitLab’s limits, how to rebuild workflow enforcement, and how to price the gaps before they surprise you.

If you’d like help building your inventory, GitSimple’s migration team runs this discovery work for commercial and federal organizations. Let’s talk.