Key takeaways
- Run an amnesty first. You cannot migrate what you have not found, and people will not tell you if the question has consequences.
- History and custom assistants do not transfer. Say so early rather than being caught out on the day.
- Migration fails when the old account still does something the new one cannot. Close those gaps before the deadline.
- A stated cutover date does more than any policy document.
Most organisations arrive at this point the same way. Someone works out that a meaningful number of staff have been using AI on personal accounts for a year, with company material in them, and that the organisation has no visibility, no contract and no ability to remove access when someone leaves. The decision to consolidate is easy. The migration is where it goes wrong.
It goes wrong in a predictable way, and the failure is not technical. It is that people keep the old account.
Step one: the amnesty
You need an accurate picture of who is using what, for which tasks, with what data. You will not get it by sending a survey that reads like the opening of a disciplinary process.
What works is a message from someone senior that says three things plainly. We know people are using these tools and we think that is reasonable. We are buying a proper one so that it is safe and the company pays. Nobody is in trouble for anything they have done up to now, and we need honest answers to set it up properly.
Then ask four questions, not fourteen:
- Which tools are you using, and are you paying for any of them yourself?
- What do you use them for in a normal week?
- Have you put company or client material into them?
- Have you built anything you would not want to lose?
The fourth question is the one people skip and it predicts the migration's success better than the others. Someone who has built a custom assistant that reformats reports the way their team likes will not abandon it because a policy told them to.
Expect the numbers to be higher than leadership thinks. Organisations that run this honestly usually find that more than half of knowledge workers are using something, that a portion are paying personally, and that company material is involved far more often than anyone assumed. That result is not a failure of governance. It is the normal state of things and it is why you are doing this.
Step two: be honest about what does not transfer
This is where goodwill is lost. Staff assume that moving to a company account is like being moved to a new laptop, where their material comes with them. It is not.
| Thing | Transfers | What to do |
|---|---|---|
| Conversation history | No | Export before the cutover if anything is worth keeping |
| Saved instructions and preferences | No | Screenshot them, retype in the new account, five minutes |
| Custom assistants someone built | No | Rebuild the two or three that matter, centrally, and share them |
| Uploaded files and project material | No | Download and re-upload where still needed |
| The personal subscription itself | Not applicable | Cancel it, and check nobody is expensing it |
| Familiarity with how it works | Yes | Which is why migration is easier than first adoption |
Say all of this in the first announcement rather than the week before. People plan around known constraints and resent surprises, and the practical cost of rebuilding is genuinely small once someone has been given a fortnight's notice.
Step three: close the capability gaps
Here is the part most migrations get wrong. An organisation buys a business tier, announces the move, and discovers three months later that a third of the team is still using their own account for certain tasks.
The reason is almost never defiance. It is that the new account cannot do something the old one could. Common versions:
- The tier purchased has a lower usage allowance, or excludes a model people had grown used to.
- A capability people relied on, such as image generation, voice, or deep research, sits on a different tier.
- A custom assistant someone built was never rebuilt, so the workflow it supported has no replacement.
- Access was granted to a subset of staff and the rest were left with nothing, which guarantees continued personal use.
The last one is the most common and the most avoidable. Partial rollouts do not reduce shadow usage, they formalise it. If the reason for the migration is governance, then everyone who was using something needs a licence, and the cost of the extra seats is trivial against the exposure of leaving a group with no sanctioned option.
The diagnostic question to ask three weeks after cutover: is there anything you still open your old account for? Ask it in a way that does not punish the answer. Two or three specific gaps will surface, and closing them takes an afternoon. Left unasked, they become permanent shadow usage.
Step four: the cutover
A migration with no date does not happen. The sequence that works over about four weeks:
- Week one. Amnesty and inventory. Announce the plan, the date, and what will and will not transfer.
- Week two. Set up the workspace properly. Training on inputs disabled, retention configured, spending ceiling set, single sign-on connected if you have it, administrator roles assigned to two people rather than one.
- Week three. Invite everyone. Run short role-based sessions covering the three to five tasks each function should use it for, and rebuild the custom assistants worth keeping. Ask people to export anything from the old account now.
- Week four. Cutover. Personal account use for company work stops on a stated day. Update the expense policy so personal AI subscriptions are no longer reimbursable. Send the one-page rule.
Then check in at week seven, when the initial enthusiasm has faded and the real usage pattern is visible.
The expense cleanup nobody remembers
Two small items that save awkwardness later. First, some staff will be expensing personal subscriptions, and those need to stop being reimbursed on a stated date rather than being quietly rejected one month. Second, some departments may have bought their own team plans on a departmental card, which means you have multiple contracts, multiple administrators and multiple retention configurations to consolidate.
Finance can usually produce a list of recurring charges in an afternoon and it is often more revealing than the staff survey. Card statements do not have a reason to be tactful.
What good looks like afterwards
Three months on, a successful consolidation has a specific signature. One contract. One administrator view showing who has access and who has not signed in for a month. Retention and training settings you can screenshot for a client questionnaire. A known monthly cost with a ceiling on it. Offboarding that removes AI access with everything else. And no meaningful personal account usage, because there is no reason for it.
None of that is difficult. It is just a sequence, and organisations that follow it in order tend to finish in a month.
Frequently asked questions
Will people lose their chat history?
Yes. History, saved instructions, custom assistants and uploaded files belong to the account they were created in and do not transfer. Tell people at the start and give them two weeks to export anything worth keeping. Rebuild the two or three custom assistants that genuinely matter, centrally, so everyone benefits.
How do we stop people using their personal account afterwards?
Remove the reasons rather than policing the behaviour. Continued use almost always means the sanctioned account lacks something: a model, a capability, an assistant, or a licence for that person at all. Ask directly a few weeks after cutover and close the gaps you find.
Should we roll out to everyone or start with a group?
If the purpose is governance, everyone who was already using something needs a licence. Partial rollouts leave a group with no sanctioned option, which guarantees the shadow usage continues. The marginal seat cost is small compared with the exposure you were trying to remove.
How long does the migration take?
About four weeks for most organisations: a week for the amnesty and inventory, a week to configure the workspace, a week to onboard and rebuild, then a stated cutover date. Check in again at week seven when the initial enthusiasm has settled and the real usage pattern is visible.
Have the consolidation run for you
We run the inventory, configure the workspace with retention, access and a hard spending ceiling, connect single sign-on, rebuild what is worth keeping, train your people by role, and hand over an administrator view your own team can run. Fixed price, live in 30 days or less.