Atlassian is easy to start, hard to sustain

The first few weeks of an Atlassian platform are often encouraging. A team creates a Jira project, adapts a workflow, opens a Confluence space or structures a Jira Service Management portal. The result is visible quickly and addresses a real need.

The difficulty comes later, when that initial success has to become a shared system. Other teams arrive with their own constraints. Rules evolve. Integrations multiply. A configuration designed for twenty people has to remain clear for hundreds or thousands of users.

The question is no longer whether the tool works. It is whether the platform can keep evolving without becoming impossible to understand.

Configuration debt is not immediately visible

A new request rarely looks excessive in isolation: add a field, copy a workflow, create a status, grant an exception or install an app. Each request may be entirely justified.

Debt emerges as those decisions accumulate. Two almost identical fields begin to carry different meanings. A copied workflow no longer benefits from improvements to its original model. An automation works around a local issue, then becomes a critical dependency that nobody feels safe changing.

This debt is not only technical. It creates very practical costs:

• users hesitate between choices that appear to mean the same thing;
• administrators spend more time understanding than improving;
• changes become risky because their effects are difficult to predict;
• reports combine data that no longer carries quite the same meaning;
• new use cases inherit exceptions whose original purpose is unknown.

A platform can therefore be available, fast and backed up while still being unhealthy.

Measure health, not only operation

I find it useful to assess a platform through five simple questions.

Are the use cases still understandable?

Someone joining a team should be able to understand where a process starts, what information is expected and what the main states mean. If that understanding depends entirely on oral knowledge transfer, the configuration is not carrying its intent on its own.

Do important objects have owners?

A workflow, permission scheme, automation or critical app needs an owner who can explain its purpose and make decisions about its evolution. Without an owner, age becomes reason enough to keep everything.

Are exceptions explicit?

Healthy governance does not necessarily impose a single model. It distinguishes between standards, necessary variations and temporary exceptions. Difference is not the problem. Invisible difference, with no decision or review date, is.

Can decisions be made without configuration archaeology?

Before a change, the team should be able to identify dependencies, affected users and likely consequences. If every improvement requires days of investigation, the platform has lost part of its ability to adapt.

Are teams actually using what was built?

A deployed capability is not necessarily an adopted one. Workarounds through spreadsheets, messaging or parallel documents often reveal a gap between the configured process and the work people actually do.

Governance is about organising trade-offs

Governance is sometimes reduced to a committee that approves or rejects requests. It becomes much more useful when it makes trade-offs predictable.

Before adding a new configuration, a few questions should have clear answers. What problem does it solve? Does the need already exist elsewhere? Can a standard be extended? Who will maintain the solution? How will we know whether it is still useful in a year?

These questions are not designed to slow teams down. They prevent a local answer from creating lasting complexity for the wider organisation. They also give administrators a way to say “yes, in this form” instead of forcing a binary choice between accepting every request and freezing the platform.

A regular review cycle helps. It may be quarterly for the most structural objects and more frequent for critical automation or integrations. The point is not to build an exhaustive inventory for its own sake. It is to identify unowned objects, duplication, declining use and decisions that no longer match reality.

Adoption is a design signal

Adoption is often treated as a phase that starts after delivery: communication, training and support. It should also inform design.

When a team avoids a field, rebuilds a report outside Jira or maintains a parallel space, it is worth understanding why. The issue may be training, but it may also be inappropriate granularity, overly technical language or a process that asks for too much effort in return for too little perceived value.

The article on why a tool migration is only as valuable as the visibility it creates explores this relationship between continuity, clarity and use. The Xray migration project also shows why a technical transformation should be judged through what teams can see and do afterwards.

A discipline for the long term

Sustaining a platform does not mean preventing change. It means preserving the ability to change: standards clear enough to be shared, exceptions visible enough to be reconsidered, identified owners and use observed beyond go-live.

The quality of an Atlassian platform is revealed less by the number of features enabled than by the ease with which an organisation can still explain its choices, challenge them and evolve them.

For the company’s delivery scope, Ovyka’s Atlassian expertise page (s’ouvre dans un nouvel onglet) (opens in a new tab) covers integration, governance and support, while its guide to choosing an Atlassian partner (s’ouvre dans un nouvel onglet) (opens in a new tab) sets out criteria to consider in different situations.