Jira, Confluence and Bitbucket moved on automated pipelines, with a short verified cutover.
Atlassian has published the whole runway. Most plans are built around the last date on it, which is the one that matters least.
Data Center reaches end-of-life in March 2029. For most organizations this is not a question of if you migrate — it is a question of when and how.
March 30, 2026
No new Data Center licences for new customers.
March 30, 2028
End of licence sales for existing customers.
March 28, 2029
Data Center becomes read-only.
Read-only is the end state, not the start of the problem. Long before 2029 you are running an instance nobody is adding capability to, on a licence you cannot extend, with apps whose vendors have already moved on.
A second Atlassian countdown lands underneath the apps you already paid to move. Atlassian Connect — the framework a large share of Cloud Marketplace apps are built on — is on a published, three-phase retirement. New Connect apps could no longer be listed from 17 September 2025. Existing ones were frozen from 31 March 2026: still running, still patchable by their vendors, but unable to add modules, scopes or surfaces.
Full end of support arrives at the end of 2026. Nothing dramatic happens that day — Atlassian's own wording is that Connect becomes use-at-your-own-risk and stops receiving updates and security patches. It is not a cliff, it is a slow leak, which is exactly why it slips past migration plans.
Read the full breakdown of the Connect countdownThe Cloud Migration Assistants are good at the data and quiet about the configuration wrapped around it. Knowing which is which is how you price your own risk.
The data moves; the configuration is the work. Custom fields multiply across projects, workflow post-functions built in Groovy have no Cloud target, and permission and issue-security schemes are where verification quietly goes blind.
Pages and history migrate cleanly. Macros are the problem — user macros in particular, which are a Data Center-only feature and have to be rebuilt rather than moved. Macro rewriting at scale is a scripted job, not a manual one.
Repositories move, but every credential and CI integration pointing at them has to be re-pointed. Bitbucket Cloud has also retired app passwords, which breaks working Git remotes and pipelines that nobody thought were part of the migration.
Guessing the size of an instance is what blows migration budgets. The assessment is free, it produces a written plan, and it is the thing that turns our flat price from a quote into a commitment.
You get the inventory itself, not just a conclusion drawn from it. It is your data, and it is useful whether or not you migrate with us.
If you would rather run the inventory yourself first, the queries and scripts we use are written up in full.
The assessment tutorial: SQL, REST and ScriptRunnerIt is never the issues and pages that break the project. It is the apps — and specifically the moment you find out the vendor has no answer either, and the deadline does not care.
The vendor ships a Cloud version and a supported path for your data. This is the good case, and it still needs testing — "supported" and "lossless" are not the same claim.
The app is there; the migration is not. Someone has to move the configuration and the stored data by script. That someone is usually us, against the app's own REST or Forge storage.
We rebuild them as custom Forge apps so functionality moves with your data instead of breaking on go-live. Same for user macros and Groovy post-functions.
It is the most repeated advice in the Atlassian world and almost nobody takes it — because every incentive in the room, ours included, is paid to move more rather than less. Here are the three places we keep watching migrations get harder than they needed to be.
Mature instances carry dozens of permission and issue-security schemes, grants pointing at groups that no longer exist, and security levels referencing deleted custom fields. The real damage is that no admin can see every project, so nobody — including your migrator — can verify what moved.
Object schemas grow to fit whoever asked last. Attribute types drift, references go one-way, and the shape that made sense in Data Center is the shape you will be paying to reproduce in Cloud unless it is fixed first.
Assets tends to accumulate everything anyone ever wanted to track. Deciding what is genuinely in scope is cheap now and expensive under a migration clock.
Cleanup is a separate, modest line in the configurator, and you can own it yourself under our supervision for roughly half the cost of us doing it.
Five phases, in this order, on every migration we run. The pipelines are scripted and re-runnable, so we adapt and re-run live rather than waiting on a support ticket.
We inventory the instance and hand you a written migration plan: what moves cleanly, what does not, what each app will cost you, and which flat-price cell you land in. It is free, and it runs from 2 hours on a small instance to 3 days on a large one.
Dead schemes, orphaned security levels and unowned projects get resolved before they become migration defects. Users, groups and attachments are moved ahead of the cutover so the production weekend is not carrying the bulk of the data.
The whole migration runs end to end against a target you can log into and check. The pipelines are scripted and idempotent, so a failed run is re-run rather than restarted by hand, and the rehearsal is the same code that will do the real thing.
Because everything bulky is already staged, the production window moves a delta rather than the instance. We verify counts on both sides — projects, issues, pages, attachments, users — before anyone is let in.
Every migration tier includes 2 weeks of post-go-live hypercare. Real instances surface their problems in the first fortnight of real use, not on cutover night, and that is the window where we are still on it.
"Zero downtime" gets sold loosely, so here is what we mean by it. Your teams keep working in Data Center while the migration is built and rehearsed. Users, groups and attachments — the bulky, slow parts — are pre-staged well before the cutover. The dry run proves the whole thing against a target you can log into. What is left for the production window is a delta, verified on both sides before anyone is let in.
What it does not mean: the source instance is not writable while that final delta runs. A migration that claims otherwise is either not moving everything or not verifying it. The honest goal is a window measured in hours, on a date you chose, with a rehearsed rollback — not the absence of a window.
Users, groups and attachments pre-staged
Full dry run against a real target
Production window is a verified delta
The trade is real and worth stating plainly. In Data Center you own the edge — your own WAF, your own CDN, your own rules. In Atlassian Cloud you inherit a fully managed AWS-native stack: Amazon CloudFront for CDN, AWS WAF at the application layer, and AWS Shield Advanced for DDoS. It is enterprise-grade and battle-tested, and you cannot touch it.
For most teams that is an upgrade. For teams whose security posture depends on custom edge rules — IP allowlists tied to a corporate perimeter, bespoke WAF signatures, geo-fencing enforced upstream — it is a genuine gap that has to be redesigned rather than migrated. We map each capability to its Cloud equivalent during the assessment so your security team sees the gaps before the cutover, not after.
Where your data physically sits is a planning item, not an afterthought — it constrains which Cloud plan you need and, in some cases, which products can move at all. Regulated instances also tend to be the ones with the most aggressive issue-security setup, which is exactly what makes verification hard. Both get answered in the written plan.
We wrote the full Cloudflare-to-Atlassian-Cloud capability map, gap by gap, for exactly this conversation.
Read the edge-security assessmentMost migration failures aren't due to technical limitations. They're due to predictable mistakes that organizations make over and over again.
44–57%
failure rate
According to industry research, nearly half of cloud migrations fail to achieve their objectives.
62%
say it’s harder than expected
Most organizations underestimate the complexity and resource requirements.
28%
higher costs on average
Cloud licenses typically cost more than Data Center, especially at scale.
12–16 months
for large migrations
The typical end-to-end timeframe for a large enterprise, when everything goes according to plan.
Rushing into migration without comprehensive assessment leads to data loss, application downtime, and user dissatisfaction.
Many Data Center Marketplace apps don't have Cloud equivalents. Discovering this mid-migration forces costly workarounds or rollbacks.
Wrong data residency choices, missing audit logs, and misconfigured IAM policies lead to regulatory fines and security breaches.
Underestimating data volume, network bandwidth, or complexity leads to incomplete migrations and data corruption.
Failing to document and replicate custom workflows, scripts, and configurations causes process disruptions post-migration.
Poor communication and training leads to employee resistance, reduced productivity, and failed adoption.
European Enterprise
Faced GDPR fines after migrating to non-compliant data residency region.
Global Tech Company
Lost 12 hours productivity due to legacy SSO configuration issues during migration.
Financial Services Firm
Rolled back migration after discovering compliance app wasn't cloud-ready.
Healthcare Provider
Failed HIPAA audit after not enabling audit logging in Cloud.
The good news is that most failures are predictable. With proper planning and experience, you can avoid the common pitfalls.
This isn't about finding a vendor who promises it will be easy. It's about finding someone who has done it before and knows what to expect.
This is the whole price list. Size comes from your active user count, complexity from apps and customisation, and the cell you land in is a flat price with a delivery window to a UAT-ready target — not a day rate that drifts.
| Instance size | Low complexity | Medium complexity | High complexity | Free assessment |
|---|---|---|---|---|
| XSUnder 250 users | €1,000~2 days | €1,400~3–4 days | €1,800~1 week | 2 hours |
| S250–500 users | €2,000~1 week | €2,700~1.5 weeks | €3,600~2 weeks | 4 hours |
| M500–1,000 users | €4,000~2 weeks | €5,500~3 weeks | €7,200~4 weeks | 1 day |
| L1,000–2,000 users | €12,000~4 weeks | €16,000~6 weeks | €21,500~8 weeks | 2 days |
| XL2,000+ users | €48,000~3 months | €65,000~4 months | €86,000~5 months | 3 days |
Every tier includes 2 weeks of post-go-live support. After that, ongoing maintenance is €50 an hour, billed for what you use.
If you are on — or applying for — Atlassian FastShift, the combined total drops by 20%, because Atlassian carries the programme-management and tooling overhead. How we support FastShift
Answer a few questions and see a transparent flat price and delivery window — no sign-up, no sales call. You pick the size; we verify it free at the assessment.
Hi! I'll help you scope your Atlassian Cloud migration. To start: what are you moving to Cloud (Jira, Service Management, Confluence, Bitbucket?), and roughly how many people use it?
On Atlassian's FastShift program? We do the hands-on delivery — and take 20% off your total. Just flag it in the quote above.
How we support FastShiftEvery migration includes 2 weeks of hypercare. After that, ongoing admin, configuration and ScriptRunner / automation upkeep is available at a flat €50/hour — no retainer lock-in.
Data Center to Cloud is the migration most organizations are here for, and everything above describes it. These are the other two we run.
Merging multiple Cloud instances, typically after mergers, acquisitions, or organizational restructuring. More complex than it initially appears.
Migrating from other project management platforms like Monday, Trello, or Asana to Jira. Often involves significant data mapping and workflow re-engineering.
Moving from self-hosted Data Center or Server instances to Atlassian Cloud. This is the most common migration type as organizations respond to the Data Center EOL.
These aren't just numbers on a slide. Each project came with its own set of challenges and required creative problem-solving, at the scales where the configuration problems above actually bite.
38,000 users — OpenBet
Dual instance migration plus Bitbucket from on-premises to cloud delivered end-to-end. Coordinated a complex multi-platform cutover involving legacy systems, high-availability requirements, and extensive user coordination across the organization.
9,500 users — UBS
Full Jira/Confluence/Bitbucket migration with zero downtime. Global financial institution with complex compliance requirements across multiple regions.
8,500 users — SolarEdge
EMEA-wide migration with embedded compliance for privacy regulations. Required careful data residency planning and extensive stakeholder communication.
1,800 users — Diconium
CMDB and Assets implementation and migration for a digital transformation company within the Volkswagen Group ecosystem. Complex configuration management across distributed teams.
1,200 users — McLaren
Cloud-to-cloud consolidation following organizational restructuring. Merged multiple instances into unified environment while maintaining operational continuity.
1,200 users — Aer Lingus
Advanced automation implementation reducing manual admin workload by 60%. Focused on ScriptRunner customizations and API-driven workflows.
800 users — Zyter
JSM adoption replacing Salesforce. Improved service efficiency through better integration with existing healthcare workflows.
400 users — Netcentric
Seamless cloud transition with performance optimization for distributed teams across multiple time zones.
250 users — ABSLBS
Confluence and Jira migrations both completed. Delivered clean data transfer with minimal disruption to daily workflows.
More migrations in the pipeline
New engagements are kicking off. Check back soon for the next batch of cloud journeys in flight.
Migrations require a specific set of skills. We have developed expertise across the Atlassian ecosystem through years of hands-on experience.
For regulated industries, compliance isn't optional. Security isn't a nice-to-have. These are non-negotiable requirements that must be addressed from day one.
Migration isn't just a technical project. It's a business transformation that affects how teams work every day.
Eliminate dedicated DevOps overhead for on-prem infrastructure. Reduce maintenance burden and free up resources for innovation.
Reduction in admin workload
Access to Atlassian Intelligence (AI), new features, and integrations that only ship to Cloud. Stay ahead of the curve.
Cloud features released in 2024
Enterprise-grade security features, compliance certifications, and automated security updates. Focus on your business, not security patching.
Of customers on Cloud
After ten-plus migrations, from 250 users to 38,000, the thing worth saying out loud is that they are imperfect by necessity, not by design. Something will land differently on the other side — a macro that renders slightly wrong, a filter that needs re-saving, an app whose reports start their history on cutover day. Every migration has a list like that.
Waiting for the version with no list is the single most expensive mistake we watch organisations make. The instance keeps growing, the apps keep sedimenting, and the same move costs more every year you defer it. The goal is not perfection, it is a migration where every imperfection is known, written down and priced before you go live.
We won't tell you migration is easy. We have been in the trenches when things go wrong. But with proper planning, realistic expectations, and experience to draw from, migrations succeed — the organizations we have worked with are now operating in Cloud and benefitting from the platform's capabilities. Migration is hard, but you don't have to do it alone.
The long version, subjectivelyMigration doesn't have to disrupt your business. With the right expertise, it becomes an opportunity to optimize and modernize your Atlassian ecosystem.
We don't work with everyone. We focus on organizations where we can make a meaningful difference.
You need more than a migration tool vendor
Atlassian provides migration assistants. What you need is someone who has used them in production and knows their limitations.
You have complex requirements
Regulated industries, large user counts, custom integrations, strict compliance requirements. These aren't edge cases — they're what we specialize in.
You value experience over marketing
We're not trying to sell you on Cloud. We're helping you get there with minimal disruption and maximum success.
You're willing to invest in doing it right
Proper planning takes time. Rushing migration saves weeks upfront and costs months later.
Three dates matter. On 30 March 2026 Atlassian stops selling new Data Center licences to new customers. On 30 March 2028 licence sales end for existing customers too. On 28 March 2029 Data Center becomes read-only. Read-only is the end state, not the start of the problem — the practical deadline is whenever your renewal, your apps or your auditors get there first.
After 28 March 2029, Atlassian Data Center products become read-only. All support, downloads, and renewals stop. Organizations must migrate to Atlassian Cloud or alternative solutions before this date to maintain full functionality.
Our published delivery windows run from ~2 days for a small, low-complexity instance to ~5 months for a large, high-complexity one, measured to a UAT-ready target. Every tier then includes 2 weeks of hypercare after go-live. Size sets the floor; apps and customisation set the rest.
We publish a flat price for every size and complexity combination, from €1,000 at the small end to €86,000 for a large, high-complexity instance. It is a fixed price, not a day-rate estimate that drifts. If you are on or applying for Atlassian FastShift, the combined total drops by 20% because Atlassian carries the programme-management overhead.
It carries the core well: issues, pages, users, groups, attachments, comments and history. What it does not carry is the configuration wrapped around them. Permission schemes that share a name with a scheme already in your Cloud target get renamed during migration. Issue security level permissions that reference unsupported custom field types do not migrate at all. Confluence user macros, ScriptRunner Groovy, Data Center-only REST endpoints, the shape of your Assets schema and filter JQL that breaks on a tenant move all need hands-on work.
Every app lands in one of three outcomes: the vendor has a Cloud version and a supported migration path, the vendor has a Cloud version but no path for your data, or there is no Cloud equivalent at all. The third case is the one that moves timelines, and we resolve it by rebuilding the functionality as a custom Forge app. Worth knowing separately: Atlassian Connect, which a large share of Cloud Marketplace apps still run on, reaches full end of support at the end of 2026.
Users keep working in Data Center right up to the cutover, and the cutover itself is a short, verified delta rather than a big-bang export. That is what zero-downtime honestly means: pre-staged users, groups and attachments, a rehearsed dry run, and a production window measured in hours rather than a lost weekend. What it does not mean is that the source instance stays writable while the final delta runs.
They do not move. Data Center Groovy does not run in Atlassian Cloud, and Confluence user macros have no native Cloud equivalent. We rebuild them as custom Forge apps so the functionality moves with your data instead of breaking on go-live, which is the same team and the same codebase as our Forge development service.
No — they can be staged, and on larger instances they usually should be. The order matters more than the timing: users and groups go first so identity resolves consistently, and anything that links across products, such as Confluence pages embedding Jira issues, needs both sides addressable when the second product lands. We plan that sequence in the assessment.
We inventory the instance, tell you what will not move cleanly, and put a flat price on the rest. No obligation, and the inventory is yours either way.