Move to Cloud without moving all the debt

A move to Cloud creates a clear deadline. A target has to be chosen, a cutover prepared and business continuity demonstrated. That constraint is useful: it forces an organisation to examine a platform shaped by decisions that may have accumulated over many years.

The temptation is to treat the operation as a reproduction. The closer the target looks to the current state, the easier the change seems to explain. But a faithful copy can also carry abandoned projects, unowned fields, opaque permissions, redundant apps and automation that nobody can still justify.

Cloud does not remove that debt. It creates an opportunity to decide what genuinely deserves to move.

Turn the inventory into a decision map

A useful inventory does more than count projects, spaces, users or attachments. It connects every important element to a use case, an owner and a decision.

For an Atlassian platform, this view usually covers several layers:

• products, Jira projects, Confluence spaces and service portals;
• users, groups, roles, permissions and identity mechanisms;
• workflows, fields, screens, request types and automation;
• Marketplace apps and the capabilities they provide;
• integrations, scripts, data exchanges and external dependencies;
• retention, security and traceability obligations;
• business journeys that must continue to work.

The purpose is not to produce the longest possible spreadsheet. It is to make trade-offs explicit. Four decisions are often enough to structure the work for each group of elements: move as is, transform, archive or retire.

Those decisions need an owner and a rationale. Without them, the implicit rule becomes “move everything to be safe”. That is exactly how an organisation preserves complexity that nobody actively chose.

Rationalise without creating an endless programme

A migration is not always the right time to redesign every process. Chasing the perfect target can delay cutover indefinitely and multiply simultaneous changes.

It helps to separate three categories:

1. issues that must be fixed before migration because they block or weaken the move;
2. elements worth rationalising now because the benefit is clear and the risk controlled;
3. elements that can be carried temporarily and addressed through a documented improvement path.

This distinction protects the schedule without abandoning quality. It also prevents a transformation from being described as “like for like” when it actually introduces changes in features, security or user experience.

Rehearse to learn, not only to reassure

A test migration is not a ceremonial rehearsal designed to confirm the original plan. It is a measurement instrument.

It reveals the actual duration of operations, imperfect conversions, app behaviour, permission differences and steps that are still manual. Most importantly, it exposes gaps between the theoretical inventory and the use cases encountered in real data.

Each run should therefore produce something verifiable: an exception log, a transformation decision, a measured duration, an improved test scenario or an updated runbook. Replaying exactly the same process and hoping for a different outcome does not create additional confidence.

Cutover criteria should also be agreed before the final rehearsal. Which gaps are blocking? Who can accept residual risk? What threshold requires a rollback? A go/no-go decision is stronger when it follows these rules instead of relying on optimism on cutover day.

Build waves around dependencies

Organising waves by team or country is easy to understand, but it is not always enough. Two apparently separate scopes may share an app, a synchronisation, an identity service or a cross-platform report.

A coherent wave accounts for criticality, dependencies and the ability to learn. The first scope should be representative enough to test the method, but controlled enough for gaps to remain recoverable. Later waves should reuse what has been learned instead of starting again.

This approach treats the platform as a system. It reduces the risk of declaring a scope “migrated” while it still silently depends on a component left behind.

Test end-to-end business journeys

Volume comparisons are essential: numbers of projects, spaces, issues, attachments or users. But matching row counts do not prove that work can resume.

Acceptance testing needs to follow real situations: create and process a request, find knowledge, trigger an automation, approve a change, produce a report, follow a relationship between Jira and Confluence, or confirm that a user sees exactly what they should.

These tests need people who understand the process, not only the migration team. They turn a technical check into evidence of continuity. The article A tool migration is only as valuable as the visibility it creates develops the same principle through the lens of use and decision-making.

Prepare hypercare before cutover

Hypercare should not be a vague period in which the project team simply remains available. Reporting channels, priorities, owners, decision times and the distinction between an incident, a misunderstanding and an enhancement request all need to be defined.

This preparation prevents the first days from being consumed by an unqualified stream of requests. It also helps identify adoption signals: recurring difficulties, attempts to find removed capabilities, workarounds or targeted training needs.

The case of a large Atlassian platform moved to Cloud brings together the public facts of a transformation delivered in waves, with rehearsals, business testing and hypercare. The detailed case published by Ovyka (s’ouvre dans un nouvel onglet) (opens in a new tab) presents the platforms’ scale, the delivery approach and the outcomes observed.

A migration is a series of decisions

Success does not come from a promise of perfect replication. It comes from a set of traceable decisions: what enters the target, what changes, what remains out of scope, what has been proven and what will still be monitored after cutover.

Moving less is not always the right answer. Moving deliberately almost always is. Cloud then becomes more than a new technical destination: it becomes a clearer starting point for what comes next.