Consulting
Strategy, governance and delivery for complex Atlassian estates — with a wealth of skill and experience in the enterprise.
- Platform strategy & health checks
- Cloud migration planning & delivery
- Governance for regulated industries
Atlassian Solution Partner
The Atlassian partner trusted by Europe's largest banks
Consulting, custom solutions and licensing for enterprises where reliability is non-negotiable. Dione Technology has delivered Atlassian at BNP Paribas, Société Générale, Barclays, AXA and Collinson.
Trusted in production at
Why now
2026 is a turning point for Atlassian platforms
Three shifts are forcing enterprise teams to make decisions this year. Each one is easier with a partner who has done it before.
01 — Migration
Data Center is sunsetting
Atlassian has set Data Center's end dates: new-customer sales ended March 2026, existing customers can buy licenses and apps only until March 2028, and support ends in March 2029. The question is no longer if but how to move — with security, compliance and audit requirements intact. We plan and deliver migrations that leadership can sign off — here is how.
02 — Licensing
Costs are climbing
Successive price rises across Cloud and Data Center make licensing a board-level topic. The right edition, tier and bundle strategy can fund much of your migration. We optimise Atlassian licensing so you get the most from every seat.
03 — AI readiness
AI needs a clean foundation
Rovo and AI agents are only as good as the data and workflows beneath them. Consolidating and structuring your Atlassian platform is the prerequisite for AI that actually works. We get your foundation ready.
Cloud migration
Data Center to Cloud, run like a regulated change
A bank does not lift and shift. It assesses, evidences, rehearses and cuts over — with rollback plans built for change-board approval and records your auditors can follow. And with procurement, security review and change windows in the path, a 2029 deadline makes migration a decision for this year, not next.
01
Assess
A full inventory of what actually moves: projects, workflows, custom fields, scripted automations, Marketplace apps, integrations. Every app tagged keep, replace, rebuild or retire — and everything stale archived first. Migrate less, migrate better.
Explore this step 02Evidence
The pack your second line will ask for: data-residency mapping, vendor risk documentation for your DORA register, rollback plans, a cutover runbook. Written before the migration, not reconstructed after it.
Explore this step 03Rehearse
Full test migrations against production-scale data. Workflows, permissions, boards, automations and app data verified — deviations fixed and re-run until the rehearsal is boring.
Explore this step 04Cut over
Staged, per-division cutovers inside agreed change windows, with hypercare until your admins confirm steady state. Downtime is a planned window, not an incident.
Explore this stepWhat we actually touch
Migration tooling gets you part of the way. We handle the part it doesn't.
- Migration tooling, used honestly. Atlassian's Jira Cloud Migration Assistant (JCMA) and Confluence Cloud Migration Assistant (CCMA) where they fit; scripted approaches where they don't. No tool moves a bank's estate unattended.
- Apps, triaged not assumed. "Cloud-compatible" versions checked feature by feature before anything is trusted — parity claimed is not parity delivered.
- Workflows and custom fields, rationalised first. Years of accumulated schemes cleaned and consolidated before they move, not after.
- Scripted automation, rewritten for Cloud. ScriptRunner and scripted post-functions audited and re-implemented against Cloud APIs, not left to break at cutover.
- Plans and Assets, migrated deliberately. Advanced Roadmaps plans and Jira Service Management Assets mapped explicitly, not discovered missing later.
- Confluence, not an afterthought. Spaces, permissions, macros and app dependencies get the same triage as Jira.
Start with a migration readiness assessment
A fixed-scope engagement, measured in weeks: full inventory and app assessment, EU data-residency and DORA mapping, cost and sequencing — including what Atlassian's own migration incentives, from the free Cloud migration trial to dual licensing, can fund — and a phased plan with rollback your second line can defend. If the right answer is "not yet", the assessment says so.
Book a readiness assessmentPrefer to read first? Download our free guide: Jira Cloud migration for banks and regulated enterprises (PDF, no email required). Residency, DORA, change control, timelines — the questions your risk team will ask are answered below.
What we do
Services across the life cycle of any Atlassian project
Three service lines, one senior team — from first workshop to steady-state support.
Solutions
Custom development that is maintainable and scalable — built to enterprise standards, with friendly and professional support.
- Integrations & automation
- Custom apps & workflows
- Jira Service Management & ESM
Licensing
Let us manage your Atlassian licenses and make sure you are getting the most out of the Atlassian platform — and your budget.
- License management & renewals
- Edition & tier optimisation
- Cloud vs Data Center cost analysis
Use cases
The work we are asked to do most often
No named engagements, no invented numbers — the detail of client work stays confidential. Here are six engagement shapes we run again and again, described the way they really go, so you can recognise your own situation in them.
Upgrade Jira Data Center without losing a Friday
The situation. Your Jira Data Center estate is on the 10.3 LTS — supported only until December 2026 — or something older, and it has to stay healthy for years yet across the Data Center runway to 2029. Your change board wants a plan, not a leap of faith, and nobody has catalogued what fifty Marketplace apps will do on the other side.
How we run it. A typical engagement starts by mapping the path to the current 11.3 LTS against Atlassian's upgrade matrix — the 11.0 boundary alone brings the Spring/Jakarta framework change, basic authentication disabled by default, and a PostgreSQL 16 / MySQL 8.4 database floor, so the platform hop is planned as a normal upgrade in an agreed window (zero-downtime upgrade does not cross platform releases), with ZDU reserved for the node-by-node moves within a line. Every app goes through the UPM update check against the target version and gets a verdict: compatible, upgrade-then-update, or unknown — and unknowns get investigated, not ignored. Then we rehearse the whole thing on a staging clone until it is boring.
What you keep. A tested, change-board-ready upgrade runbook, an app compatibility register with a decision recorded per app, and an estate on a supported LTS receiving security backports — positioned to stay current and secure through the Data Center runway while the migration decision is made properly.
A health check your auditors would actually accept
The situation. Your Jira platform has grown by accretion: a decade of custom fields, workflow schemes and admin decisions nobody can reconstruct, on a version drifting towards its end-of-support date. In a regulated environment that is not just untidy — it is an audit finding waiting to be written, and the person who understood it all left last year.
How we run it. A typical engagement inventories the estate — projects, schemes, custom fields, apps, automation, integrations and admin access — and scores it against two baselines: Atlassian's own currency expectations (releases are supported for two years, and LTS releases exist precisely for organisations that upgrade roughly annually) and the governance your second line expects, from change records for configuration changes to a defensible answer on who can administer what. Findings are ranked by risk, not by how interesting they are to fix.
What you keep. A written platform health report, a governance operating model — ownership, change control, admin standards — your risk function can review, and a prioritised remediation backlog your own team can execute or we can deliver.
Integrate Jira with the systems your bank runs on
The situation. You need Jira Cloud wired into the systems around it — identity, ITSM tooling, data platforms — and your security team's first questions are where the code runs, where the data goes, and who approved the egress. A quick script with an API token will not survive that review, and building on Connect is off the table: it reaches end of support in Q4 2026.
How we run it. A typical engagement builds on Forge, Atlassian's strategic cloud platform: the app runs on Atlassian-hosted compute inside a security layer that enforces tenancy isolation, and every external call must be declared in the manifest — undeclared egress simply fails, which is exactly the property a bank wants. Where heavy processing or data must stay on your infrastructure, Forge Remote bridges to your own backend. The integration is engineered against Jira Cloud's published constraints — the points-based rate limits enforced since March 2026, and the registration limits and 30-day expiry on REST-registered webhooks — with 429/Retry-After handling built in rather than bolted on.
What you keep. A working integration your security team can actually review — declared scopes and egress visible at install — plus architecture documentation, source code and a handover your own engineers can maintain.
Roll out Jira Service Management beyond IT — with Assets underneath
The situation. Your IT service desk runs on JSM, but HR, facilities and legal still run on shared mailboxes, and there is no single register of the things all those requests are about. You have Premium or Enterprise licensing that already includes Assets — 50,000 objects included on Premium, 500,000 on Enterprise, extendable if you ever need more — and advanced incident, problem and change management you are not using.
How we run it. A typical engagement designs the service catalogue the way JSM is built to work: each request type mapped to an underlying work type, with its own portal form, conditional logic and field restrictions, organised into portal groups per function — the same pattern for HR and facilities as for ITSM. Assets schemas are modelled deliberately against real ownership and data sources, sized within the platform's limits rather than sprawling into an unmaintainable CMDB. Automation is designed with your plan's run limits in mind, so rules do not silently stop mid-month.
What you keep. Live portals for each function, Assets schemas with named owners and documented data flows, and an admin team trained to extend the model instead of calling us back for every new request type.
Walk into your renewal window with the analysis already done
The situation. Your annual Cloud renewal quote arrives 60 days before expiry, and that is usually when the questions start: is Premium earning its roughly double per-user price, are the user tiers still right, and why do a dozen apps renew on different dates from the products they sit on? Decided under deadline, the default answer is "renew as-is" — the most expensive answer available.
How we run it. A typical engagement works the levers in order. Tier first: annual subscriptions bill on fixed user tiers, so right-sizing before renewal is the main savings move. Edition second: Standard, Premium and Enterprise are tested against what you actually use — SLA, sandbox, automation limits, bundled Guard on Enterprise. Then apps, whose tiers must match the parent product and, for Jira-family apps, bill at the maximum user count across your Jira products — so the product-tier decision cascades. Finally co-terming: renewals can be aligned onto a single quote alongside a core renewal of at least 12 months, collapsing the scattered dates into one negotiation.
What you keep. A renewal position paper — recommended editions, tiers and app decisions with the reasoning attached — and a co-termed renewal structure, so next year's negotiation starts from a document instead of a deadline.
Stop paying for seats nobody is sitting in
The situation. Your Cloud bill keeps creeping up while headcount does not, and the mechanics explain why: Atlassian bills on product access, not usage, so a user counts the moment they are granted access — even if they never accept the invite or log in. Default groups quietly grant product access to every new user placed in them, synced directory members stay billable until removed — and if you run Atlassian Guard, every user with product access counts towards the Guard bill as well, unless a non-billable authentication policy covers accounts that should not be there, such as service and bot accounts.
How we run it. A typical engagement audits who is billable and why: product access versus site access, the default groups attached to each product role, what your identity sync is pushing in, and which Guard exclusions you are entitled to but not using. Then the group model is rebuilt so access follows an intentional joiner-mover-leaver path instead of accumulating, and the cleanup is timed against your billing model, because on annual tiers savings land when the tier is next set.
What you keep. A cleaned directory and group structure, a documented access model your admins can hold the line on, and a seat count that reflects the people actually using the platform — ready to convert into a lower tier at renewal.
Why Dione
Senior Atlassian expertise. No layers in between.
Enterprise-proven
Our experience comes from inside some of Europe's most demanding environments — global banks and insurers where security, audit and scale are everyday requirements, not edge cases.
Direct access to experts
You work with the people who actually deliver. No account layers, no hand-offs — the consultant you meet is the consultant who does the work.
Platform-first advice
Whether it's consulting, custom development or licensing, our recommendations start from what makes your Atlassian platform healthier — not from what's easiest to sell.
About us
Specialists in Atlassian tools
Dione Technology is an independent Atlassian consultancy. We are passionate about Atlassian and the value its tools deliver when they are done right — and we have spent more than a decade doing it right inside enterprise environments.
As an Atlassian Solution Partner we cover the full life cycle: advising on strategy, building solutions, and managing the licensing that underpins it all.
10+ years
delivering Atlassian in the enterprise
4 of Europe's largest
banks and insurers among our clients
Full life cycle
consulting, solutions and licensing under one roof
Where we work
FAQ
Questions bank teams ask us
Straight answers on the topics that decide Atlassian programmes in regulated environments.
Can Atlassian Cloud meet EU data-residency requirements?
Yes. Atlassian Cloud can pin in-scope product data for Jira, Confluence and Jira Service Management to the EU, and Enterprise plans add organisation-level audit logging, with customer-managed encryption keys available as an add-on. We map residency, encryption and access requirements against your obligations before a migration plan is signed off.
What actually happens to Data Center in 2029?
Atlassian has ended Data Center sales for new customers; existing customers can buy licenses and apps until March 2028, and support ends in March 2029, when licenses expire. Waiting narrows your options — assessing early widens them.
How does a move to Atlassian Cloud fit our DORA obligations?
Under DORA, Atlassian becomes one of your registered ICT third-party providers — so the migration needs vendor risk documentation, resilience evidence and, where Atlassian supports a critical or important function, an exit strategy your second line can defend. We prepare those artefacts as part of migration planning. There is no such thing as a "DORA certificate", so treat any vendor claiming one with caution.
Can we migrate without breaking change control and audit?
Yes — that is the core of a bank-grade migration. Staged cutovers, documented rollback plans and audit-ready change records are built into the plan from day one, so internal audit reviews the migration the same way it reviews any regulated change.
How quickly can we get a defensible migration plan?
A readiness assessment takes weeks, not months — and gives you a defensible answer for your own platform: scope, sequencing, cost and a timeline leadership can sign off. Full migrations are then phased, so disruption is limited to short, planned cutover windows.
Do you work within bank security and procurement requirements?
We have delivered inside BNP Paribas, Société Générale, Barclays and AXA — vendor onboarding, security review and on-site delivery included. We know what your procurement and security teams will ask, because we have answered it before.
A different question? Ask an Atlassian expert.
Every engagement starts with a conversation
Tell us where your Atlassian platform is today and where it needs to be. We will come back to you with a clear, honest view of how to get there.
Talk to an Atlassian expert