Skip to content
Talk to an architect
Platform and migration

Migration is where identity debt becomes visible.

A migration moves an Atlassian estate from Data Center to Cloud, or consolidates several instances into one. Atlas Bench runs the assessment, the identity mapping, the standardization decisions, and the cutover, so the destination is a platform someone owns rather than the same estate at a new address.

Data Center to Cloud, cloud to cloud, and third-party tools into Atlassian, with the identity and governance workstreams built into the scope rather than bolted on afterwards.

before after one platform separate instances, separate permission models L1 L2 L3 L4

The problem

A migration is the only moment when someone is funded to look at everything. Every user, every group, every integration, every automation that has been running unattended since the person who built it left.

Most migrations waste that. The plan is to move what exists and fix it later, and later never gets funded. The permissions arrive on the far side exactly as broken as they were on the near side, now in a platform where they are harder to unpick.

What the work is

Estate inventory and assessment

Every instance, app, integration, automation, and custom field in scope, with the ones nobody owns identified before a plan is written.

Approach and sequencing

Which instances merge, which move as they are, and in what order, with cutover windows agreed against your business calendar rather than ours.

Identity workstream

Access decided before anything is copied. SSO, group structure, and provisioning stood up on the target so users land where they belong.

App and integration rationalization

Marketplace apps and third-party integrations assessed against actual usage, so cost does not migrate along with the data.

Data migration and validation

The move itself, rehearsed in a sandbox first, with reconciliation on both sides and a tracked defect log rather than a spot check.

Governance on the far side

Permission, workflow, and field schemes configured on the target so the estate stays maintainable by a small administration team.

Cutover and hypercare

A cutover plan, communications, go-live in sequence, and a hypercare window before the platform transitions to your team.

How it runs

  1. Assessment

    3 to 4 weeks

    Discovery across every instance in scope, producing an inventory, a risk register, and a recommended sequence. This is the deliverable that makes the rest estimable.

  2. Design and build

    6 to 10 weeks

    Target configuration built in a sandbox: identity, permission schemes, workflows, and the migration runbooks. Nothing touches production.

  3. Test and remediate

    3 to 4 weeks

    Structured user acceptance testing against the sandbox, with defect triage and configuration remediation across everything in scope.

  4. Cutover and hypercare

    3 to 4 weeks

    Go-live in the agreed sequence, post-cutover validation, then hypercare with the team who built it before handover.

What you get

  • A full inventory of instances, apps, integrations, automations, and custom configuration in scope
  • A migration approach with sequencing, cutover windows, and a named risk register
  • Target identity configuration, with SSO and group provisioning live before data moves
  • A rationalization decision log recording what carries forward, what consolidates, and what is retired
  • A sandbox build of the target estate, used for testing before any production change
  • Reconciliation on both sides of the move, with a tracked defect log
  • Permission, workflow, and field schemes configured so the estate is maintainable after handover
  • A cutover plan, communications, and a hypercare period before transition to your team
  • As-built documentation and administrator training
Start here

Four layers. One accountable system of work.

The layer everyone wants sits on the layer everyone ignores. Every engagement starts at one of these four, and whichever door you come through, the other three are still load bearing.

L4

Agents and Automation

Rovo, Agents in Jira, Forge, MCP with Claude and Copilot, agent lifecycle, usage and cost governance.

2 services

Atlassian Anthropic
L3

Governance and Change

Permission architecture, audit and compliance, ITSM and change control, change management, strategic reporting and budgets.

4 services

Atlassian Guard Jira Service Management Strategy Collection Jira Align
L2

Platform and Migration

Migration of every kind, tool consolidation, licensing, standardization, the system of work.

3 services

Atlassian Miro AWS Azure
L1

Identity and Access

Human and non-human identity, SSO, SCIM, least privilege, access reviews, Guard cleanup, Agent SSO readiness.

2 services

Atlassian Guard Okta

load-bearing, bottom to top

Proof

Cloud Migration

Atlassian Cloud Migration specialization, held alongside the Service Management specialization.

Atlassian Partner Directory, 2026.

Questions we get

Data Center to Cloud, or something else?
Both. Data Center to Cloud, cloud to cloud after an acquisition, and third-party tools into Atlassian. The pattern is the same either way: the move is the moment the underlying model gets decided.
Can you migrate without consolidating?
Yes, and sometimes that is the right call. But a like-for-like move carries the permission model with it. If the estate is already hard to administer, moving it makes that permanent rather than better.
What happens to our Marketplace apps?
Each one is assessed against actual usage. Some have a cloud equivalent, some are replaced by native capability, and some turn out to be unused. Migrating an app nobody opens is a cost you carry for years.
How long does it take?
It depends on the number of instances and the state of the configuration, not on the volume of data. The assessment exists to produce a defensible answer to exactly this question.
Do you migrate history?
Usually, but not always, and it is worth deciding deliberately. Some engagements start clean in templated projects and preserve the old estate read-only, which is faster and produces a better result.
Who runs it afterwards?
Your team, with documentation and administrator training as deliverables. If you would rather not, the run layer is a service in its own right.
featured guide

Most teams ask for a phased migration because it feels safer, but when spaces share links, roll-ups, scripts, and global apps, phasing splits one connected system into two broken ones. For instances like that, a single well-rehearsed cutover carries less risk, less coordination, and fewer surprises than moving in batches.

Read the guide

Recent resources

Find out what you are actually running.

Fixed scope. The assessment reads the estate as it is: instances, schemes, licensing, and the decisions a migration would force you to make anyway. You get the findings, the ownership gaps, and the order to close them in.

Get an agent readiness assessment

By sending this you agree to our privacy policy.

Not ready? Talk to an architect