Decide What GitLab Is Not Replacing Before You Migrate from Atlassian

One of the best reasons to move from Atlassian to GitLab is consolidation. Code, planning, CI/CD, and security in one platform means fewer licenses, fewer integrations to maintain, and fewer places for things to break. GitLab delivers on most of that promise.

Atlassian shops rarely run just Jira and Bitbucket. Over the years they add Confluence, Jira Service Management, a test management app, a time tracking app, ScriptRunner, and a handful of other Marketplace tools. It should be obvious that not all of those tools are going to have clean counterparts on the GitLab platform.

That’s why the second item in our eBook, Ten Things to Address Before You Migrate from Atlassian to GitLab, is deciding what GitLab is not replacing. This should be easier to see once you’ve done your inventory.

Where GitLab is strong, and where it isn’t

The core of the Atlassian stack has solid GitLab equivalents. Repositories and merge requests replace Bitbucket. Work items, epics, iterations, and boards cover Jira Software, with some adjustments to how workflows are enforced. GitLab CI/CD is a strong platform, though every Bitbucket Pipelines definition will need a full rewrite.

Here is what to look at outside the Atlassian core:

GitLab is a DevSecOps platform, not a one-for-one copy of every Atlassian product and Marketplace app. Keeping that in mind will be very helpful for planning your migration.

The two gaps that derail migrations

In our experience, service desk and test management are the two areas most likely to throw a migration off course. This is because the people who depend on those tools usually aren’t in the room when the migration is scoped.

Service desk. If your support or IT teams run Jira Service Management in production, GitLab’s Service Desk won’t take its place. It handles email intake and ticket templates, not full ITSM. That usually means that a separate ITSM tool needs to be part of the business case from the start.

Test management. QA teams on Xray or Zephyr rely on test execution tracking, test run history, and traceability back to requirements. GitLab’s test cases document scenarios, but they don’t cover execution or traceability. If your QA process or your auditors depend on that, plan for it up front.

The fix for both is simple: take the table above to every team that uses each tool and ask them directly what they need.

Not everything needs a replacement

There’s another side to this decision. A migration is one of the few times an organization looks hard at every tool and process it runs. Some of what lives in Atlassian today exists because it was easy to add but may not be needed moving forward.

So when you walk through each tool with its users, ask what do you need from this in GitLab? And is there anything here we could stop doing? You don’t necessarily need a one-for-one replacement for every step.

Download the full guide

Deciding what GitLab won’t replace is step two 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.