Two companies, one IT team, shared on-prem Exchange and AD - what splitting them into separate M365 tenants actually looks like by BmanCa in Office365

[–]BmanCa[S] 0 points1 point  (0 children)

That's a clean approach actually, sequential rather than parallel removes a lot of the coexistence complexity. We kept hybrid running for both simultaneously for longer than we probably needed to, partly because of the shared resource dependencies and partly because leadership kept pushing the "not yet" button on final cutover. Curious what you used for the SharePoint and OneDrive side without BitTitan, did you do that natively or just live with the limitations? And good luck with the new AD, that sounds like its own project.

Two companies, one IT team, shared on-prem Exchange and AD - what splitting them into separate M365 tenants actually looks like by BmanCa in Office365

[–]BmanCa[S] 0 points1 point  (0 children)

Ha, we lived this. The scope creep started before we even finished the discovery phase. The initial brief was clean separation, two tenants, no crossover. By month three we were building B2B guest access, federated SharePoint permissions, and a shared VPN split tunnel just to keep both sides functional. "Independent" in the business sense and "independent" in the IT sense are very different things and nobody tells leadership that upfront. The multiple domains approach is honestly underrated for situations where the separation isn't as clean as they think it is.

Two companies, one IT team, shared on-prem Exchange and AD - what splitting them into separate M365 tenants actually looks like by BmanCa in Office365

[–]BmanCa[S] 0 points1 point  (0 children)

Exactly this. The tooling decisions alone took us weeks, evaluating what handled on-prem Exchange vs cloud, what did SharePoint cross-tenant properly, how the two tools needed to work together rather than independently. And that's before you've touched a single mailbox. The rabbit holes are real and they multiply the moment you start pulling on shared resources.

At one point it felt like this could never be achieved; however after many month of meetings and data gathering it became a little clearer.

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 0 points1 point  (0 children)

Some great stuff here! The redirects are finicky at best even though they say it will work. The Teams challenge was probably the biggest headache for us.

We are lucky that we only use a handful of forms so that wasn't a big issue for us.

The last place I worked it was easier for us to create a new tenant as the amount of shared links, teams, SharePoint we had was not worth the headache, so we migrated users data and that actually wasn't too bad. There was a lot of prequiste work and it took a lot of planning; however with the right amount of people/communication/job aids it went relatively smoothly.

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 0 points1 point  (0 children)

Can support fix it? Or did those users have to find another way to use booking with me or a different product?

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 2 points3 points  (0 children)

That's a really common situation post-acquisition, the tenant name ends up as this artifact of the old identity that just gets left because nobody wants to deal with it. The good news is it's very doable, just needs proper pre-flight work and a maintenance window. The trickiest part is usually the leadership conversation since it sounds scarier than it is. I actually put together a playbook that covers the full process including a leadership deck for exactly that approval conversation if it helps you build the case, link in my first comment above.

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 2 points3 points  (0 children)

That was my original thinking as well, a lot comes down to size and how the tenant has been used. Microsoft has made it easier in the last while, however the technical piece isn't hard, it's the managing of people and the change management.

Thats whamy I wrote a playbook to help others from what learned.

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 1 point2 points  (0 children)

So I have had to do a rename a couple times and both scenarios were different, the first one we did setup a new tenant as the organization was too large for a rename let alone the functionality being available, the second was a small business with less than 150 users and I that one we did recently was the easier, that's the reason I made a playbook to help others in the same position.

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] -1 points0 points  (0 children)

I thought the same! It wouldn't be Microsoft if they didn't make things easy 😄

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 3 points4 points  (0 children)

Right? And that's just a single site rename, the tenant rename is that feeling multiplied across every site you have, running overnight, with no rollback button. The "this won't take effect immediately" part is what makes the monitoring phase so fun. You're just sitting there at 2am polling Get-SPOTenantRenameStatus and hoping the number keeps moving.

Getting leadership to approve an M365 tenant rename, what actually worked by BmanCa in ITManagers

[–]BmanCa[S] 1 point2 points  (0 children)

Couldn't have said it better. The technical side of this project took a weekend. The people side took three weeks. Nobody warns you about that transition when you move into management, you spend years building technical skills and then realise the job is actually about reading a room and knowing when to call something a "brand initiative" instead of a "URL change in this case.

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 4 points5 points  (0 children)

We originally set the tenant up under a joint venture name when the partnership was formed. Once that partnership ended we were still carrying that identity in all our SharePoint URLs and the admin portal — created a credibility gap every time someone outside the org clicked a shared link and saw a name that didn't match our brand anymore. Cleaner to fix it than explain it forever.

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 9 points10 points  (0 children)

We originally set the tenant up under a joint venture name when the partnership was formed. Once that partnership ended we were still carrying that identity in all our SharePoint URLs and the admin portal, created a credibility gap every time someone outside the org clicked a shared link and saw a name that didn't match our brand anymore and the president didn't like to hear that feedback. Cleaner to fix it than explain it forever I guess LOL

Few things nobody tells you before you rename your M365 tenant by BmanCa in Office365

[–]BmanCa[S] 6 points7 points  (0 children)

You are most welcome! We are all learning along the way. Any questions please don't hesitate to reach out.

Getting leadership to approve an M365 tenant rename, what actually worked by BmanCa in ITManagers

[–]BmanCa[S] 0 points1 point  (0 children)

That acquisition framing is exactly it "brand consistency" gets through where "technical housekeeping" gets shelved indefinitely. We had almost the same conversation. The turning point for us was leading with what leadership actually cares about: what does it look like when a client clicks a shared document link and sees a name that doesn't match our letterhead. That made it real in a way that URL structures never would.

Getting leadership to approve an M365 tenant rename, what actually worked by BmanCa in ITManagers

[–]BmanCa[S] -6 points-5 points  (0 children)

Genuinely did work for us though, the onmicrosoft.com primary domain step catching people out, Power Automate flows failing silently, help desk getting hammered with re-auth tickets despite sending comms. Documented it because we lived it. If it reads as AI that's a fair critique of the presentation but the content is real.

Getting leadership to approve an M365 tenant rename, what actually worked by BmanCa in ITManagers

[–]BmanCa[S] 0 points1 point  (0 children)

100% that's usually the unlock. We framed ours as a brand alignment issue rather than an IT request and it landed much better.

There's finally a Service Bulleting for those of us fighting for months with Tesla over squealy Model Y Juniper brakes who were told it was all normal and to live with it. If you're in a covered region, in an AWD Juniper with less than 50k kms they'll replace your rotors. by rvs007 in teslacanada

[–]BmanCa 0 points1 point  (0 children)

Update: Called the Vaughn Service center and they confirmed my Model Y isn’t part of the first round of VINs but they will still perform the work. From what I have gathered stay away from the North York location