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 the same stack Atlassian runs its own products on, 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, because 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 assessmentNone of these are exotic. They are the six things that have cost us a night or a rollback on real migrations, which is why the assessment checks for every one of them before a price is quoted.
Confluence user macros do not exist in Cloud. Every page that used one renders the raw macro name after cutover unless it is rewritten to a Forge macro or replaced before the move.
The Cloud comment field is shorter than Data Center's. Long incident threads and pasted logs are truncated silently, so we find and split them before the import, not after a user does.
Security schemes map by name, and a level that does not match on the target side leaves the issue visible to everyone. We diff the schemes and hold the wave until every level resolves.
Jira Assets (Insight) objects that reference each other cannot be created in one pass. Our migrator orders them, creates placeholders, then reconnects the tickets that pointed at them.
Time-tracking and reporting apps often migrate configuration but not history. The reports start their history on cutover day unless the vendor path is run separately and verified.
Users who exist under two email addresses, or under a legacy SSO attribute, land as duplicates or as inactive. We reconcile the directory first, because every assignee and watcher depends on it.
The scripts that catch these live in the open-source toolkits on the portfolio page. If you would rather run them yourself before talking to anyone, that is what they are there for.
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, with 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?
You are chatting with an AI assistant (Anthropic Claude). Your messages are sent to Anthropic to generate the replies, and the assistant may look up public facts with a web search (Serper). Please don’t share passwords or personal details you don’t want processed. Privacy policy
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 a bank or a hospital the migration plan has to survive an internal audit before anything moves. These are the areas that review has covered on our past projects.
What changes for the people who use the tools once the migration is done, from the projects we have run.
No more upgrade weekends, no Java patching, no database server to keep alive. At Aer Lingus the automation that came with the move cut the manual admin work by more than half.
Less manual admin work at Aer Lingus
Atlassian ships new features, Rovo and the AI capabilities to Cloud only. Data Center gets security fixes and a countdown.
Where Rovo, Atlassian Intelligence and new Forge modules ship
CloudFront, AWS WAF and Shield in front of every instance, SOC 2 and ISO 27001 on Atlassian's side of the audit, and no security patch you have to schedule yourself.
Patch windows you schedule
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 will not tell you a migration is easy. We will tell you what its list looked like on the last ten, and what each item cost to fix. Every organisation named on this page is running in Cloud today, with a list of its own that was written down before go-live.
The long version, subjectivelyThese are the four reasons people have actually hired us for a migration. If yours is on the list, the assessment is free.
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 are not edge cases; they are 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.