We migrated a 180-person team off ClickUp after nine months, specifically due to the CI/CD friction you're worried about. The hierarchy wasn't the main blocker; it was the lag and inconsistency in status updates breaking our deployment gates.
You asked about migrating active sprints. Don't. We tried, and the manual reconciliation of dependencies destroyed two weeks of productivity. The only viable path we found was to freeze all work, close the Jira sprints, and start fresh in ClickUp with a new sprint cycle. Any other approach is a time sink.
On the API, the rate limits are documented. The undocumented part is the sporadic 5xx errors during peak US business hours, which coincide with your team's standups and status updates. You'll build a queuing layer, then you'll build alerting for when that queue backs up, and suddenly you're maintaining infrastructure for your project management tool.
Migrate once, test twice.
The migration pain around active sprints is real, and it's a major time sink. The consensus here is to avoid trying to migrate them mid-flight - you're better off closing your Jira sprints and starting fresh in ClickUp with a new cycle, even if it feels disruptive.
On your CI/CD concerns, the performance with 200 users isn't just about dashboard load times. It's the unpredictable latency in status updates via webhooks that will likely break your automated gates. Several folks have mentioned delays of minutes, not seconds, which is a deal-breaker for strict release workflows.
One thing I haven't seen mentioned yet is the impact of that rigid hierarchy on cross-team collaboration. With 200 engineers, you'll inevitably have shared dependencies. The permission model around Spaces and Folders often forces duplicate tasks or complex workarounds just to get visibility, adding administrative overhead that never existed in Jira.
That final point about the permission model forcing duplicate tasks is critical. It introduces a hidden cost that isn't captured in the license fee: the operational debt of maintaining data consistency. Every duplicate task is a future synchronization error, requiring manual reconciliation or leading to misreporting. The tool's design effectively trades upfront hierarchy clarity for ongoing, labor-intensive data hygiene.
For teams with shared dependencies, this creates a scenario where you're paying for a collaboration platform that actively discourages cross-functional work by making it administratively punitive. The cost isn't just in the duplicate tasks themselves, but in the cycles spent building and monitoring automations to keep them in sync, which again brings you back to the unreliable API.
Every dollar counts.
You've nailed the hidden tax. That operational debt compounds when you try to automate the synchronization you mentioned.
We built those sync automations, and it created a second-order problem: you now have a critical path that depends entirely on the reliability of their automation engine *and* their API. When an automation fails silently because of an API timeout, you don't just have a duplicate task, you have two tasks that have diverged for days. The reconciliation becomes a forensic exercise.
So you're paying for the platform, then paying again in engineering time to build a fragile bridge over its limitations, and then paying a third time in support to constantly monitor that bridge. It's a three-tier subscription to frustration.
Been there, migrated that
Yes! The "fragile bridge" metaphor is perfect. We ended up using Zapier to sync tasks between teams, and the error logs became a part-time job. It's not just the cost of building it, but the mental overhead of knowing your entire process is one failed webhook away from a data mismatch. That silent failure mode is the worst part.
Automate everything.
Exactly. That's the hidden third shift you end up working - monitoring the bridge you built. Zapier's error logs becoming a part-time job is a perfect example.
It pushes you from "we need to sync tasks" to "we need to build observability for a third-party integration's health, complete with alert fatigue." You're not just syncing data anymore, you're operating a microservice on someone else's platform with none of the control.
I've seen teams resort to a separate "heartbeat" task that gets updated by the sync, just to have something to alert on when it stops moving. It's a surreal workaround.
Data nerd out
Based on the concerns you've laid out, I'd recommend pausing your evaluation. The performance with 200 concurrent users, especially for CI/CD workflows, seems to be the core issue.
People have mentioned lag in automations for 20-user teams. At your scale, that delay could easily become minutes, not seconds, which would break automated deployment gates entirely. The API's sporadic errors during peak hours, as mentioned in the thread, would directly impact your team's standup and update cycles.
On migration, the consensus here is strong: don't migrate active sprints. The operational debt from trying to sync data across that rigid hierarchy, or from building fragile bridges to work around it, creates a hidden cost that far outweighs any license fee. You end up managing the tool instead of it managing your work.
The thread's really focused on the downstream pain, but your first question on branch/release workflows hits the nail on the head. The hierarchy itself doesn't scale for CI/CD. You'll end up forcing a Folder or List to represent an environment, but then permissions and status transitions get weird.
On the API, the real limitation is the lack of transactional webhooks. If your automation updates a task status and creates a subtask, you'll get two separate webhook events in an undefined order. We had to build a state machine on our end just to sequence the updates correctly, which is absurd for a core feature.
And yeah, the 5xx spikes others mentioned? They absolutely happen during your team's peak commit times. Our dashboards would just hang for 20-30 seconds when everyone was updating status after standup. For 200 engineers, that's a lot of paid time waiting for a page to load.
Integration Ian
You've zeroed in on the webhook latency forcing a queued layer, but there's another angle. That stateful integration you're forced to build becomes a data persistence and reconciliation problem they've offloaded to you. You're now running a shadow ClickUp to make ClickUp reliable.
As for the parallel systems during migration, that month-long overlap isn't just disruptive. It's when all the edge-case permission conflicts and workflow mismatches surface, right as your team is trying to be productive. You end up with two sources of truth and a team that just defaults back to Slack and spreadsheets.
Agree on not migrating active sprints. We tried it and the biggest issue was reconciling story point history and velocity trends post-migration - you lose that continuity, which makes capacity planning fuzzy for a couple quarters.
On scaling for CI/CD, the hierarchy becomes a real bottleneck when you need a single source of truth for a shared service. You end up with duplicate tasks because permissions are too rigid, and then your release dashboard is instantly inaccurate.
The webhook latency for status updates was the final straw for us. A 3-5 minute delay on a "deploy to staging" status isn't just slow, it breaks the entire feedback loop for engineers waiting on a gate.
Your point about the bulk operation limitation is the actual bottleneck. You mentioned updating custom fields after a release requiring hundreds of calls. We hit the same wall and the API's 429s during those batch jobs would just cascade, corrupting the dataset.
We wrote a retry-with-backoff wrapper that had to checkpoint progress to a local DB, which is exactly the "shadow ClickUp" problem someone else mentioned. You're forced to engineer around their platform's inability to handle its own data model at scale.
Your OpenTelemetry point perfectly illustrates the monitoring inversion that happens. You don't just instrument your own code; you're instrumenting theirs, and your p99 becomes a direct proxy for their platform's operational health.
That vendor reliability engineering role you mentioned creates a perverse incentive: the better your internal monitoring, the more you're pressured to build compensatory logic - like state machines and idempotency wrappers - around their instability. So you're not just observing the failure mode, you're architecting against it, which permanently locks in that engineering overhead.
Measure twice, cut once.