Migration Playbook: Key Lessons from Enterprise Atlassian Cloud Migrations

Migration Playbook in the Real World

I enjoy migration weekends.

That might sound strange to anyone who has worked on one.

Most people assume the migration weekend is the most stressful part of a migration programme. In reality, if you've done the preparation properly, it is usually one of the calmest points in the entire project. no one chasing you, milestones and checkpoints, but usually just the core team on call.

By the time you reach migration weekend, most of the difficult decisions should already have been made. The Discovery and Assessment work should be complete. Risks should be understood. Stakeholders should know what is happening. Testing should have been completed. The migration plan should have been reviewed, challenged and refined multiple times.

If you're still trying to solve major problems during the migration weekend itself, you've probably left things too late.

After working on several Atlassian migrations, I've found that successful programmes have far more in common than they do differences. The tooling changes, the organisations change, and the technical challenges change, but the things that make migrations successful are remarkably consistent.

Discovery and Assessment Matters More Than People Think

Most migration issues are not discovered during migration. They are discovered during Discovery and Assessment.

The organisations that have the smoothest migrations are usually the ones that spend time understanding what they actually have before they start discussing how to move it.

What integrations exist? Whi

ch customisations are genuinely business critical? How are teams using the platform today? What reporting depends on the existing setup? What assumptions have become embedded in day-to-day operations?

None of these questions are particularly exciting, but they are usually where the real risks sit.

On one recent enterprise migration, the technical challenge was not simply moving Jira and Confluence from Data Center to Cloud. The organisation also needed to split Jira into multiple Cloud sites based on the way different parts of the business operated, while keeping Confluence in a single Cloud environment. That immediately introduced additional questions around project categorisation, cross-site links, application configuration, reporting, permissions and user access.

Those are the sorts of issues that need to be understood before implementation starts.

A good Discovery and Assessment phase is not simply about producing a report. It is about reducing uncertainty before delivery starts.

Communication Is a Workstream

One lesson that comes up repeatedly is that communication is not something that sits alongside the project. It is part of the project.

Executive sponsors, project stakeholders, administrators, technical teams and end users all need different information at different points in the programme.

Good communication creates confidence.

More importantly, it creates opportunities for people to raise concerns early, while there is still time to address them.

On larger migrations, the communication model has to cover far more than project status updates. It needs to include change windows, user readiness, application owner involvement, escalation routes, support arrangements, decisions still required, and known differences between Data Center and Cloud.

In one programme, success depended on close coordination between internal platform teams, application owners, Atlassian support, security stakeholders and the migration delivery team. The technical migration plan was important, but the communication plan was what kept everyone aligned enough to execute it.

Many of the most significant issues I've seen on migration programmes were not technical problems. They were communication problems.

Governance Enables Delivery

Governance sometimes gets a bad reputation.

Nobody enjoys unnecessary process.

However, enterprise migrations involve large numbers of stakeholders, competing priorities and significant business risk.

Clear ownership, RAID management, acceptance criteria, escalation paths and Go / No-Go decisions provide a framework for making decisions quickly and confidently.

The larger the programme becomes, the more valuable that framework becomes.

A good example is UAT sign-off. In a complex migration, it is unlikely that every minor issue will be closed before the production decision. What matters is that issues are categorised, understood, and formally accepted where appropriate. Critical and major items need clear treatment. Minor and cosmetic items need either a fix plan, workaround or explicit agreement that they are not blocking.

That is not bureaucracy. That is how you avoid having the same debate repeatedly during the final week.

Without structure, teams often spend more time debating decisions than making them.

UAT Is Where Confidence Is Built

Technical validation tells you whether the data migrated.

User Ac

ceptance Testing tells you whether the organisation can operate.

Those are two very different things.

A successful UAT phase allows stakeholders to understand what has changed, what still needs attention and whether they are comfortable proceeding to production.

On a recent migration, UAT was not limited to checking whether issues and pages existed in Cloud. It also needed to validate areas such as:

• Jira projects split across multiple Cloud sites

• Confluence content and macro behaviour

• Xray test management data

• Advanced Roadmaps hierarchy considerations

• Marketplace app behaviour

• Reporting and Power BI dependencies

• GitLab, Miro and other integration touchpoints

• User access and SSO behaviour

  
  

Some of these items could be validated technically. Others required business users and application owners to confirm that the migrated environment supported their day-to-day work.

The objective is not perfection.

The objective is informed decision making.

In most programmes there will still be open items at the end of UAT. The important thing is that they are understood, documented and accepted.

Technical Complexity Is Usually in the Edges

Migration tools are very good at moving the standard parts of the platform.

The difficult areas are often the edges: integrations, apps, reporting, permissions, historical configuration and behaviours that have built up over time.

A few examples from recent enterprise migration work include:

• Handling large attachment volumes by using attachment pre-loads before the final production migration window.

• Sequencing migrations carefully where different Jira sites had different app requirements.

• Managing Confluence macro and diagram issues through a combination of testing, repair activity and vendor escalation.

• Rebuilding or validating external integrations after migration rather than assuming they would behave the same way in Cloud.

• Using read-only periods, backups and rollback checkpoints to protect the production migration window.

• Reviewing user access carefully so that Day 1 users had appropriate access without accidentally opening access more broadly than intended.

None of these examples are unusual in enterprise environments.

They are exactly why the migration plan needs to be detailed, owned and tested.

Migration Weekend Should Be Boring

By the time migration weekend arrives, the project should largely become an exercise in execution.

Everyone should know their role.

The communications should already be prepared.

The rollback plans should already be understood.

The migration runbook should already have been rehearsed.

When that preparation has been done properly, migration weekend becomes surprisingly calm.

There will always be issues. There will always be unexpected questions. But they tend to be manageable because the hard work was completed beforehand.

In practice, a good migration weekend often looks like a long sequence of controlled activities: final backups, read-only changes, data migration, application checks, integration validation, user access updates, smoke testing, stakeholder updates and go-live communications.

It is not glamorous.

That is the point.

Hypercare Matters

Going live is not the finish line.

It's simply the point where real users begin interacting with the new environment.

There will always be questions, configuration tweaks, integration fixes and user support activities during the first few days and weeks.

A good hypercare period helps bridge the gap between a successful migration and successful adoption.

Both are important.

For large organisations, hypercare also provides a controlled way to separate genuine migration issues from new requirements, training gaps or normal differences between Data Center and Cloud.

That distinction matters because, without it, the project can quickly become an open-ended improvement programme rather than a migration close-out.

Final Thoughts

Whenever someone asks me what makes a migration successful, my answer is usually the same.

Preparation.

Not tooling.

Not technology.

Not the size of the migration.

Preparation.

I am still of the generation that quotes the line - I love it when a plan comes together!

The programmes that succeed invest time in Discovery, Assessment and Testing, communicate effectively, engage stakeholders early, test thoroughly and maintain clear ownership throughout delivery.

Get those things right and migration weekend becomes one of the easiest parts of the project.

And that's probably why I enjoy them so much.

I'm already looking forward to the next one. It gets me out of walking the dog for a weekend, which is becoming increasingly difficult to justify as a business benefit.