Migration to Atlassian Cloud

The most frequent one is arriving without a proper inventory: active projects, apps in use, integration dependencies, automations and scripts. This is followed by the absence of a clear owner per area (who decides, approves and maintains), underestimating the cleanup work involved (duplicated fields, unused workflows, inherited permissions) and failing to allow time and a plan for communication, training and post-launch stabilisation.

By involving key teams from the diagnostic phase, not at the end of the project: new workflows are designed with them, not for them. Training is also planned by user profile, because a platform administrator has very different needs from a business user managing tickets. Support does not end at go-live: the first weeks of live operation are when the most questions arise and when adoption is either consolidated or lost. When there is no change management plan, a migration can go technically flawlessly and still be perceived as a failure.

There is no 1:1 correspondence between what exists in Data Centre and what is available in Cloud. Many Data Centre Marketplace plugins have no Cloud version, and even when they do, they do not behave in the same way. Automations or scripts that rely on direct access to the database or file system cannot be transferred as-is. Replicating them all in Cloud is often not possible, it tends to generate additional cost and simply carries the same technical debt across to the new platform.

The approach, therefore, is not to produce a checklist of customisations, but a proper inventory: what has a native Cloud equivalent, what can be covered by a Marketplace app, and what, when no standard alternative exists, requires bespoke development.

In phases, with criteria defined before you start: what is essential from day one, what can go into the backlog and in what order things should be tackled. This way, testing (both technical and with key users on real use cases) forms part of the process rather than being a final formality. Migrating quickly into an environment without sufficient control costs more to fix afterwards than planning properly from the outset would.

Security and identity management. Infrastructure becomes Atlassian's responsibility, which forces a rethink of areas that were previously taken for granted. The direct LDAP/AD integration used in Data Centre translates to SSO with SAML and automatic user provisioning via SCIM in Cloud. The permissions model also changes, and Atlassian Guard adds a layer of control that needs to be configured from the start. Additionally, in regulated sectors, data residency is managed through Atlassian's Data Residency feature, a matter to be validated with legal and security teams.

No, but it requires careful decision-making: not all historical data adds value, and some of it may simply be accumulated noise. Losing relevant history, or migrating it incorrectly, has real consequences: issues without context, decisions without evidence and processes that cannot be justified in an audit. Depending on the data source, migration may be straightforward or may require bespoke work: data transformation, field mapping and reconstruction of relationships between issues, attachments and approval trails.

A correct migration meets the technical objective: the data is there, the systems work, users can operate. That is necessary, but not sufficient. It is excellent when the resulting environment is better than the original, not just equivalent: when the opportunity is used to standardise processes, define governance and eliminate technical debt. If, after migrating, users work more effectively and IT manages more efficiently, it was excellent; if it simply works, it was correct.

Certified professionals in the Atlassian ecosystem with experience in migrations, implementations, integrations and bespoke development. The difference lies in cross-functionality: having DevOps, AI and bespoke development capabilities within the same team makes it possible to address, without relying on third parties, the needs that almost always arise beyond the platform itself: automation, integration with corporate systems, identity management and advanced reporting. This is reflected in both deadlines and outcomes.