8 months post-acquisition and we still have 200 people with active accounts in both tenants. Anyone actually finished one of these cleanly?
Posted by Prestigious-Fun-9680@reddit | sysadmin | View on Reddit | 10 comments
We acquired a smaller company last year. They were on Entra ID + on-prem AD. We're on Okta with Entra for M365. The plan was always to migrate everyone into our tenant by month 4. It's month 8.
Current state:
Acquired employees have their original accounts in the old Entra tenant still active because some line-of-business apps were never migrated and still auth against the old tenant. They also have guest accounts in our Entra for M365 access. And they have Okta accounts provisioned from our HR system for SSO into our SaaS stack. So each of these 200 people has three account objects across two IdPs and one of them is a guest account that keeps expiring and needs manual renewal every 60 days because nobody set up proper B2B policies.
Access reviews are a joke. When auditors ask "who has access to X" and X is in our tenant but the user's identity of record is still the old tenant, I genuinely don't know how to answer that cleanly. The user exists in both. Which one is authoritative? Depends on the app, apparently.
The part that's killing us right now is offboarding. One of the acquired employees resigned last week. We disabled their Okta account. Didn't touch the old tenant. They could still access old-tenant apps for another 4 days until someone noticed.
I know the answer is "finish the migration" but the business keeps deprioritizing the app migrations that are blocking it. So in the meantime, does anyone have a sane way to manage identity across two tenants for users in this limbo state? Specifically looking for how people handle the authoritative source of truth problem and offboarding across both systems simultaneously.
rack_and_stack_42@reddit
Nobody finishes these cleanly. They just reach a point where the remaining exceptions are small enough to manage and everyone agrees to stop calling it a project.
We went through something similar and the thing that actually moved the needle was stopping the approach of "migrate everyone" and switching to "identify who actually needs access to what and shut down everything else."
The first step was pulling a report from both tenants of who logged in during the last 30 days. Anyone with zero activity in the legacy tenant got disabled immediately. That alone cut our list by about 40% because a lot of people technically had accounts but were already working entirely in the new environment.
For the rest, we went department by department with each team lead confirming which tenant their people should be in and which legacy resources they still needed. Gave them a 2 week window to respond. If they did not respond, the accounts got disabled with a 30 day recovery window in case anyone screamed.
The ones that drag on forever are the shared mailboxes, service accounts, and app integrations that nobody owns. Those need someone to manually trace what they connect to. No shortcut for that part.
8 months is not unusual. Most I have seen is 14 months before the legacy tenant was fully decommissioned and even then there were a few service accounts they just left running because nobody was brave enough to turn them off.
30yearCurse@reddit
sobbing in the corner, raising my arm slowly...
Curious201@reddit
this is one of those post-acquisition messes where the technical fix is obvious but the business owner has not finished making the business decision. if those accounts are still active in both tenants after 8 months, i would start by creating a written risk summary with a small table: user, old tenant access, new tenant access, last sign-in, mailbox/data owner, and recommended action. then get an actual sign-off from leadership on who stays, who gets blocked, who gets converted to shared mailbox/archive, and who loses access completely. i would not try to solve this only with scripts because the hard part is not disabling accounts, it is getting someone to accept ownership of the risk and the disruption. once that decision is made, the cleanup is straightforward.
gjpeters@reddit
It's not great but I'd build a custom PowerShell script to automate daily account checks to look for drift or variation.
wtf_com@reddit
Everything is hard because you haven’t finished the transition. If the business is behind the delay then it’s on them but if you haven’t communicated it the. It’s on you.
Create a strategy to get it completed asap; get business approval the execute. The fake injuries are only making it worse.
Arlieth@reddit
If everyone has accounts provisioned on the new Entra tenant then just update the SSO config's IdP on those business apps. If anyone complains then they get to use basic authentication per app. Boo fucking hoo, they can complain to the CIO.
All announcements should have guidance on filing support tickets for access. If you think Tier 1 is going to get overwhelmed then do it one department at a time. Any directors who want to drag their feet can go pound sand or offer to eat IT's opex for maintaining the legacy infrastructure.
dreadpiratewombat@reddit
Why would you have both Okta and Entra? If you’re already in the Microsoft M365 licensing ecosystem why also pay for Okta? It’s just extra complexity.
I’d rationalise your Entra tenant, finish the migration and piss off the Okta component.
Reasonable-Physics81@reddit
Because Okta has the most out of the box connections. I agree either way of getting tid of it asap, their pricing is ridiculous for an "basically an api manager".
bit0n@reddit
If it’s just for access to the line of business app on the old tenant then would making their main account the new one on your tenant and making that a guest account with permissions to the app on the old one work?
tarvijron@reddit
LOL, lmao. No, you are riding the caboose of the pain train. If you can't force the issue of the legacy business line cruft this will just keep going on. If it were me I'd be trying to create some old school 9am "USER CONFIGURATION MISMATCH" email reporting scripts that checks both tenants and pops an alert if a user is inactive in one but active in the other.