The Forgotten Step After Cloud Migration

[#1]

Every migration plan has a checklist. Field mappings, cutover windows, rollback procedures, a go-live date circled in red. Exhaustive, by design — because everyone knows what happens if a migration is under-planned.

Almost none of those checklists have a line for what happens after.

Go-live gets treated as the finish line. The project closes, the retro happens, everyone moves on to the next fire — and the Assets schema that just survived months of careful planning gets quietly handed over to no one in particular.

That's the forgotten step. No dramatic failure mode. Nothing crashes on day one. It shows up eight months later as a schema nobody fully trusts, a deletion nobody can explain, or a compliance email with thirteen minutes left in the week and no clean answer.

It's not one problem. It's three, and they compound.

1. Nobody's protecting the data anymore.

Migration ends, and there's a quiet assumption that "Cloud" and "backed up" mean the same thing. They don't — Atlassian's shared responsibility model covers infrastructure, not your specific Assets schema, and not the bulk automation rule that touches the wrong objects three months from now.

2. Nobody owns the schema anymore.

Pre-migration, your schema had months of scrutiny — everyone mapping it, arguing over it, protecting it. Post-migration, that scrutiny disappears overnight, right when the schema is at its cleanest. Without a named owner, a lightweight change process, and a quarterly audit, "clean" doesn't last.

3. Nobody can prove what happened.

Eventually someone asks: who had access, who changed this, when did it happen, what was there before. If the answer is "give me a minute, I think we can reconstruct that" — you've already found the gap.

Why this step gets skipped
Not because it doesn't matter — because it doesn't have a deadline. Migration has a go-live date forcing the work to happen. Backup, governance, and audit trail don't have that pressure. They're easy to plan for "once things settle down." Things never quite settle down enough.

Migration is the visible project. This is the invisible insurance policy — the kind you notice exactly once, on the one day you needed it and didn't have it.

None of this requires a second project. It requires deciding, before go-live closes, that "we migrated" and "we're protected" are two different sentences — and making both true before the retro happens, not eight months after.

Further reading: what's actually covered under shared responsibility · what post-migration governance looks like · what a real audit trail looks like

[Elena_Elevatic]

hey @Salome Ivaniadze Twinit This matches what we see with JSM Assets specifically — the schema gets treated like part of the migration deliverable, so once cutover is signed off it falls into a gap between "IT owns Jira" and "nobody owns this specific object schema." One thing that's helped: naming the Assets schema owner in the same RACI as the migration itself, before go-live, not as a follow-up task.

I wrote about the monitoring-stops-at-go-live pattern specifically here, if useful.