Cleanup is an event. Drift is a condition.

When I asked Matthew Sinclair what governance actually means once a Jira estate reaches thousands of projects, his answer was not about control, and not about rules.

"Governance is more than safety. It's bringing order out of chaos."

— Matthew Sinclair

Read that sentence twice and the problem with cleanup projects falls out of it. Order is a state. Chaos is a process. A cleanup project produces the state once, on a Friday, and then leaves the process running.

Almost every Jira instance that has been in use for years tells the same story. At some point it becomes too confusing to work with. Someone sets up a cleanup project. Fields get merged, workflows get aligned, status values get clarified. Afterwards things are better.

Two years later it looks the way it did before.

The two clocks do not run together

That is not the result of poor work. It happens because cleanup and drift do not move at the same speed.

Cleanup happens on a fixed date. Drift happens every day, in small steps that each make sense on their own. One team needs a field. A vendor needs its own workflow. A department needs an additional status. None of these decisions is wrong.

Together, over a few years, they rebuild exactly the condition the cleanup was meant to remove.

Each cleanup pulls the line down on a single date. The slope between two cleanups is what actually decides where the instance ends up.

Nothing here is a failure. Nobody was careless, nobody ignored a policy, no admin lost control of the instance. Every individual request was reviewed and approved by someone doing their job properly. The system did exactly what it was designed to do.

The instance is confusing anyway.

What you cannot see

Anyone cleaning up an older instance runs into the same limit.

It is visible that three fields hold the same value. What is not visible is when they appeared, who requested them, and which one still serves a purpose.

Without that information a decision turns into a negotiation. And in a negotiation, whoever objects loudest keeps their field.

This is why cleanup is so exhausting and why it holds for such a short time. Deleting is not the hard part. Justifying is.

The cleanest instance you will ever have

There is exactly one moment when this is not true, and most organizations spend it on something else.

A new Cloud instance, on the day it goes live, is the cleanest your configuration will ever be. The number of objects is manageable. Responsibilities have just been assigned. Every field in there was put there on purpose, recently, by someone you can still name.

Nobody will ever be able to say that about this instance again.

Migration does not postpone the drift problem. It splits your timeline in two. Whatever configuration travels, travels. Whatever history sat in the previous environment arrives only in fragments, if it arrives at all. The new instance therefore starts in a state that can be seen but no longer explained.

What follows is the part Kevin Behrens described in our conversation about life after go live. His words: "Migration is a milestone, not a finish line." What gets underestimated afterwards is the friction that platform sprawl creates. Normal operations resume. And normal operations mean the next entirely reasonable request arrives next Tuesday.

That request is not a problem. It is the first entry in a record you either have or do not have.

A camera cannot show the room before it was switched on

An event based record captures what happens from the moment it is set up. Whatever happened before stays outside of it.

This is not a limitation that more effort could work around. It is the nature of the thing. A camera does not show what happened in the room before someone switched it on.

In practice this means the moment of installation is itself a decision. Every week without a record is a week that nobody will be able to account for two years from now. That gap cannot be closed later, not by a tool and not by an experienced consultant.

"We will just clean it up again"

This is the standard answer, and it is not wrong. It is just fragile in three specific ways.

The second cleanup is harder than the first. More objects, more owners, more teams who have built something on top of the current configuration. The cost of the cleanup rises with exactly the thing you postponed it for.

It depends on somebody being willing to run it. A cleanup project is unpopular work with no visible output. It competes with incidents, migrations and audits, and it loses that competition until it becomes urgent, which is well past the point where it was cheap.

It solves the state, not the slope. After the cleanup the instance is tidy and the process that untidied it is still running, unmeasured. You have bought yourself the same two years again, at a higher price.

This is the same mechanism we described in Why Jira Governance Fails Long Before Anyone Notices. Enterprise governance rarely fails through one bad decision. It fails through hundreds of reasonable ones drifting apart.

What changes when the record is continuous

It is worth being plain about this part. At MetaFrazo we built the product on this observation. We record what happens to the configuration of a Jira Cloud instance as a sequence of individual events, starting on the day of installation.

The first effect is unspectacular and still the most important one. Drift becomes countable instead of noticeable. Configuration activity per week is a number, which means a quiet quarter and a busy one are finally distinguishable, and the burst that follows a cleanup looks like what it is. The value is not the shape of any particular quarter. It is that the shape exists at all, and that the next one can be held against it.

Configuration Change Volume Over Time. Configuration activity per week, over one quarter.

The second effect addresses the question cleanup projects fail on. Every configuration event is there individually: the date, what was changed, whether it added something or removed something, in which project, and by whom. Filtered down to a single object, that record is the object's biography, and the discussion about whether the field is still needed turns into a question that can actually be answered.

Configuration Change Event Audit Log. Every configuration event in time order, classified as additive or destructive.

The third effect is that drift turns out to have an address. It is not spread evenly across the instance. A handful of projects carry most of it, and they are usually not the ones people name when asked. That changes what a cleanup even is: not a campaign across the whole estate, but a short list.

Governance Maturity Score by Project. Drift is not distributed evenly, which means the cleanup has an address.

None of those three is a decision. Together they are the difference between knowing that your instance changed and being able to say what changed, where, and at whose hand, on a date that falls well outside anyone's memory.

What this does not solve

It does not make your instance clean. It makes the drift visible, and a person still has to decide what to do about it.

It does not remove the negotiation either. It changes what the negotiation is about. Instead of arguing over competing recollections of a field, everyone is looking at the same history of it.

And it does not reconstruct anything that predates the installation. The record starts on the day it is switched on. That limitation is the entire argument of this article rather than a footnote to it. Whatever your instance cannot explain about the last two years, no product will recover.

What is still open is where the record begins. That boundary moves forward every single day.

One thing you can do without any product

Open your custom field list and take the first twenty fields.

For each one, answer two questions without asking anyone: when was it created, and who owns it today.

Count how many of the twenty you can answer both questions for. The exercise takes about ten minutes and the number it produces is your current traceability.

If it is low, that is not a finding about your team. It is the expected result in any instance that has been running for a few years without an event record. The useful part is knowing the number before a migration, an auditor, or the next cleanup project asks you for it.

What follows from this

Cleaning up a grown instance solves yesterday's problem. Recording from the day of setup prevents the problem of the day after tomorrow.

Both are worth doing. Only the second one lasts.

And the most obvious opportunity is the start in a new environment, because an instance never gets cleaner than that.

---

Matthew Sinclair and Kevin Behrens were interviewed in our series "5 Questions in the Atlassian Universe".

MetaFrazo is available on the Atlassian Marketplace, with a 30-day free trial on every edition. It records from the day it is installed.