Welcome to episode 421
of the Microsoft Cloud IT Pro podcast recorded
live from Workplace Ninjas US, December
2025.
This is a show about Microsoft three sixty
five and Azure from the perspective of IT
pros and end users, where we discuss a
topic or recent news and how it relates
to you. We're back to another interview when
Ben sits down for a conversation with Frank
Lesniak, the lead of the Microsoft three sixty
five team at West Monroe. In this episode,
they dive into the intricacies of mergers and
divestitures within Microsoft three sixty five environments.
They discuss the initial due diligence phase, planning
and approach,
building and configuring new environments, and the final
migration and cutover phase. Frank shares insights on
common challenges such as integration of different licensing
models, the handling of workstations and applications,
as well as the importance of security assessments.
The episode provides a detailed look at the
methodology
and tools used by Frank's team to streamline
these complex processes.
We're here for another Microsoft Cloud IT Pro
podcast.
Another one without Scott. I have left him
behind once more
and came to Workplace Ninjas
US twenty twenty five. So this is the
first one of these
in The US. And I'm sitting down here
with Frank Lesniak. Said the name right, right?
You got it. Alright, perfect. And you're the
lead for the Microsoft three sixty five team
at West Monroe Yeah. Microsoft three sixty five
Consulting. Yep. So happy to sit down and
talk with you, and I think we have
a super interesting topic today, it's something I
have done some of. Sounds like you guys
do a ton of these, so fascinated to
talk about our topic. But before we do
that, do you wanna give a little intro
about you, whether it's work or personal or
fun or whatever
you feel so inclined? Sure, yeah. So I
describe myself as a tech enthusiast. I like
to nerd out on various technology things. Home
on me. So tech is fun and work
and like there's a lot more Yeah. I'm
one of these rare people that actually likes
work. Like it's kind of it's kind of
messed up to say that out loud but
it is it's true. I do actually really
like what I do. So I I feel
blessed about that. Yeah. I'm a tech enthusiast.
I've it at the heart of it, if
anybody follows me on socials, I post about
general tech, not just Microsoft stuff. Okay. But,
yeah. At work, like you said, I lead
our Microsoft three sixty five team. It's a
team of 45 people
that have different sort of sub disciplines within
Microsoft three sixty five. Not everybody's technical. We've
also got project managers and other stuff. Alright.
But, yeah, like you said, one of the
things we focus on is corporate m and
a corporate m and a and doing divestitures
and integrations, and that is its own special
type of project that I'm excited to dig
into. Those are super interesting. And again, I've
done a few of these. But you have
done way more than I have, so I'm
curious to hear
some of your approaches. And we'll make sure,
like you said, socials, we'll make sure anybody
listening, we'll post all your socials Awesome. Awesome.
In the show notes. Speedbook can go find
you, follow you, all of that. Okay. But
we were talking about this, the merging and
divestitures. And I feel like
this has gotten
a lot more common in terms of at
least what I've seen from Microsoft three sixty
five projects
in the last few years of companies buying
a bunch of companies, and Microsoft three sixty
five has been around long enough now that
it seems like whenever you buy a company,
you both have Microsoft three sixty five. Copy.
Or you also have on the opposite side
the divestitures where these two companies
a big one that just split was it
Discovery and
HBO? Just split or Warner Brothers? Yes. I
just know. There was a split there, and
I think they had Microsoft three sixty five.
So it's like Yeah. And I know I
projects like that where it's
how do you start looking at these? And
we were talking, you gave me some bullet
points that we'll try to stick to is
you have three phases. And I think it
would be interesting to kinda dive through
when you start thinking about these three phases
and kinda how you approach this from that
perspective and how you help some of your
clients with that. Yeah. So before we dive
into that, one thing I forgot to mention,
we were chatting before this is, there's sort
of a pre phase that I may or
may not be or somebody on my team
may or may not be involved in, and
that's called the due diligence phase. Okay. So
before this is all kind like, at this
point, it'd be super confidential. Nobody knows about
the deal, this acquisition or divestiture. Right. And
there's this like, kind of pre phase where
typically the buyer you can do this on
the sell side too. If you're the seller,
you might wanna do, like, kind of a
tabletop sort of exercise where you Okay. Do
a fake diligence to see, like, how you
would score and maybe make some improvements before
you go to market. But typically it's on
the buy side where we're helping the buyer
assess the company that's being purchased and looking
at
how they might go about the divestiture.
Okay. And so and also are there any
risks in the environment? Like maybe there's a
glaring
MFA issue or something like that, right? So
we're out there. But there's MFA issues that
Microsoft three sixty five?
Well, talk to Merrill and get Maestro up
and ready. Yeah. There you go. Yeah. But
anyway, there's this sort of like pre phase
where we might do some like kind of
initial triage of the situation. But then that
gets us into Once the transaction occurs, people
sign the paperwork or they're about to sign
the paperwork, we start talking about the first
phase of of these projects, divestiture project, the
actual execution project, which is called we call
it an approach and plan project. Okay. Where
we basically get we simply start working with
the buyer and we figure out, okay, what
is it that we want to do here?
Because these projects always are like drinking from
the fire hose, everybody's like, let's go and
there's not really a plan usually. Right. So
the first thing we do is it's not
very sexy, but we sit down and we
build that plan and the specifics about what
it is we're going to do. And we
work with the seller as well to get
agreement on, like, hey, this is going to
be the approach. This is precisely how we're
gonna migrate email, SharePoint, Teams, even old school
file shares maybe, identities, workstations. Here's the plan.
Here's how we're going to do this. Do
you agree? If so, great. If not, okay.
Let's figure out something that is agreeable. And
then also, what tools are we using? Are
we gonna use bit tight migration ways? Are
we gonna use Quest on Demand? What are
we doing? And what sort of permissions are
implied or what sort of connectivity might be
implied with that approach? Yep. Do you ever
have I've come across this with some of
the I would say more the mergers that
I've done, but it'd be interesting. I haven't
done a lot of divestitures
Mhmm. Where you even have a merger and
the buyer of the company is like, we're
buying this other company. Mhmm. We need to
migrate. And we're like, okay. Great. What are
we migrating? They're like, well, we know they
use Teams.
We don't really know about other stuff. Do
you also build in, like, I would say
almost a discovery of it? Let's go into
the company you're buying and actually figure out
what it is we need to migrate. Yes.
Exactly. Yes. Scoping the migration is so like
people don't really I think clearly appreciate this.
We spend a lot of time in this
upfront phase.
First of all, figuring out who are even
the employees that are coming across. Yeah. Because
not everybody might come across. I've seen that
too where it's like a portion of the
company is being bought. Yeah. Like let's say
it's 200 That's like that's the churn merger
all in one. Right. Right. Exactly. Let's say
it's 200 people that are conveying. Well who
are those 200 people? Like let's get a
definitive list. You'd be surprised at how challenging
that is sometimes. Just getting the damn list
together. Once we have a list though, we've
got some automations and some tools written. Unfortunately
these are not publicly available. Okay. We basically
You gotta have some IP, right? Exactly. Yeah.
We do.
I'll describe what happens. Basically what we do
is we work with the seller to do
a full inventory of Exchange
and SharePoint, and we keep that data in
their environment because there's no way in hell
the seller is gonna give us a full
inventory of their environments. We just say seller
run this tool, keep the data, and then
we've got a separate so it's like basically
that does a full dump of Exchange and
full dump of sorry, metadata. Not Got it.
Not the actual data, but just the data
about the data. Yeah. Exactly. Yeah. Like here
are all the recipients in Exchange and here's
all the information about them. Basically that's what
we're doing. Okay. And the SharePoint front, here's
a list of all the SharePoint sites and
the permissions associated with them, the URLs and
all that sort of stuff. Alright. I'm being
I'm overstintheling a little bit, but basically that's
what that looks like. Right. And it's a
huge CSV as the output. Got it. We
then have a second script that basically does
an ETL on the data set. And it
it walks through the permission set to recursively
find all of the, in the case of
Exchange, that are related to that list of
definitive people that are coming across. Got it.
Okay. So we find all the mailboxes that
have some sort of involvement
or distribution list, whatever. Right. Share mailboxes.
Exactly. Yeah. We find the things that are
related definitively to these 200 people. And it
typically is a superset. There's like usually some
junk in there that doesn't need to convey.
But this gives us like sort of the
universe of what might need to migrate. And
then there's some adjudication on that list with
both the buyer and the seller. Like, buyer,
do you really want this to come across?
Yes or no? Right. What even is it?
They might need to go investigate with whoever
has permission to it. And then the seller
might say, no. You're not getting that data
for x y z reasons. So this is
an adjudication process that is not something you
can automate, but Okay. Yeah. That that all
kicks off in this Do you ever look
at and get involved into and again, one
that I've seen come up is all the
enter apps that are registered. Like they're when
they do a merger and it's, oh, by
the way, you have DocuSign that's set up
with SSO, and you have Yep. Adobe Creative
Cloud, and you have Calendly, and you have
I mean, it's not uncommon to see hundreds
of registered applications that are in Entra. Yep.
It's like you realize that this merger, that
entry timing goes away. Yep. How are we
gonna handle all of those registered applications? Yeah.
So if it's a divestiture or carve out,
right, that's got one of pressure. We typically
would wanna understand what are they actually using,
and what also like This is I'm getting
ahead of myself a little bit, but there's
like a question about some the timing of
some of these things. Right? So like, let's
say that you let's say that the selling
company has 2,000 apps. They're a huge enterprise,
but the divesting entity only uses two only
air quotes uses 200 of those. Right. Right?
Then we have a question of, okay, do
these apps need to convey yes or no?
Something like DocuSign, they might be able to
continue to use the selling company's iteration of
that app for some period of time. And
the access and ability for the divesting
folks to continue to use the selling companies
applications is covered under an explicit legal agreement.
Okay. We're getting a little off tech here,
but but it's actually important. Well, but it's
all yeah. It's all part of this. So
this is an agreement called the transaction services
agreement or TSA. Okay. It describes
in detail, here are the services that are
gonna be provided by the seller for this
amount of time, and here are the fees
associated with those services.
So it's typically a monthly fee for email,
a monthly fee for SharePoint, a monthly fee
or whatever. Yep. And those things are typically
enumerated. The ideal situation is
we help the buyer
negotiate that transaction services agreement during the diligence
phase that I mentioned that I'll put in
the pre phase. Okay. So you help with
that part of it too then? Not me
personally, but we have But you have people.
Specialists. Yeah. People on your team. Yeah. They're
working with lawyers and stuff too. Right? That's
right.
Those lawyers. I know. I mean, the thing
about these TSA's though that's so important is
that monthly fee for service.
And we, West Monroe and my team, we
focus a lot on speed. And so what
ends up it's sort of funny in a
way. Maybe I shouldn't say this. But these
companies that are selling these divisions or whatever,
they're divesting these entities.
They structure these transaction services agreements to make
money. Like, they're they're basically I mean, sometimes
these fees are crazy. Right? Or sometimes the
fees escalate. That's the other thing. They might
divide the service for a certain number of
months, and then the fee escalates if you're
not off in a certain month. Got it.
Right? So it's sort of the build versus
buy mentality a little bit. Like, let's say
the company that's acquiring this organization has a
team. Maybe they technically have the capability to
do the business for themselves. That's fine. And
and what they may have the sort of
wherewithal to do that, but they may not
have the capacity to do it relative to
their other op day to day operational expenses.
Or not expenses, but day to day operational
Right. Because of the speed and the timing
and all of that. Yeah. Yeah. So so
let's say a typical IT team can do
a divestiture
in nine to twelve months. I think that's
reasonable if you've got a decent team who's
maybe done it before, but don't have a
dedicated resource pool that that can do this.
And they're sort of splitting this with their
day job. Nine to twelve months might be
typical for like a mid sized sort of
divestiture. My team can get it done in
probably three months. Okay. If you think about
that, right, relative to the TSA and the
monthly fees Oh, yeah. We have an automated
automatic business case for even though, like, our
fees aren't small. Like, we come in and
we do this quickly and we sort of
in in some ways, it's I think it's
sort of funny because we end up doing
a little bit of a bait and switch
sometimes with these selling companies. They think they're
expecting to earn nine months of monthly revenue
from providing these services. And then we come
in and get it done in three. They're
like, oh, crap. Right.
They're done. But I don't feel bad about
that, actually. Like, I to me, it's like,
hey, man. Like, you're kind of price gouging.
It's sort of a captive audience. Oh, for
sure. You're sort of price gouging this. But
it's all part of the negotiations and the
sale anyway. So Yeah. Yeah. So once you
get that's kind of the approach and plan
where you're doing the discovery, you're running all
your tools, figuring out the data. Exactly. You
have to know what's migrating. This is probably
where you also develop a little bit of
the project plan of we're gonna do it
in this order. A percent. Yeah. This is
the timing. Yeah. Exactly. So going back to,
like, your question about the applications, I guess
I didn't really fully address that. There's discussion
about, okay, so when are we migrating email?
Are we migrating workstations at the same time
as emails? Depending on the size of the
company,
that may be reasonable you may wanna do
that. You may want a big bang email
workstation on the same weekend, let's say. Right.
And then the question is, okay, what about
applications? When are those migrating? They might migrate
at the same time depending on what they
are. If there's software as a service applications,
maybe we're just getting new contracts put up
with DocuSign, to use your example earlier. Oh,
really? We do DocuSign contract. We connect that
to entry ID. When we provision identities and
they register for MFA, they're they have access
to it and they're off to the races.
Right? Simple example, but, like, we may cut
over some applications in that way. Other applications
may take longer and they may need access
they may need to be accessible under the
TSA for some period of time. Like, in
the case of manufacturing, for example, they might
have an ER, an ERP platform,
that's running all their manufacturing and shipping and
all the logistics and everything. I mean, you're
not gonna spin that thing up Right. Immediately.
You can't disrupt their business for several months
either. You're probably not I mean, even if
you're a superpower, a super nerd at ERP.
Because you're not spinning up an ERP that
reflects their business operations in three months. Yeah.
It's not gonna happen. That's probably more like
a year to eighteen month project. Okay. So
typically, there's some applications that are sort of
left behind Mhmm. In some way that has
to be sort of negotiated
for the migrated users to get back to
those applications depending on their architecture. Right. Yeah.
It's interesting. And I was one of the
ones I'm thinking through now and working on
as well is like both companies have AD,
all the workstations are joined to AD, both
ADs are synced to different entry tenants. Like,
there's a lot of moving parts when you're
planning this out to think through. To your
point, the timing, it's if you just move
identities and SharePoint and email, but you leave
the workstations in the old domain
for a period of time, now you have
two identities
and it's Right. Exactly. There's a lot of
different, I would say, a lot of nuances
that you really do need to sit down
and figure out this plan. Exactly. Yeah. Like,
we have a standard playbook that we we
try and follow, but there's none of these
are the same. There always some there's always
some unique wrenches.
Like, I I didn't mention this, but the
other thing that comes up in these approaching
plans sometimes is a seller that just says
no to everything. Like,
sometimes these folks are just really difficult. I
get it. Like, people are worried about cybersecurity.
They're worried about they're talking to if we're
on the buy side. Right? Like, if the
buyer is the one who hired us, the
seller didn't hire us. Right. They don't wanna
work with us necessarily. And some of the
employees don't want it. They're like, no. The
CEO sold the company. I'm mad that we're
getting sold to the buyer. Exactly. Exactly. Exactly.
Or they're mad they weren't sold. Maybe they
wanted to convey. Like, there there's all kinds
of politics that go into this. But also
the sometimes there's that that remember I told
you that bait and switch thing where we're
kinda getting they're realizing we're gonna get this
car done a lot faster than they were
expecting.
Sometimes they introduce roadblocks to slow things down.
Got it. Whether they say that explicitly or
it's understood or not, I that's what's happening
in a lot of cases. Yeah. And I
was imagining
too, it kinda goes to something we might
touch on later, is you also could probably
have MSPs involved with the seller where the
MSPs are worried they're gonna lose Yes. Their
client Yeah. That's right. Because they're being acquired
by the buyer who has a different MSP.
And MSPs
can be a little difficult when you're trying
to pull stuff away from them. So Yeah.
We've heard that happen a few times where
they just aren't I mean, they're not teach
people
how to cooperate, but they also have to
They're not helpful.
Yes.
You get that whole approach, you've planned it
out, you have it set up, and then
you move into phase two. We'll call it
phase two. You kinda have the pre phase.
We got a pre phase, phase one, phase
two. Yep. Yep. Exactly. So this is where
so in most situations, this I'm gonna totally
agree with specific circumstances. But in a lot
of situations where we're working on divestiture, that
divesting entity is getting spun up as its
own standalone company. Okay. I think about it.
You're going from relying on probably a centralized
IT function.
You're you're part of a big company, like
a huge enterprise. You're relying on a centralized
IT function at that large company. Now you're
getting
carved out or spun off as your own
entity, and you don't have an IT function.
So we're building that for them. Right? A
lot of times these these investors don't have
IT staff that are conveying. Well, maybe they
have one IT leader. That's fairly common work.
Somebody is sort of nominated as the new
CIO or thereabouts. Do you get to go
leave and be the new IT guy at
the new company? Yeah. Which is fine. That's
a pretty good perk. You become the CIO.
Right. Get a promotion due to it. Exactly.
So sometimes that's the case where we have
a director who's there, but usually there's no
other conveying. Okay. Nobody actually do the work
because we all know what directors do. It's
like they
there isn't necessarily even someone who's a decision
maker.
Okay. Right? Like, they may not maybe they're
in charge of IT, but they may not
be maybe they're more of an application person.
For example.
There's a lot of different permutations there, but
basically they may not be able to make
all the decisions that need to be made.
So we have a a templatized playbook for
spinning up new m three sixty five tenants
and new Azure subscriptions and all the infrastructure
that goes along with that. So for Microsoft
three sixty five, we use m three sixty
five DSC today. Alright.
And one of my coworkers, a shout out
that like Cherry built a he built a
very robust, very and others do our involved.
I shouldn't change that. They built out a
very robust,
that that saves a ton of time
and reduces a lot of risk. And then
we also have something similar on the Azure
side. We use Terraform,
like so many other companies too. And there's
a co kind of a complicated chicken and
egg situation that you'd have to talk more
to, like, Danny Stutz or Blake Cherry about.
Uh-huh. There's there's a chicken and egg situation
where they don't have a,
an Azure DevOps environment yet, and we need
them to have one, so we have, like,
just to kind of rebuild that and kind
of seed everything and then and then launch
this. And then you can go push it
all out. Okay. We're setting up kind of
a corporate IT, back office IT style subscription
that meets all the best leading practices and
all that sort of stuff. It's like we're
doing hybrid identity by default so we're getting
domain controllers spun up, we're getting some utility
servers spun up. Basically, the for infrastructure you
need to run any business, getting all that
spun up, and and the same eventual I
venture it, connect, and all these things. Got
it.
Do you feel overwhelmed by trying to manage
your Office three sixty five environment? Are you
facing unexpected issues that disrupt your company's productivity?
IntelliJunk is here to help. Much like you
take your car to the mechanic that has
specialized knowledge on how to best keep your
car running, Intelligent helps you with your Microsoft
cloud environment because that's their expertise.
Intelligent keeps up with the latest updates in
the Microsoft cloud to help keep your business
running smoothly and ahead of the curve. Whether
you are a small organization with just a
few users up to an organization of several
thousand employees,
they want to partner with you to implement
and administer your Microsoft cloud technology.
Visit them at inteligync.com/podcast.
That's intelligink.com/podcast
for more information or to schedule a thirty
minute call to get started with them today.
Remember, Intelligink focuses on the Microsoft cloud so
you can focus on your business.
That's in a divestiture. How do you think
about it when it's a merger? Because then
some of that you're not building from scratch
because the parent company has it. Yeah. I'm
assuming there's still gonna be maybe stuff to
build based on some of that planning. Yeah.
But do you approach that then a little
or how do you approach that, I guess,
from the build and configure? It's a lot
more bespoke. I mean,
to be honest, like, I like to give
benefits of doubt to any client I work
with. There are a lot of smart a
lot of smart people out there, and nobody
intends to make egregious security mistakes. Yep. But
not everybody does a good job of testing
their security and
one of the first things we do, I
used to do this years ago because they're
one of my clients had a security incident
unrelated to our work, but like, it was
while we were doing a project. You always
have put that disclaimer on there. Right? They
had a security incident, but it wasn't us.
No. For real. Because I've had that too.
But it was it just happened while we
were doing all their work, man. Yep.
And they were mad at us because we
had administrative access to their tenant. Well, it
didn't have And they got it. Why didn't
you look at us? And it's like, we
didn't have any scope to look at. Why
would Right. Why would I You didn't hire
us to do a security analysis of your
environment. Not gonna I'm like, go away on
my way to see poke around in your
tenant, which we might raise other alarms. Why
is Frank looking at all these security settings?
Yeah. Let's Frank do it in the HR
SharePoint site.
Right. Right. So I instituted a rule, and
we stick with this now. We're we have
any sizable m three sixty five project. Doesn't
matter if it's the best of your integration,
whatever. Always do an m three sixty five.
Alright.
Even if the client doesn't want us to
do it, we're still doing it and we
might maybe not make a big show out
of it, but I still wanna know what
the security posture of the market is. Right.
And so we do that to the target
organization of the place where we're migrating to
the next situation.
And along with that, we're also kind of
examining the general MFA posture of the divesting
entity or or the entity to be integrated,
I should say. And what we're looking for
is, like, are there differences in MFA behavior
that we need to sort of adjudicate and
figure out, like, maybe resolve differences on? Whether
that's because there's a security
hole or because
something is too lax or too aggressive and
and, like, basically, what are the impacts these
employees are gonna experience when they come in?
And is there anything we need to fix
because there's a glaring security problem? Yeah. The
other one I've seen too that's become more
interesting especially with mergers is different licenses.
Yes. Like if
if the
the selling company has e fives and the
buying company only has e threes Right. Like,
you can run into some and I'm assuming
that actually comes out in the approach and
plan, but then Yeah. Building out how are
we gonna handle this because
we're losing certain functionality.
Yeah. Exactly. Actually, we had that situation earlier.
Was it this year? I think it was
earlier this year. Yeah. We wrapped up this
project in January where we were working with
two very large manufacturing companies. They're global.
Alright. I can't say the name on it,
but I know it's fine. If I told
you the name, you would know who they
are. We were working with them on basically
an approach and plan and that situation was
exactly right. They had one company had M365E5,
the other one had M365E3
and they were coming together as a new
organization and really trying to figure out what's
the and the e three organization had a
bunch of third party tools in the mix.
CrowdStrike and all that, you know, I mean,
they were sort of augmenting the gap there
with other stuff. Yep. And there was a
sort of there was a lot of discussion
and consternation around, like, what's the right at
at the end of the day, this is
just, like, part of the planning, part of
the adjudication. It's, like, okay. Let's
come together and resolve these differences. You're gonna
be one team, etcetera, etcetera. Yep. Actually, that
situation was kind of interesting too because they
were two public companies, and we were working
before the transaction was closed. So before the
legal documents were signed. Oh. And they were
competitors. And so they weren't legally allowed to
talk to each other about this sort of
stuff. Oh, wow. So they talked we were
hired as sort of an intermediary. It was
a unique situation. We were they were able
to talk with us, and we were able
to kind of mediate and figure out, okay.
Like, here's what you guys should be. Like,
if you're a consultative sort of way, here's
what you all should be thinking about. Is
this agreeable person a? Is this agreeable person
b? Person b. Yeah. And that would have
been fascinating. It was it was pretty interesting.
Yeah. Yeah. Very cool. What else? So, yeah.
We talked about NetNewell tools, automating it, building
out those landing zones, Terraform, DSC.
We spent all the time in the Workstations.
Yeah. Deployments and workstations. That's another interesting one
because we talked about their domain joined. Like,
it's not just a, hey, let's go change
the domain or the enter domain that the
enter ID Yeah. And here's the thing, like,
you can't technically, you can flip these machines
in place from
being traditionally domain joined to being enter ID
joined with and then autopilot enabled should they
need to be reset or something. Yeah. You
can do that technically. Like, QuestODM supports some
of that functionality. We've had clients that that
employ that functionality very well. I had a
client use UK based, and this is before
we got involved, but they big bang migrated
I think 5,000 workstations
in like an evening or a weekend. Wow.
I mean, when they tell me this story,
I thought they were lying to be honest.
That just makes me It makes me so
nervous. Yeah. Yeah. Personally, I would not stand
up for that. But I mean the technology
is there. The issues that we have to
figure out though is more on this like,
I'm talking about divestitures a lot because that's
mostly what we have to deal with. Okay.
Because integrations are a little different. Like when
you're if you're buying a company in a
Folsom sort of way, like you bought an
entire entity and there's no carve out taking
place. Yep. You kinda have full control of
the environment and you can do whatever you
want. So you might be able to do
that in place migration. But when you're doing
a carve out, you're not typically getting admin
rights to that selling organization's environment.
Yeah. So it becomes,
you can't do what you might wanna do,
I guess, is what I'm trying to say.
Right? So our typical approach for workstations
is actually to de autopilot enroll with them
from the parent or the selling company's side
Okay. And then autopilot enroll them on the
acquiring organization side and either reset them or
reimage them. Yeah. Depending on that's our typical
sort of playbook, but It's in my
experience, that's the easiest way to do it.
It's a if you do But it causes
consternation. You're wiping the device. What's the situation
with the date on the device? It away.
Exactly. Because at that point in time, you
don't have anything spun up like OneDrive with
no folder move that's gonna move it into
the Exactly. We have to like we have
to kind of hope, pray, plan, and assume
with communications that that the selling organization has
that stuff turned on and it's syncing correctly
and we're getting telemetry and there's communication to
users to make sure that they're checking that
OneDrive icon to make sure there's no To
make sure. There's no red x's or anything
like that. Like, so many people ignore that
the OneDrive sync client. Yeah. It does make
me nervous and this is always a big
point of concern when we come in and
say, hey. Let's wipe all the workstages. Everybody
freaks out. Right? So it takes some Right.
Takes some most organizational change management, so to
speak, to And then I'm assuming too when
you're doing the migration, it's probably also, to
a certain extent, like, what data are we
allowed to take, what data has to stay
behind Yeah. Yeah. Making sure that we're only
migrating
what we're supposed to and that we're not
missing anything. We're also supposed to migrate. Yeah.
Yeah. I mean, on the workstation side, we
don't worry about that so much. It's typically
assumed and agreeable that anything on the workstation
can convey. Okay. And anything in people's OneDrives
can convey typically. I think I haven't had
a seller, knock on wood. I don't I
don't like this adjudication stuff. It's annoying. Good
to call. Tomorrow. You're right. Like, I mean,
this may come up. But generally speaking, they
kinda give people the benefit of the doubt
that, hey, people aren't stealing
or trying to actual trade stuff. Yeah. Where
that comes more into play is, like, on
the SharePoint team's file share side of the
house where we maybe extend a bit more
time. And that's we try and we start
that process in the approaching plan where we
sort of draw the boundary around the what
possibly might migrate. Yeah. But there's usually ongoing
adjudication about okay what exactly is gonna I
like that word adjudication by the way. It's
a fun word. But there's ongoing sort of
debate about what is and isn't migrating and
sometimes a reversal of decisions too, which is
always fun. Anyway, yeah.
Wow. So that's you got it all built,
configured
Yeah. Ready to go. Like, at this point
in time Yeah. The end of this, you
haven't ready to migrate. Right. You haven't actually
migrated anything. You've just prepped. Okay. It's all
ready. It's here to go. We're gonna move
it over now. I've heard this say, we're
also staging the data in this space. Okay.
Yeah. So So you can set up a
free migration of some of the mailboxes. Yeah.
We pre stage the data, like, for example,
with migration was mid time migration was
used you precede
email data that's, like, t minus thirty days
old, typically. Yep. You get all that sort
of stuff staged, and you fix errors, and
you deal with all that. And that's it's
kind of kinda works in the background. Same
thing with SharePoint we use. I mean, it
depends. We typically use Sharegate. Sharegate. Okay. And
and same thing for Teams. And we can
also use Quest and we do sometimes. It
depends on the situation. So anyway, we we
precede as much data as we can during
this phase. Alright. And then you get to
the cut over where everybody's
probably Yeah. All hands on deck. All hands
on deck. And Yeah. There's a couple different
approaches here. Like, you have the big bang,
the one you talked about, where maybe you're
migrating 5,000 users in a night or in
a weekend. Yep. Or there's probably also scenarios
where you may try to do things a
little bit more gradual and probably pros and
cons to both of those. Yeah. We almost
always big bang identity and email. Okay. Because
it's just not feasible in my opinion.
I mean, it technically, I get that you
can make this work. But, like, again, with
the divestiture kind of situation in mind, the
selling company doesn't want us to screw around
with their email flow. Yep. Makes sense. They
do not want us putting tools in place
that messaged through. That's just that's not an
option realistically speaking. Yeah. So we are typically
doing a big bang migration out of necessity
on at least on email and identities.
Alright. Just because otherwise it gets confusing as
to how do you even email this person.
I know you use forwarders and other stuff,
but like it just becomes a Yeah. It
gets messy. Yeah. And then the other actually
the sticking point is usually calendars and trying
to see, like, trying to schedule meetings accurately
with people and understand their availability. If we
I didn't mention this, but when we do
a final cut over of email using, like,
for example, migration whiz, that final cut over
is what brings the calendar over. There are
no calendar items brought over Okay. Until that
point. So it's not That's right. Because calendar
doesn't come over to pre stage Correct. With
the type. Correct. And actually if you do,
like, if you do bring it over for
whatever reason, it causes it, it can cause
issues. You wanna do that in one fell
swoop at the end. Yeah. Calendar point, like,
getting edits, deletions, changes. Yeah. I've seen the
major issues of recurring meetings. There's all kinds
of problems if you do that. So, yeah.
So you have to bring that over at
the end. So if you got some people
migrating, some people now, you can't see calendars
accurately unless you set up
calendar, like, federation and stuff. You're not doing
that in a situation.
So so it's a big bang email cut
over typically. And then
in the typical big bang cut over is
also kind of group SharePoint teams. Those are
also typically big bang cut over.
Okay. To the extent that we've successfully adjudicated
or agreed upon what's migrating, there's usually some
subset of sites
where
the selling company is insisting on doing a
deep review or maybe lawyers need to get
involved to data data. I can imagine some
of those probably more sensitive sites. Yeah. Yeah.
Again, it depends on the business side. Understand
some of those Some people just sometimes, like,
I I understand, like, security, and I definitely
appreciate that. But sometimes, like, sometimes you kinda
wish, like, can we just agree to be
adults here and, like, business professionals and,
the new company that's being created like we'll
just delete stuff that isn't relevant. We just
agree to this is like a business agreement.
It sometimes works, sometimes doesn't.
But anyway, sometimes stuff doesn't migrate for that
reason. We kind of leave it behind and
we migrate it later. But generally speaking we
try to bring those SharePoint team sites over
the scene. And OneDrive as well. Sorry. I
forgot the message now. Sorry. Actually, that's not
entirely true. We bring OneDrives over with people's
workstations.
Oh, okay. Right? It makes sense with a
known folder. Yeah. Because otherwise, if we brought
OneDrives over ahead of time, they're on their
workstation that's connected to the selling organization. Their
OneDrive is gonna get us sick. Right. So
we timed OneDrives with the migrate with the
workstations, and that's kind of the big the
workstations is really the big question mark in
terms of big bang or not. It really
depends a lot on the logistics and what
can be supported and what's agreeable to the
business. We I would like to big bang
workstations the same weekend. It just makes everything
easier if everybody sort of wakes up on
Monday morning and they're on their new stuff.
Yeah. That's the best scenario if we can
do it. But sometimes if if they have
a large number,
on-site, like a manufacturing plant or something like
that Okay. Right, we have to dispatch a
small army to kind of facilitate some of
this stuff because, again, the the organization doesn't
typically have IT staff.
So we're sending a small army at these
locations. And depending on how many there are
and how where they're located in the world,
we may or may not be able to
do that all on the same weekend. Got
it. So we just have to kind of
think through some of that stuff. And sometimes
we big bang it, sometimes we don't. Alright.
Yeah. Very cool. Well, thanks. Yeah. At the
end, we're at the end of all that,
that's typically the work my team's doing. We
might bring over applications like we were talking
about earlier too at the same time. Alright.
But at the end of all this, typically,
there's they're online in the new environment. They're
working on their new either they're newly issued
I forgot to mention. Sometimes we issue new
workstations
because Okay. Maybe the workstation the hardware sometimes
isn't conveying as part of the transaction. Like,
the buyer has not bought the workstation. With
the seller. Yeah. It has to be sent
back to the seller or something. That's ridiculous.
I think, but that's what that's sometimes what
happens. So either we've given them new machines
or they're using newly
reset or newly released provisions. Yep. Yep. They're
on their new email. Everybody's happy. At least
within a couple of days, everybody's happy. And
but sometimes there's some applications that are sort
of leaving behind, like, those ERPs and other
big big behemoth type applications that just take
more time and effort focusing on the migrate.
Got it. So yeah. That's it. Awesome.
Well, very cool. Thanks, Frank. Yeah. I appreciate
it. Yeah, man. It's always fascinating. I haven't
I have not encountered anybody that's focused
this much
on mergers and investitures. So it was This
is really one of our one of our
key one of our team's key focus areas
is this kind of project. Alright. Perfect. Well,
we'll put links in the episodes,
company website, your social media, Anything else you
wanna share with people,
socials if they wanna get in touch with
you or
websites, LinkedIn, best places to find you? I'm
pretty easy to find, to be honest. Pretty
much on all the socials, you can find
me my first and last name. Okay. I
know you have links, but just to say
that out loud in case somebody's Perfect. While
they're listening. Yes. Exactly. Yeah. So I'm on
x blues guy,
LinkedIn,
Macedon. I don't use it that much when
I'm on there. Okay. I'm on GitHub. So
there's all kinds of ways to get All
of them. Are you the only Frank Lesniak?
No. You'll find one other Frank Lesniak that
comes up when you Google Alright. Name. He's,
funny enough, he lives in Chicago area, which
is where I'm where which is where I
live. But he's, I think, either an administrator
or, like, a long tenure teacher at a
public school. Okay. So that's not me. I'm
not a teacher. So Chicago, are you a
Bears fan? Are you a football fan? I
like the Bear. I'm not a I'm not
like a mega Bears fan. Like, I'm not
on if you ever seen SNL skits, the
Supermans, I'm not one of those guys. You
know? I do like the Bears. I watched
them the other night. Alright. Yeah. I grew
up in Michigan, so I'm a Lions fan.
Okay. I'm still a little mad at you
for taking Ben
Johnson.
Sorry, man. Yeah. That's fair. It happens. Yep.
Alright. Well, I will let you go. I
saw the drink cart go by Yes, I
see. The Expo Hall. So right now this
episode is standing between us and
a party in the Expo Hall. Okay. So
thanks again for joining us. Yeah. All the
links for stuff. I'll get any other links
too that you wanna put in the show
notes, and
enjoy the rest of the conference. Yeah. Thank
you. Thanks for having me. Thank you.
If you enjoyed the podcast, go leave us
a five star rating in iTunes. It helps
to get the word out so more IT
pros can learn about Office three sixty five
and Azure.
If you have any questions you want us
to address on the show, or feedback about
the show, feel free to reach out via
our website,
Twitter, or Facebook.
Thanks again for listening, and have a great
day.