Merger
-
@Jason said:
@scottalanmiller said:
@Minion-Queen said:
This would be a case to move them to Office 365 for their email portion at least. You can easily migrate them all over to O365 exchange and have multiple domains for people to be receiving at.
They say that they have a dependency that O365 cannot address.
What is that?
Frankly, I'm curious about this as well?
-
@Jason said:
@scottalanmiller said:
@Minion-Queen said:
This would be a case to move them to Office 365 for their email portion at least. You can easily migrate them all over to O365 exchange and have multiple domains for people to be receiving at.
They say that they have a dependency that O365 cannot address.
What is that?
He/They didn't say
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
Sure - but then the networks wouldn't be really separate. Though perhaps that wouldn't be a problem.
What do you mean? They'd be just as separate. In what way would they be less separate?
aww.. you're assuming a second IP on the ERL.. gotcha.
Correct. And then two networks internally.
-
@scottalanmiller said:
@Jason said:
@scottalanmiller said:
@Minion-Queen said:
This would be a case to move them to Office 365 for their email portion at least. You can easily migrate them all over to O365 exchange and have multiple domains for people to be receiving at.
They say that they have a dependency that O365 cannot address.
What is that?
He/They didn't say
Seems like this is the first thing that should be addressed.
-
@Jason said:
Seems like this is the first thing that should be addressed.
That would be my approach, if this were my project I would push on them HARD to determine that this is absolutely the truth and not just something that they are saying to blow off the idea. It's possible, but should lead to some questions about how they got into this state and how to avoid it in the future. I get the tight time frame, but this is making it tighter and getting the full picture here would potentially solve a lot of other things. Not everything by any stretch, but a bit.
-
@scottalanmiller said:
@Jason said:
Seems like this is the first thing that should be addressed.
That would be my approach, if this were my project I would push on them HARD to determine that this is absolutely the truth and not just something that they are saying to blow off the idea. It's possible, but should lead to some questions about how they got into this state and how to avoid it in the future. I get the tight time frame, but this is making it tighter and getting the full picture here would potentially solve a lot of other things. Not everything by any stretch, but a bit.
the legacy application is not compatible doesn't work with o365. the software vendor of the Document management sends emails with a tag so they can track all correspondence and auto save on to the documents management under each client without manually saving each email. this is done at the exchange level.
-
@scottalanmiller said:
@Dashrender said:
@StefUk said:
@Dashrender said:
@StefUk said:
i asume we can migrate just that app
Why do you assume this? How does the app work? How does it authenticate? How much data does it have?, etc, etc.
i keep missing the quotes .. if AD is merged, exchange merged, RDP and the only outstanding from company B is the APP , instead of bringing the entire infrastructure just to run the app, i can migrate the app,
sWhy are you merging twice though? or more like.. merging once and migrating once?
Merging company B into company A, then migrating company A into company C? Why not skip all that and just create C and migrate everything directly into it?
That's how I feel. Start this now, move fast. Might be done in two weeks with six weeks to sit back and relax.
that would be fine if no one was going to work for the next two months or no changes where going to be made
the main data migration still need to be done over a week end and out of hrs. -
What stops them from working? Sure you have to do big things like network file shares, etc during off time, but setting up the new AD, copying the users in, creating print queues, etc... all that can be done now.
-
@StefUk said:
@scottalanmiller said:
@Dashrender said:
@StefUk said:
@Dashrender said:
@StefUk said:
i asume we can migrate just that app
Why do you assume this? How does the app work? How does it authenticate? How much data does it have?, etc, etc.
i keep missing the quotes .. if AD is merged, exchange merged, RDP and the only outstanding from company B is the APP , instead of bringing the entire infrastructure just to run the app, i can migrate the app,
sWhy are you merging twice though? or more like.. merging once and migrating once?
Merging company B into company A, then migrating company A into company C? Why not skip all that and just create C and migrate everything directly into it?
That's how I feel. Start this now, move fast. Might be done in two weeks with six weeks to sit back and relax.
that would be fine if no one was going to work for the next two months or no changes where going to be made
the main data migration still need to be done over a week end and out of hrs.But you have to do it, right? So the sooner, the faster, the better? If you don't do it now, how will you do it later? And how does the process stop people from working?
-
@StefUk said:
@scottalanmiller said:
@Jason said:
Seems like this is the first thing that should be addressed.
That would be my approach, if this were my project I would push on them HARD to determine that this is absolutely the truth and not just something that they are saying to blow off the idea. It's possible, but should lead to some questions about how they got into this state and how to avoid it in the future. I get the tight time frame, but this is making it tighter and getting the full picture here would potentially solve a lot of other things. Not everything by any stretch, but a bit.
the legacy application is not compatible doesn't work with o365. the software vendor of the Document management sends emails with a tag so they can track all correspondence and auto save on to the documents management under each client without manually saving each email. this is done at the exchange level.
O365 is Exchange. If the DM sends emails, that suggests that it would work. Has this been tested? Your description makes it sound like O365 will work great, then you say it won't work as the conclusion. But I'm not sure why.
-
Here is some semi-useless advice which won't answer your questions.
Company A, Company B, etc is hard to follow. In examples you should replace them with real words, like:
Company A -> Aquotronics
Company B -> Bluebolt
Company C -> CrashcourseIt's like with maths problems where people use Person A and Person B instead of Arthur and Bethany or something.
It makes it hard to keep it all in memory and think about it, at least for people like me (dyslexics) when the names are all almost identical except for 1 letter.
Now to actually respond to what you said, in addition to all said above, several years ago we merged with another company, and several years before that another... well we acquired them but hey, I'm trying to help, let's not get into semantics.
In both cases we had setup domain trusts and moved mailboxes over, and gave the users multiple email addresses (outgoing / default / primary being the primary company) when they were acquired users. This way they'd still get email going to their old email address(es). What objects we couldn't move we simply recreated.
The general approach in both cases was that we get everyone working in both environments, i.e. the environments are working together (in both cases a VPN was setup to make this easy) and move similar users in blocks. So all receptionists switched over after we moved phone logging software over, and HR, and technical people, and so on.
It took about a week. The first time we ran into some problems, primarily because at the time it was more difficult to move things cross forest, and the last time it was a lot easier.
The biggest thing was getting remote users switched during their off time so that when they came in they'd be ready to go, just connecting to a different server. Some users (receptionists) were confused by this the first time, so we made sure to make it clear the second time around.
You're correct in thinking of doing it in such a way as to make the biggest disruptions happen last, however you also have to think of it in terms of what is needed to be done hierarchically, that is to say, if some software requires the users all users be moved first and subsequently they can't go back (maybe it stores things in AD, for example) then you have plan that out as well.
It's not a great, direct answer, but I hope it provided some insight since I've been down this road before.
-
Hence the use of foo and bar.
