For a while, homemade assistants felt like progress.
Someone built a helper for a recurring job. Someone else shared it. A few became quietly essential. Nobody ran an inventory, because the platform made sharing feel easy enough and the work was moving.
Then the platform changes.
Features move. Sharing rules tighten. What used to transfer cleanly doesn't. Leaders look around and realize the company doesn't have a few assistants. It has a sprawl: some heavily used, some abandoned, some impossible to hand to the next person.
That isn't mostly a migration-tips problem. It's homegrown assistant sprawl meeting a platform shift: assets without owners, without triage, and without a decision about what deserves to become a maintained internal tool.
Homemade assistants usually appear because official enablement left a vacuum. People filled it. That inventiveness is real value.
It becomes risk when:
The goal is not to shame the builders. The goal is to decide what survives on purpose.
We keep seeing the same picture without needing a named account to make the point.
A lot of people have shared homemade assistants that now need to move. The sensible starting point is the ones most heavily used. A governance group has to decide what belongs as a maintained capability versus what should stay a lighter project. Someone notes the sharing model itself may not carry over cleanly, so the team will have to figure out ownership and transfer again, not only click a migrate button.
That is one problem, not a weekend of DIY conversion. You don't need a how-to for every assistant first. You need triage.
Start with use and consequence, not nostalgia.
Worth a serious look:
Usually park or retire:
Rebuild the few. Archive the rest in a way people can find if needed. Do not migrate sprawl one-for-one and call it governance.
Both, on different questions.
If only the council decides, you will retire useful tools people depended on. If only users decide, you will rebuild everything that has a fan base, including the abandoned cousins. Triage needs both voices in one pass.
Unowned assistants should not quietly become production infrastructure.
A clean rule:
People sometimes volunteer when the alternative is losing a helper they rely on. That is useful. What is not useful is keeping unowned assistants in circulation until the next platform change creates another emergency.
Maintained internal tools are few on purpose. Sprawl was the temporary bridge. Triage is how you stop living on the bridge.
Which homemade assistants are worth rebuilding properly?
The ones with heavy use, real downside if they break, a clear job, transferable logic, and an owner candidate. Park duplicates, unexplained experiments, and helpers that only work with one person's private context. Rebuild the few, not the folder.
Who decides: a council or the people who use them?
Users inventory and rank by use and consequence. A council or governance group decides what becomes maintained capability versus lightweight project versus retire. Platform owners decide what the new environment can support. One pass with both voices beats either side alone.
What happens to assistants nobody owns?
No owner means no rebuild commitment and no official label. Offer a short claim window, then archive and remove from shared promotion. Unowned assistants should not become silent production infrastructure.
If the pattern on this page sounds familiar, start with the free AI Operations Reality Check. One everyday workflow. No pitch deck.
If you want a bounded diagnostic and a written next-step memo, the AI Operations Review is the paid step after that ($997, not an open-ended contract).