I Spent 2 Months Migrating To Jira

I've spent the past couple of months trying to migrate a ClickUp workspace over to Jira. I'm not talking about my own workspace, I'm not moving The Productive Dad anywhere, but I did this as part of my day job.

And I want to tell you about it because I think the experience reveals something important about why you're probably using the right tool already, even if it doesn't always feel that way.

The access problem

Let me start here because it set the tone for everything that followed. To do a proper migration over to Jira using the clean ClickUp-to-Jira import tool, you need admin rights in Jira.

That's okay, but even with admin rights Jira requires you to create a brand new project to import data into. You can't bring data into an existing project. So if you've already built out your Jira board, set up your columns, structured your workflow, you're going to need to start from scratch with a new project just to run the import, and then figure out how to merge the two. That's a big workaround straight out of the gate.

And for a lot of things like deleting tasks, reassigning them, changing work types, I just didn't have permission. I had to wait for a Jira admin to step in every time I hit one of those roadblocks. In a large shared Jira workspace, that's just how things work 🤷♂️ The system is designed around centralised control. Being a ClickUp admin and consultant, this felt like the slooooowest thing in the world.

Work types

That brought me to something called work types. These are a bit like task types in ClickUp. In this Jira workspace there were twelve of them: things like bug, story, epic, support item, requirement, project task.

Each one has its own set of statuses it can move through, and those rules aren't always obvious or consistent.

A support item might go from open → more info required → in progress → done.

A development task might require a specific field to be filled out before it can move to in progress at all.

And some work types I just couldn't move at all — I didn't have the permission.

So before I could migrate anything meaningfully, I had to create a task for each of the twelve work types just to document the status flows, because of course there was no documentation anywhere. It's just assumed you know what the workflow is.

That's a significant piece of work before you've moved a single real task. It's not impossible, but it tells you something about how Jira is built. It assumes you'll invest heavily upfront defining your structure and then work within very tight parameters. There isn't much flexibility once it's set.

The limitations that really wound me up

Custom fields in Jira are shared across the entire workspace. Every user in every project sees them. I couldn't recreate the custom fields I had in ClickUp without cluttering the workspace for hundreds of other people who had no need for them. So I didn't.

Same with statuses. Shared globally, tied to work types, not configurable per project. In ClickUp I had different statuses for different lists. In Jira that's not possible in the same way. So I ended up using Jira labels instead.

Labels became my workaround for almost everything. I created a label for each status. Things like:

status-to_do
status-in_progress
status-done

And then a label for each project and another for each client. It worked, just about. But every label I created was visible to everyone in the workspace. It's messy, it's non-standard, and it's the kind of thing that makes a shared workspace harder to navigate over time.

Moving the actual data

This was a whole thing in itself. A simple CSV export from ClickUp and import into Jira doesn't work cleanly. Subtask relationships break, status mapping doesn't work and everything lands with the same default status regardless of where it was in ClickUp.

So I ended up using a Python script to extract data from each ClickUp list and format it specifically for Jira.

Because there were no custom fields to map into, all the ClickUp custom field data and the comments got consolidated into each task's description. Not ideal, but it meant no task history was lost.

The full flow, for every single list, was:

Run a Python script to export from ClickUp This gave me a master backup CSV (open and closed tasks), a parent tasks CSV (open tasks only), and a subtasks CSV (open tasks only).
Import the parent tasks CSV into Jira.
Export those same tasks back out of Jira as a CSV to get the Jira-generated task keys.
Run a second Python script to match the subtasks CSV against the parent tasks just exported.
Import the matched subtasks into Jira.

It worked. But it took an insane amount of time.

A warning about ClickUp Docs

Now that everything is in Jira, I need to move the documentation across too. It turns out there's no easy way to bulk export ClickUp Docs. I'm going to have to go through them one by one!

I want to be clear, I think ClickUp Docs are genuinely useful. The ability to ask questions across your ClickUp workspace, reference documents in tasks, keep everything in one place. That has real value.

But if there's any chance you'll ever need to move that information somewhere else, keep an eye on how much you're putting in there 👀 Exporting right now is a manual job, and that can really add up.

The thing I keep coming back to

When people tell me they're thinking about moving to Jira, what I usually hear underneath it is that their current setup isn't working and they want something that feels more serious. More structured, more like a "real" operations system.

I totally get that feeling. But Jira's structure comes at a cost.

It assumes centralised control. It assumes an admin function. It assumes your workflows are stable enough to define upfront and unlikely to change much. For a large enterprise, that's fine. It's sort of built for that environment. But even then it doesn't work very nicely.

For a small agency or service business where one person might need to spin up a new project structure on a Thursday afternoon without raising a ticket, Jira is going to slow you down.

ClickUp is built the other way around. The tool bends to your process. Custom fields scoped to one list, statuses per folder, flexibility that doesn't require permission. That's not a small thing.

So before you start looking at alternatives, ask whether the tool is actually the problem, or whether it's the way the tool is set up. In my experience, it's almost always the second one.

And that's a much easier fix.